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" lucarda27@hotmail.com An: "Christof Ressi" christof.ressi@gmx.at, pd-dev pd-dev@lists.iem.at 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" 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