> 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.
Thanks for testing! just to make sure: *all* Pd externals compiled with MinGW have a dependency on MSVCRT.DLL but they use only C functions and it doesn't have to be the version shipped with Pd. the version doesn't matter as long as they don't do stupid things like freeing memory or closing a file handle obtained from another module (which you should never do anyway, unless you're 100% sure everything was compiled with the very same compiler). what you could check, though, is if plugins depend on a msvcr*.dll (e.g. msvcr90.dll) because this would mean they have been compiled with VS but haven't linked statically. you could also check if externals depend on any C++ symbols from MSVC runtime libraries. Christof > Gesendet: Dienstag, 22. Januar 2019 um 23:22 Uhr > Von: "Lucas Cordiviola" <[email protected]> > An: "Christof Ressi" <[email protected]>, pd-dev <[email protected]> > Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win > > 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" <[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
