[PD-dev] removing pd/bin/msvr*.dll from Pd/win

[IOhannes m zmölnig]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20190122/82ab0fed/attachment.sig>