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