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

[Christof Ressi]

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
>