[PD-dev] removing pd/bin/msvr*.dll from Pd/win

[Lucas Cordiviola]

> Is pdlibbuilder/mingw statically linking in its own msvcr*?
Yes. --> 
https://github.com/pure-data/pd-lib-builder/blob/master/Makefile.pdlibbuilder#L638

I guess you don't want to hear the nightmares of the C-runtimes that are 
needed to ship if compiling with MSVS. (latest VS compiled stuff running 
on windows machines without updates, etc)

:)

Mensaje telepatico asistido por maquinas.

On 1/22/2019 7:36 PM, Miller Puckette wrote:
> Would this mean that anyone shipping a binary external for Windows would
> have to put it in a separate directory with its own msvcrt.dll/msvcr90.dll?
> Sounds like a nightmare to me.
>
> I don't understand the issues yet... in particular, since pdlibbuilder uses
> mingw on Windows, how does it work with Pd if mingw and msvcr*dll aren't
> compatible?  Is pdlibbuilder/mingw statically linking in its own msvcr*?
>
> cheers
> Miller
>
> On Tue, Jan 22, 2019 at 10:51:45PM +0100, Christof Ressi wrote:
>> I agree and I've already suggested this: https://lists.puredata.info/pipermail/pd-dev/2018-09/021721.html
>>
>> BTW, I got linker errors because of msvcrt.dll when I compiled Dan's pdfontloader. this left me scratching my head for quite a while. removing the DLL solved the problem.
>> https://lists.puredata.info/pipermail/pd-dev/2018-09/021709.html
>>
>> Christof
>>
>>> Gesendet: Dienstag, 22. Januar 2019 um 22:16 Uhr
>>> Von: "IOhannes m zm??lnig" <zmoelnig at iem.at>
>>> An: "PureData developer's list" <pd-dev at lists.iem.at>
>>> Betreff: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
>>>
>>> hi,
>>>
>>> TL;DR: i'd like to suggest to remove the "msvcr90.dll" and " msvcrt.dll"
>>> files from the pd\bin\ folder of all (future) windows releases.
>>>
>>> rationale
>>> =========
>>>
>>> # usage by Pd
>>> first of all, these files are not used by Pd at all.
>>> they are only provided as a courtesy for externals that happen to
>>> require a dyamically linked libc implementation but fail to provide one
>>> themselves.
>>> most likely this is a leftover from the days, where any dynamic
>>> dependencies of an external would only be looked up in the Pd\bin\
>>> folder (and not in the folder of the external itself), making it
>>> impossible to ship externals in a self-contained folder.
>>> luckily, these days are gone.
>>>
>>> # incompatibility
>>> for whatever reasons (personally i blame redmont, but i might be
>>> biased), "msvcrt.dll" is not a well defined library. especially it does
>>> not guarantee any binary compatibility.
>>> in practice, the "msvcrt.dll" as shipped with Pd is *incompatible* with
>>> msvcrt.dll as used by mingw when compiling. (it might also be
>>> incompatible with a file of the same name shipped with the latest
>>> release of MS Visual Studio, but i haven't checked).
>>>
>>> that means: the provided msvcrt.dll simply will not work with any
>>> mingw-compiled external.
>>> if the
>>>
>>> # compiling
>>> i noticed that i cannot compile/link externals for windows/32bit using
>>> mingw, if their build-system uses autotools/libtool.
>>>
>>> the linking stage fails in catastrophic ways, only because the linker
>>> picks up the
>>>
>>> here's an example log-file of such a failed build:
>>>    https://git.iem.at/pd/Gem/-/jobs/3230
>>>
>>> <techdetails>
>>> it took me a while to figure out what went wrong, because pd-lib-builder
>>> based externals compile just fine.
>>> it turned out, that the difference was that pd-lib-builder would link
>>> against "${PDPATH}\bin\pd.dll" (that is: it uses the full path as the
>>> library file to link against) whereas libtool based builds would link
>>> against "pd.dll" and add "${PDPATH\bin\" to the library search path (the
>>> actual linker flags being "-L${PDPATH}\bin\ -l:pd.dll").
>>> since explicit library search paths take precedence over built-ins,
>>> adding "-L${PDPATH}\bin\" would make the linker find the "msvcrt.dll"
>>> file in ${PDPATH}\bin\, which happens to be incompatible with mingw, and
>>> thus an error is raised.
>>> </techdetails>
>>>
>>> the *only* way i found to fix the linker flag, is by removing the
>>> "msvcrt.dll" file from ${PDPATH}\bin\ before starting the build-process.
>>> in practice i also removed the "msvcr90.dll" file.
>>>
>>> incidentally, there are no problem with the w64 version of Pd, as this
>>> ships 32bit versions of "msvcr*.dll", which will be ignored by the
>>> compiler/linker/runtimelinker, because of a non-matching architecture.
>>>
>>>
>>>
>>> # conclusion
>>> afaics, there are currently **no** benefits in shipping the msvcr*.dll
>>> files.
>>> however, they do create a number of issues.
>>> (and in the case of Pd/W64 they are of the wrong architecture anyhow)
>>>
>>> i don't see a reason to keep them.
>>>
>>> fgmdsar
>>> IOhannes
>>>
>>> _______________________________________________
>>> Pd-dev mailing list
>>> Pd-dev at lists.iem.at
>>> https://lists.puredata.info/listinfo/pd-dev
>>>
>>
>>
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at lists.iem.at
>> https://lists.puredata.info/listinfo/pd-dev
>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev