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
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
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
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
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" 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
Is pdlibbuilder/mingw statically linking in its own msvcr*?
Yes. --> https://github.com/pure-data/pd-lib-builder/blob/master/Makefile.pdlibbuilde...
I guess you don't want to hear the nightmares of the C-runtimes that are needed to ship if compiling with MSVS. (latest VS compiled stuff running on windows machines without updates, etc)
:)
Mensaje telepatico asistido por maquinas.
On 1/22/2019 7:36 PM, Miller Puckette wrote:
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" 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
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 1/22/19, Miller Puckette msp@ucsd.edu wrote:
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*?
For Windows pdlibbuilder compiles with option "-static-libgcc" (plus "-static-libstdc++" in the case of C++ externals).
Katja
On 1/22/19 11:36 PM, Miller Puckette wrote:
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.
but i think that's really the only sane way. unless you can guarantee that Pd and all externals are built with the same compiler.
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*?
yes, i think so (but i'm really not quite sure).
LDFLAGS="-static-libgcc -shared -Wl,--enable-auto-import $(PDBINDIR)/pd.dll"
sounds like: - statically linking the C-runtime ("-static-libgcc"). - don't search the PDBINDIR for potentially clashing libraries.
but i really don't know.
afaict, Gem really requires to link against msvcrt. and gives me endless troubles, because of this¹. other libraries probably don't (e.g. the pd-lib-builder ones).
gfmad IOhannes
¹and then there's libwinpthread-1.dll, which gives me evenmore headache...but mor eon that another day.
On 1/23/19 12:37 AM, IOhannes m zmölnig wrote:
On 1/22/19 11:36 PM, Miller Puckette wrote:
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.
but i think that's really the only sane way. unless you can guarantee that Pd and all externals are built with the same compiler.
although on re-reading [1],i have serious doubts whether there is any safe way:
If a DLL with the same module name is already loaded in memory, the system checks only for redirection and a manifest before resolving to the loaded DLL, no matter which directory it is in. The system does not search for the DLL.
which i translate to: if any external happens to load a library (e.g. "msvcrt.dll"), then all externals loaded afterwards and depending on a library of the same name are doomed to use the first "msvcrt.dll".
which is of course similar on unix...but there we typically have soversions encoded in the filename which will help resolve this issue.
fgmrdsa IOhannes
[1] https://docs.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-s...
I bet most externs use one or another thing from msvcr*dll. String functions, malloc, etc...
Here's an idea, what if I stuck msvcr*dll in a separate directory and called SetDllDirectory another time in s_loader.c to allow externs to find it if they need it?
M
On Wed, Jan 23, 2019 at 12:37:13AM +0100, IOhannes m zm??lnig wrote:
On 1/22/19 11:36 PM, Miller Puckette wrote:
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.
but i think that's really the only sane way. unless you can guarantee that Pd and all externals are built with the same compiler.
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*?
yes, i think so (but i'm really not quite sure).
LDFLAGS="-static-libgcc -shared -Wl,--enable-auto-import $(PDBINDIR)/pd.dll"
sounds like:
- statically linking the C-runtime ("-static-libgcc").
- don't search the PDBINDIR for potentially clashing libraries.
but i really don't know.
afaict, Gem really requires to link against msvcrt. and gives me endless troubles, because of this??. other libraries probably don't (e.g. the pd-lib-builder ones).
gfmad IOhannes
??and then there's libwinpthread-1.dll, which gives me evenmore headache...but mor eon that another day.
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 1/23/19 12:42 AM, Miller Puckette wrote:
I bet most externs use one or another thing from msvcr*dll. String functions, malloc, etc...
i guess we should wait for lucas to finish his tests.
Here's an idea, what if I stuck msvcr*dll in a separate directory and called SetDllDirectory another time in s_loader.c to allow externs to find it if they need it?
hmm, but SetDllDirectory() only allows us to specify a single additional directory (calling it multiple times will just change this single directory). and we already need it for specifying the plugin-path, so the external can ship its own dependencies - beyond msvcrt.dll
fgmdars IOhannes
Here's an idea, what if I stuck msvcr*dll in a separate directory and called SetDllDirectory another time in s_loader.c to allow externs to find it if they need it?
hmm, but SetDllDirectory() only allows us to specify a single additional directory (calling it multiple times will just change this single directory). and we already need it for specifying the plugin-path, so the external can ship its own dependencies - beyond msvcrt.dll
fgmdars IOhannes
Lame fix would be to try it twice, first the "good" way (looking where the extern is), then as a backup, in .../pd/bullshit where I could hide the old DLs.
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
@Miller:
neither Pd nor any externals built with MinGW (basically every external using pd-lib-builder) depend on the msvcrt.dll (or the msvcr90.dll or pthreadVC.dll) included in pd/bin. externals built with pd-lib-builder don't link against the runtime DLLs shipped with Pd anyway. I've deleted them from the Pd bin folder and everything works fine on several machines.
apart from that, Pd and pure C externals (no matter if compiled with MinGW or VS) only use C functions from the MSVC runtime and this doesn't cause troubles because memory or handles don't cross module boundaries and data structures are well defined. e.g. you must never malloc in one module and free in another because there might be different runtimes involved.
C++ externals compiled with MinGW usually link statically against libstdc++ (or ship the DLL) so there are no missing symbols. C++ externals compiled with VS would ideally link statically (see below), but they should *not* rely on a runtime DLL shipped with Pd. if they do, I would reach out to the maintainer or recompile and upload to Deken. so I would say let's get rid of the runtime DLLs in pd/bin.
@IOhannes:
On 1/22/19 11:36 PM, Miller Puckette wrote:
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.
but i think that's really the only sane way. unless you can guarantee that Pd and all externals are built with the same compiler.
or they can link statically. This is what most VST plugins seem to do. Dependency Walker doesn't show any open dependencies on MSVC runtime libraries on the plugins I've checked. They obviously coexist peacefully in DAWs although they might be from different decades and are mostly written in C++.
afaict, Gem really requires to link against msvcrt.
using Dependency Walker on the recent Gem 0.94 I see that it only uses C symbols from the MSVC, like any other plugin compiled with MinGW, so I don't see a problem here. the C++ symbols come from the libstdc++ which you ship (although you could also link statically). OTOH, the old Gem from Pd extended depended on C++ symbols from msvcr71.dll (I guess because it was compiled with VS) and if that DLL was missing Gem wouldn't load.
Christof
Gesendet: Mittwoch, 23. Januar 2019 um 00:51 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "IOhannes m zm??lnig" zmoelnig@iem.at Cc: pd-dev@lists.iem.at Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
Here's an idea, what if I stuck msvcr*dll in a separate directory and called SetDllDirectory another time in s_loader.c to allow externs to find it if they need it?
hmm, but SetDllDirectory() only allows us to specify a single additional directory (calling it multiple times will just change this single directory). and we already need it for specifying the plugin-path, so the external can ship its own dependencies - beyond msvcrt.dll
fgmdars IOhannes
Lame fix would be to try it twice, first the "good" way (looking where the extern is), then as a backup, in .../pd/bullshit where I could hide the old DLs.
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
to sum it up: msvcrt.dll is always present on the system anyway, so there's no need to ship it with Pd. if an externals relies on msvcr90.dll in pd/bin I would consider this a bug.
Gesendet: Mittwoch, 23. Januar 2019 um 01:54 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: "Miller Puckette" msp@ucsd.edu Cc: pd-dev@lists.iem.at Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
@Miller:
neither Pd nor any externals built with MinGW (basically every external using pd-lib-builder) depend on the msvcrt.dll (or the msvcr90.dll or pthreadVC.dll) included in pd/bin. externals built with pd-lib-builder don't link against the runtime DLLs shipped with Pd anyway. I've deleted them from the Pd bin folder and everything works fine on several machines.
apart from that, Pd and pure C externals (no matter if compiled with MinGW or VS) only use C functions from the MSVC runtime and this doesn't cause troubles because memory or handles don't cross module boundaries and data structures are well defined. e.g. you must never malloc in one module and free in another because there might be different runtimes involved.
C++ externals compiled with MinGW usually link statically against libstdc++ (or ship the DLL) so there are no missing symbols. C++ externals compiled with VS would ideally link statically (see below), but they should *not* rely on a runtime DLL shipped with Pd. if they do, I would reach out to the maintainer or recompile and upload to Deken. so I would say let's get rid of the runtime DLLs in pd/bin.
@IOhannes:
On 1/22/19 11:36 PM, Miller Puckette wrote:
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.
but i think that's really the only sane way. unless you can guarantee that Pd and all externals are built with the same compiler.
or they can link statically. This is what most VST plugins seem to do. Dependency Walker doesn't show any open dependencies on MSVC runtime libraries on the plugins I've checked. They obviously coexist peacefully in DAWs although they might be from different decades and are mostly written in C++.
afaict, Gem really requires to link against msvcrt.
using Dependency Walker on the recent Gem 0.94 I see that it only uses C symbols from the MSVC, like any other plugin compiled with MinGW, so I don't see a problem here. the C++ symbols come from the libstdc++ which you ship (although you could also link statically). OTOH, the old Gem from Pd extended depended on C++ symbols from msvcr71.dll (I guess because it was compiled with VS) and if that DLL was missing Gem wouldn't load.
Christof
Gesendet: Mittwoch, 23. Januar 2019 um 00:51 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "IOhannes m zm??lnig" zmoelnig@iem.at Cc: pd-dev@lists.iem.at Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
Here's an idea, what if I stuck msvcr*dll in a separate directory and called SetDllDirectory another time in s_loader.c to allow externs to find it if they need it?
hmm, but SetDllDirectory() only allows us to specify a single additional directory (calling it multiple times will just change this single directory). and we already need it for specifying the plugin-path, so the external can ship its own dependencies - beyond msvcrt.dll
fgmdars IOhannes
Lame fix would be to try it twice, first the "good" way (looking where the extern is), then as a backup, in .../pd/bullshit where I could hide the old DLs.
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
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
sorry for spamming, but I think this SO question and the given answers shed some more light on the issue:
https://stackoverflow.com/questions/1073509/should-i-redistribute-msvcrt-dll...
TL;DR: programs built with VS can either link statically against the MSVCRT or they have to install the appropiate redistributable package. msvcrt.dll is very old and was declared a private system library which applications should not link against (didn't know that!), but MinGW does anyway. You should certainly *not* redistribute msvcrt.dll.
Christof
PS: since 2015 there are new runtime libraries, e.g. UCRTBASE.DLL and VCRUNTIME140.DLL (https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL,_MS...)
Gesendet: Mittwoch, 23. Januar 2019 um 02:17 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: pd-dev pd-dev@lists.iem.at Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
to sum it up: msvcrt.dll is always present on the system anyway, so there's no need to ship it with Pd. if an externals relies on msvcr90.dll in pd/bin I would consider this a bug.
Gesendet: Mittwoch, 23. Januar 2019 um 01:54 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: "Miller Puckette" msp@ucsd.edu Cc: pd-dev@lists.iem.at Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
@Miller:
neither Pd nor any externals built with MinGW (basically every external using pd-lib-builder) depend on the msvcrt.dll (or the msvcr90.dll or pthreadVC.dll) included in pd/bin. externals built with pd-lib-builder don't link against the runtime DLLs shipped with Pd anyway. I've deleted them from the Pd bin folder and everything works fine on several machines.
apart from that, Pd and pure C externals (no matter if compiled with MinGW or VS) only use C functions from the MSVC runtime and this doesn't cause troubles because memory or handles don't cross module boundaries and data structures are well defined. e.g. you must never malloc in one module and free in another because there might be different runtimes involved.
C++ externals compiled with MinGW usually link statically against libstdc++ (or ship the DLL) so there are no missing symbols. C++ externals compiled with VS would ideally link statically (see below), but they should *not* rely on a runtime DLL shipped with Pd. if they do, I would reach out to the maintainer or recompile and upload to Deken. so I would say let's get rid of the runtime DLLs in pd/bin.
@IOhannes:
On 1/22/19 11:36 PM, Miller Puckette wrote:
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.
but i think that's really the only sane way. unless you can guarantee that Pd and all externals are built with the same compiler.
or they can link statically. This is what most VST plugins seem to do. Dependency Walker doesn't show any open dependencies on MSVC runtime libraries on the plugins I've checked. They obviously coexist peacefully in DAWs although they might be from different decades and are mostly written in C++.
afaict, Gem really requires to link against msvcrt.
using Dependency Walker on the recent Gem 0.94 I see that it only uses C symbols from the MSVC, like any other plugin compiled with MinGW, so I don't see a problem here. the C++ symbols come from the libstdc++ which you ship (although you could also link statically). OTOH, the old Gem from Pd extended depended on C++ symbols from msvcr71.dll (I guess because it was compiled with VS) and if that DLL was missing Gem wouldn't load.
Christof
Gesendet: Mittwoch, 23. Januar 2019 um 00:51 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "IOhannes m zm??lnig" zmoelnig@iem.at Cc: pd-dev@lists.iem.at Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
Here's an idea, what if I stuck msvcr*dll in a separate directory and called SetDllDirectory another time in s_loader.c to allow externs to find it if they need it?
hmm, but SetDllDirectory() only allows us to specify a single additional directory (calling it multiple times will just change this single directory). and we already need it for specifying the plugin-path, so the external can ship its own dependencies - beyond msvcrt.dll
fgmdars IOhannes
Lame fix would be to try it twice, first the "good" way (looking where the extern is), then as a backup, in .../pd/bullshit where I could hide the old DLs.
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
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
Here's a full dependency-walker analysis of all w32 v00-extended Deken:
http://lucarda.com.ar/x/dep-walk-00extended-deken-w32-report.zip
It's one text file per .dll. We can Grep/Findstring to get results that mainly boils down to:
msvcr90.dll -> no match.
msvcr71.dll -> Gem and friends.
pthread -> splits to:
PTHREADGC2.DLL --> some objects.
PTHREADVC.DLL --> Gem and friends. We must consider Oliver's discoveries on this: https://lists.puredata.info/pipermail/pd-list/2018-12/124086.html as there's something strange with this file.
As of "msvcrt.dll" I think Christof had explained everything. My tests deleting this file showed no trouble.
As of "msvcr90.dll" I will randomly search tomorrow on non Pd-extended-era but it could be the case that is not needed, ...
Here are the Pd patches I used to generate batch files for dependency-walker and also to serialize opening and closing *-help.pd files:
http://lucarda.com.ar/x/w32DekenPKGdepWalkCHECK1.zip
@Christof
since 2015 there are new runtime libraries, e.g. UCRTBASE.DLL and VCRUNTIME140.DLL (https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL,_MS...)
I helped Zack Lee's [ofelia] in the early stage a year ago. Basically there's the normal vc_redist.x86.exe but it does not work on machines that don't receive updates (a minority anyway) but theres is work around shipping a lot of dlls. :)
Mensaje telepatico asistido por maquinas.
On 1/22/2019 10:56 PM, Christof Ressi wrote:
sorry for spamming, but I think this SO question and the given answers shed some more light on the issue:
https://stackoverflow.com/questions/1073509/should-i-redistribute-msvcrt-dll...
TL;DR: programs built with VS can either link statically against the MSVCRT or they have to install the appropiate redistributable package. msvcrt.dll is very old and was declared a private system library which applications should not link against (didn't know that!), but MinGW does anyway. You should certainly *not* redistribute msvcrt.dll.
Christof
PS: since 2015 there are new runtime libraries, e.g. UCRTBASE.DLL and VCRUNTIME140.DLL (https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL,_MS...)
Gesendet: Mittwoch, 23. Januar 2019 um 02:17 Uhr Von: "Christof Ressi" christof.ressi@gmx.atmailto:christof.ressi@gmx.at An: pd-dev pd-dev@lists.iem.atmailto:pd-dev@lists.iem.at Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
to sum it up: msvcrt.dll is always present on the system anyway, so there's no need to ship it with Pd. if an externals relies on msvcr90.dll in pd/bin I would consider this a bug.
Gesendet: Mittwoch, 23. Januar 2019 um 01:54 Uhr Von: "Christof Ressi" christof.ressi@gmx.atmailto:christof.ressi@gmx.at An: "Miller Puckette" msp@ucsd.edumailto:msp@ucsd.edu Cc: pd-dev@lists.iem.atmailto:pd-dev@lists.iem.at Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
@Miller:
neither Pd nor any externals built with MinGW (basically every external using pd-lib-builder) depend on the msvcrt.dll (or the msvcr90.dll or pthreadVC.dll) included in pd/bin. externals built with pd-lib-builder don't link against the runtime DLLs shipped with Pd anyway. I've deleted them from the Pd bin folder and everything works fine on several machines.
apart from that, Pd and pure C externals (no matter if compiled with MinGW or VS) only use C functions from the MSVC runtime and this doesn't cause troubles because memory or handles don't cross module boundaries and data structures are well defined. e.g. you must never malloc in one module and free in another because there might be different runtimes involved.
C++ externals compiled with MinGW usually link statically against libstdc++ (or ship the DLL) so there are no missing symbols. C++ externals compiled with VS would ideally link statically (see below), but they should *not* rely on a runtime DLL shipped with Pd. if they do, I would reach out to the maintainer or recompile and upload to Deken. so I would say let's get rid of the runtime DLLs in pd/bin.
@IOhannes:
On 1/22/19 11:36 PM, Miller Puckette wrote:
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.
but i think that's really the only sane way. unless you can guarantee that Pd and all externals are built with the same compiler.
or they can link statically. This is what most VST plugins seem to do. Dependency Walker doesn't show any open dependencies on MSVC runtime libraries on the plugins I've checked. They obviously coexist peacefully in DAWs although they might be from different decades and are mostly written in C++.
afaict, Gem really requires to link against msvcrt.
using Dependency Walker on the recent Gem 0.94 I see that it only uses C symbols from the MSVC, like any other plugin compiled with MinGW, so I don't see a problem here. the C++ symbols come from the libstdc++ which you ship (although you could also link statically). OTOH, the old Gem from Pd extended depended on C++ symbols from msvcr71.dll (I guess because it was compiled with VS) and if that DLL was missing Gem wouldn't load.
Christof
Gesendet: Mittwoch, 23. Januar 2019 um 00:51 Uhr Von: "Miller Puckette" msp@ucsd.edumailto:msp@ucsd.edu An: "IOhannes m zm??lnig" zmoelnig@iem.atmailto:zmoelnig@iem.at Cc: pd-dev@lists.iem.atmailto:pd-dev@lists.iem.at Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
Here's an idea, what if I stuck msvcr*dll in a separate directory and called SetDllDirectory another time in s_loader.c to allow externs to find it if they need it?
hmm, but SetDllDirectory() only allows us to specify a single additional directory (calling it multiple times will just change this single directory). and we already need it for specifying the plugin-path, so the external can ship its own dependencies - beyond msvcrt.dll
fgmdars IOhannes
Lame fix would be to try it twice, first the "good" way (looking where the extern is), then as a backup, in .../pd/bullshit where I could hide the old DLs.
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.atmailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.atmailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.atmailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.atmailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.atmailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Cool.
I have a real tough test in mind - the old PDRP patches which have MSVC- compiled externs in them, with msvcrt.dll dynamically linked (I believe). I'll set up a clean W2K system to test them on and see what happens (and if they don't work without the DLLs in pd/bin/ I can see if my proposed workaround fixes things).
cheers M
On Wed, Jan 23, 2019 at 10:14:39AM +0000, Lucas Cordiviola wrote:
Here's a full dependency-walker analysis of all w32 v00-extended Deken:
http://lucarda.com.ar/x/dep-walk-00extended-deken-w32-report.zip
It's one text file per .dll. We can Grep/Findstring to get results that mainly boils down to:
msvcr90.dll -> no match.
msvcr71.dll -> Gem and friends.
pthread -> splits to:
PTHREADGC2.DLL --> some objects.
PTHREADVC.DLL --> Gem and friends. We must consider Oliver's discoveries on this: https://lists.puredata.info/pipermail/pd-list/2018-12/124086.html as there's something strange with this file.
As of "msvcrt.dll" I think Christof had explained everything. My tests deleting this file showed no trouble.
As of "msvcr90.dll" I will randomly search tomorrow on non Pd-extended-era but it could be the case that is not needed, ...
Here are the Pd patches I used to generate batch files for dependency-walker and also to serialize opening and closing *-help.pd files:
http://lucarda.com.ar/x/w32DekenPKGdepWalkCHECK1.zip
@Christof
since 2015 there are new runtime libraries, e.g. UCRTBASE.DLL and VCRUNTIME140.DLL (https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL,_MS...)
I helped Zack Lee's [ofelia] in the early stage a year ago. Basically there's the normal vc_redist.x86.exe but it does not work on machines that don't receive updates (a minority anyway) but theres is work around shipping a lot of dlls. :)
Mensaje telepatico asistido por maquinas.
On 1/22/2019 10:56 PM, Christof Ressi wrote:
sorry for spamming, but I think this SO question and the given answers shed some more light on the issue:
https://stackoverflow.com/questions/1073509/should-i-redistribute-msvcrt-dll...
TL;DR: programs built with VS can either link statically against the MSVCRT or they have to install the appropiate redistributable package. msvcrt.dll is very old and was declared a private system library which applications should not link against (didn't know that!), but MinGW does anyway. You should certainly *not* redistribute msvcrt.dll.
Christof
PS: since 2015 there are new runtime libraries, e.g. UCRTBASE.DLL and VCRUNTIME140.DLL (https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL,_MS...)
Gesendet: Mittwoch, 23. Januar 2019 um 02:17 Uhr Von: "Christof Ressi" christof.ressi@gmx.atmailto:christof.ressi@gmx.at An: pd-dev pd-dev@lists.iem.atmailto:pd-dev@lists.iem.at Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
to sum it up: msvcrt.dll is always present on the system anyway, so there's no need to ship it with Pd. if an externals relies on msvcr90.dll in pd/bin I would consider this a bug.
Gesendet: Mittwoch, 23. Januar 2019 um 01:54 Uhr Von: "Christof Ressi" christof.ressi@gmx.atmailto:christof.ressi@gmx.at An: "Miller Puckette" msp@ucsd.edumailto:msp@ucsd.edu Cc: pd-dev@lists.iem.atmailto:pd-dev@lists.iem.at Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
@Miller:
neither Pd nor any externals built with MinGW (basically every external using pd-lib-builder) depend on the msvcrt.dll (or the msvcr90.dll or pthreadVC.dll) included in pd/bin. externals built with pd-lib-builder don't link against the runtime DLLs shipped with Pd anyway. I've deleted them from the Pd bin folder and everything works fine on several machines.
apart from that, Pd and pure C externals (no matter if compiled with MinGW or VS) only use C functions from the MSVC runtime and this doesn't cause troubles because memory or handles don't cross module boundaries and data structures are well defined. e.g. you must never malloc in one module and free in another because there might be different runtimes involved.
C++ externals compiled with MinGW usually link statically against libstdc++ (or ship the DLL) so there are no missing symbols. C++ externals compiled with VS would ideally link statically (see below), but they should *not* rely on a runtime DLL shipped with Pd. if they do, I would reach out to the maintainer or recompile and upload to Deken. so I would say let's get rid of the runtime DLLs in pd/bin.
@IOhannes:
On 1/22/19 11:36 PM, Miller Puckette wrote:
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.
but i think that's really the only sane way. unless you can guarantee that Pd and all externals are built with the same compiler.
or they can link statically. This is what most VST plugins seem to do. Dependency Walker doesn't show any open dependencies on MSVC runtime libraries on the plugins I've checked. They obviously coexist peacefully in DAWs although they might be from different decades and are mostly written in C++.
afaict, Gem really requires to link against msvcrt.
using Dependency Walker on the recent Gem 0.94 I see that it only uses C symbols from the MSVC, like any other plugin compiled with MinGW, so I don't see a problem here. the C++ symbols come from the libstdc++ which you ship (although you could also link statically). OTOH, the old Gem from Pd extended depended on C++ symbols from msvcr71.dll (I guess because it was compiled with VS) and if that DLL was missing Gem wouldn't load.
Christof
Gesendet: Mittwoch, 23. Januar 2019 um 00:51 Uhr Von: "Miller Puckette" msp@ucsd.edumailto:msp@ucsd.edu An: "IOhannes m zm??lnig" zmoelnig@iem.atmailto:zmoelnig@iem.at Cc: pd-dev@lists.iem.atmailto:pd-dev@lists.iem.at Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
Here's an idea, what if I stuck msvcr*dll in a separate directory and called SetDllDirectory another time in s_loader.c to allow externs to find it if they need it?
hmm, but SetDllDirectory() only allows us to specify a single additional directory (calling it multiple times will just change this single directory). and we already need it for specifying the plugin-path, so the external can ship its own dependencies - beyond msvcrt.dll
fgmdars IOhannes
Lame fix would be to try it twice, first the "good" way (looking where the extern is), then as a backup, in .../pd/bullshit where I could hide the old DLs.
Pd-dev mailing list Pd-dev@lists.iem.atmailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.atmailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.atmailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.atmailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.atmailto: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
No traces of msvcrt.dll or msvcr90.dll on PDRP. (Attached dep-walker txt files.)
I think bin/msvcrt.dll is safe to delete.
As of "bin/msvcr90.dll": could it be that it's just a leftover from the times when you double-compile with VS and MinGW ? Few externals are compiled with VS and I doubt any developer had ever asked to ship "pd/bin/msvcr90.dll". We know it is not needed/inherited from the pd-extended-era.
:)
Mensaje telepatico asistido por maquinas.
On 1/23/2019 3:30 PM, Miller Puckette wrote:
Cool.
I have a real tough test in mind - the old PDRP patches which have MSVC- compiled externs in them, with msvcrt.dll dynamically linked (I believe). I'll set up a clean W2K system to test them on and see what happens (and if they don't work without the DLLs in pd/bin/ I can see if my proposed workaround fixes things).
cheers M
On Wed, Jan 23, 2019 at 10:14:39AM +0000, Lucas Cordiviola wrote:
Here's a full dependency-walker analysis of all w32 v00-extended Deken:
http://lucarda.com.ar/x/dep-walk-00extended-deken-w32-report.zip
It's one text file per .dll. We can Grep/Findstring to get results that mainly boils down to:
msvcr90.dll -> no match.
msvcr71.dll -> Gem and friends.
pthread -> splits to:
PTHREADGC2.DLL --> some objects.
PTHREADVC.DLL --> Gem and friends. We must consider Oliver's discoveries on this: https://lists.puredata.info/pipermail/pd-list/2018-12/124086.html as there's something strange with this file.
As of "msvcrt.dll" I think Christof had explained everything. My tests deleting this file showed no trouble.
As of "msvcr90.dll" I will randomly search tomorrow on non Pd-extended-era but it could be the case that is not needed, ...
Here are the Pd patches I used to generate batch files for dependency-walker and also to serialize opening and closing *-help.pd files:
http://lucarda.com.ar/x/w32DekenPKGdepWalkCHECK1.zip
@Christof
since 2015 there are new runtime libraries, e.g. UCRTBASE.DLL and VCRUNTIME140.DLL (https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL,_MS...)
I helped Zack Lee's [ofelia] in the early stage a year ago. Basically there's the normal vc_redist.x86.exe but it does not work on machines that don't receive updates (a minority anyway) but theres is work around shipping a lot of dlls. :)
Mensaje telepatico asistido por maquinas.
On 1/22/2019 10:56 PM, Christof Ressi wrote:
sorry for spamming, but I think this SO question and the given answers shed some more light on the issue:
https://stackoverflow.com/questions/1073509/should-i-redistribute-msvcrt-dll...
TL;DR: programs built with VS can either link statically against the MSVCRT or they have to install the appropiate redistributable package. msvcrt.dll is very old and was declared a private system library which applications should not link against (didn't know that!), but MinGW does anyway. You should certainly *not* redistribute msvcrt.dll.
Christof
PS: since 2015 there are new runtime libraries, e.g. UCRTBASE.DLL and VCRUNTIME140.DLL (https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL,_MS...)
Gesendet: Mittwoch, 23. Januar 2019 um 02:17 Uhr Von: "Christof Ressi" christof.ressi@gmx.atmailto:christof.ressi@gmx.at An: pd-dev pd-dev@lists.iem.atmailto:pd-dev@lists.iem.at Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
to sum it up: msvcrt.dll is always present on the system anyway, so there's no need to ship it with Pd. if an externals relies on msvcr90.dll in pd/bin I would consider this a bug.
Gesendet: Mittwoch, 23. Januar 2019 um 01:54 Uhr Von: "Christof Ressi" christof.ressi@gmx.atmailto:christof.ressi@gmx.at An: "Miller Puckette" msp@ucsd.edumailto:msp@ucsd.edu Cc: pd-dev@lists.iem.atmailto:pd-dev@lists.iem.at Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
@Miller:
neither Pd nor any externals built with MinGW (basically every external using pd-lib-builder) depend on the msvcrt.dll (or the msvcr90.dll or pthreadVC.dll) included in pd/bin. externals built with pd-lib-builder don't link against the runtime DLLs shipped with Pd anyway. I've deleted them from the Pd bin folder and everything works fine on several machines.
apart from that, Pd and pure C externals (no matter if compiled with MinGW or VS) only use C functions from the MSVC runtime and this doesn't cause troubles because memory or handles don't cross module boundaries and data structures are well defined. e.g. you must never malloc in one module and free in another because there might be different runtimes involved.
C++ externals compiled with MinGW usually link statically against libstdc++ (or ship the DLL) so there are no missing symbols. C++ externals compiled with VS would ideally link statically (see below), but they should *not* rely on a runtime DLL shipped with Pd. if they do, I would reach out to the maintainer or recompile and upload to Deken. so I would say let's get rid of the runtime DLLs in pd/bin.
@IOhannes:
On 1/22/19 11:36 PM, Miller Puckette wrote:
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.
but i think that's really the only sane way. unless you can guarantee that Pd and all externals are built with the same compiler.
or they can link statically. This is what most VST plugins seem to do. Dependency Walker doesn't show any open dependencies on MSVC runtime libraries on the plugins I've checked. They obviously coexist peacefully in DAWs although they might be from different decades and are mostly written in C++.
afaict, Gem really requires to link against msvcrt.
using Dependency Walker on the recent Gem 0.94 I see that it only uses C symbols from the MSVC, like any other plugin compiled with MinGW, so I don't see a problem here. the C++ symbols come from the libstdc++ which you ship (although you could also link statically). OTOH, the old Gem from Pd extended depended on C++ symbols from msvcr71.dll (I guess because it was compiled with VS) and if that DLL was missing Gem wouldn't load.
Christof
Gesendet: Mittwoch, 23. Januar 2019 um 00:51 Uhr Von: "Miller Puckette" msp@ucsd.edumailto:msp@ucsd.edu An: "IOhannes m zm??lnig" zmoelnig@iem.atmailto:zmoelnig@iem.at Cc: pd-dev@lists.iem.atmailto:pd-dev@lists.iem.at Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
Here's an idea, what if I stuck msvcr*dll in a separate directory and called SetDllDirectory another time in s_loader.c to allow externs to find it if they need it?
hmm, but SetDllDirectory() only allows us to specify a single additional directory (calling it multiple times will just change this single directory). and we already need it for specifying the plugin-path, so the external can ship its own dependencies - beyond msvcrt.dll
fgmdars IOhannes
Lame fix would be to try it twice, first the "good" way (looking where the extern is), then as a backup, in .../pd/bullshit where I could hide the old DLs.
Pd-dev mailing list Pd-dev@lists.iem.atmailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.atmailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.atmailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.atmailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.atmailto: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
On 24.01.19 08:25, Lucas Cordiviola wrote:
Few externals are compiled with VS
where do you get that metric from?
Pd-extended compiled everything with mingw, so *there* was indeed no VS involved. this spilled over to the packages available via deken.
but i figure that there is quite a number of externals out there, that are not available via deken. for instance, here at the iem, we do a bit of Pd development, and those working with windows used to almost exclusively compile with VS. (for years i'm trying to nudge them towards mingw, with varied success. since i deployed a CI system, numbers are shifting)
gmasdr IOhannes
I've finished scanning all the packages from "deken_w32_filled_2.txt" attached earlier on this thread which covers all Deken as of july 2016. No traces of "msvcr90.dll".
@IOhannes: Can you generate a new .txt with all w32 pkgs?
I'll gladly scan the rest.
:)
Mensaje telepatico asistido por maquinas.
On 1/25/19 12:13 PM, Lucas Cordiviola wrote:
I've finished scanning all the packages from "deken_w32_filled_2.txt" attached earlier on this thread which covers all Deken as of july 2016. No traces of "msvcr90.dll".
@IOhannes: Can you generate a new .txt with all w32 pkgs?
I'll gladly scan the rest.
$ deken find --arch "Windows-*-*" | sed -n -e 's|^.*\bURL: (.*(Windows-.*)|\1|p' | sort -u
gives me the attached list (including those you already scanned).
gfdsam IOhannes
$ deken find --arch "Windows-*-*" | sed -n -e 's|^.*\bURL: (.*(Windows-.*)|\1|p' | sort -u
gives me the attached list (including those you already scanned).
I found missing pkgs from your list but I got a complete one using deken (cancelling a download a binking prompt appears on the deken's windows results so I use SHIFT+arrows ).
I've scanned all w32-deken (attached list) and "msvcr90.dll" hits only "soundhack-v0.0.8"
I've crated a page on puredata.info containing the full scanned output :
http://puredata.info/Members/lucarda/w32-dep-wak-deken-2019/
:)
Mensaje telepatico asistido por maquinas.
On 1/23/19, Christof Ressi christof.ressi@gmx.at wrote:
msvcrt.dll is very old and was declared a private system library which applications should not link against (didn't know that!), but MinGW does anyway.
This SO thread may clarify why MinGW does depend on msvcrt.dll:
https://stackoverflow.com/questions/27451875/going-on-with-no-msvcrt-dll
Summarizing what I understand from it, libgcc / stdlibc++ cannot provide certain runtime-dependent functions for the Windows operating system, like exception handling, function overloading etc. Apparently MinGW links to msvcrt.dll for these by default.
The msvcrt.dll as provided by Windows is not old in itself, but for the purpose of compatibility best considered as such, tells this text here:
https://sourceforge.net/p/mingw-w64/wiki2/The%20case%20against%20msvcrt.dll/
Reliance on recently added language features should probably be treated like any non-standard dependency. In the context of vanilla Pd and deken, externals must take care of their own non-standard dependencies anyhow.
Katja
P.S. this would at least provide compatibility with old externs; then, if new externs all were compiled staticly-linked to their own libc versions, everybody might be able to get along together.
Actually, I do wonder about malloc() - how can different versions of that coexist? It makes my head hurt to think about that...
M
On Tue, Jan 22, 2019 at 03:42:36PM -0800, Miller Puckette wrote:
I bet most externs use one or another thing from msvcr*dll. String functions, malloc, etc...
Here's an idea, what if I stuck msvcr*dll in a separate directory and called SetDllDirectory another time in s_loader.c to allow externs to find it if they need it?
M
On Wed, Jan 23, 2019 at 12:37:13AM +0100, IOhannes m zm??lnig wrote:
On 1/22/19 11:36 PM, Miller Puckette wrote:
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.
but i think that's really the only sane way. unless you can guarantee that Pd and all externals are built with the same compiler.
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*?
yes, i think so (but i'm really not quite sure).
LDFLAGS="-static-libgcc -shared -Wl,--enable-auto-import $(PDBINDIR)/pd.dll"
sounds like:
- statically linking the C-runtime ("-static-libgcc").
- don't search the PDBINDIR for potentially clashing libraries.
but i really don't know.
afaict, Gem really requires to link against msvcrt. and gives me endless troubles, because of this??. other libraries probably don't (e.g. the pd-lib-builder ones).
gfmad IOhannes
??and then there's libwinpthread-1.dll, which gives me evenmore headache...but mor eon that another day.
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
On 1/23/19, Miller Puckette msp@ucsd.edu wrote:
I bet most externs use one or another thing from msvcr*dll. String functions, malloc, etc...
I've always naively assumed that MinGW's libgcc and libstdc++ are a full replacement for MS standard libs (which notably do not include pthread). Pd-extended builds for Windows provide a shared libgcc_s_dw2-1.dll and libstdc++6.dll:
https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/packages/win32_inno/...
For MinGW-built externals in the context of deken, static linking with standard libs seems easiest. However I should have mentioned that superbloated binaries may be produced when not stripped.
Katja
-
Christof Ressi -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
katja -
Lucas Cordiviola -
Miller Puckette