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

[Lucas Cordiviola]

I also agree.

I will try to find out if any of the old extended externals actually 
needs these dlls. Probably msvcrt.dll comes from the Msys1 era.

I'll check ASAP with the list of old externals (attached).

Mensaje telepatico asistido por maquinas.

On 1/22/2019 6:51 PM, 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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: deken_w32_filled_2.txt
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20190122/8b203d96/attachment-0001.txt>