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@iem.at An: "PureData developer's list" pd-dev@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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev