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" <[email protected]> > > An: "PureData developer's list" <[email protected]> > > 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 > > [email protected] > > https://lists.puredata.info/listinfo/pd-dev > > > > > > _______________________________________________ > Pd-dev mailing list > [email protected] > https://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
