Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
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-with-my-application 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,_MSVCP*.DLL_and_CRTDLL.DLL) > Gesendet: Mittwoch, 23. Januar 2019 um 02:17 Uhr > Von: "Christof Ressi" > An: pd-dev > 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" > > An: "Miller Puckette" > > 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" > > > An: "IOhannes m zm??lnig" > > > 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 > > > >
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" > An: "Miller Puckette" > 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" > > An: "IOhannes m zm??lnig" > > 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
Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
> 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"
> An: "Christof Ressi" , pd-dev
> 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"
> >> An: "PureData developer's list"
> >> 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
> >>
> >>
> >> 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.
> >>
> >>
> >> 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,
Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
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
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
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 signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
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
Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
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.
signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
On 1/22/19, Miller Puckette 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 ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
> Is pdlibbuilder/mingw statically linking in its own msvcr*?
Yes. -->
https://github.com/pure-data/pd-lib-builder/blob/master/Makefile.pdlibbuilder#L638
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"
>>> An: "PureData developer's list"
>>> 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
>>>
>>>
>>> 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.
>>>
>>>
>>> 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
>
>
>
Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
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"
> > An: "PureData developer's list"
> > 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
> >
> >
> > 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.
> >
> >
> > 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
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"
>> An: "PureData developer's list"
>> 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
>>
>>
>> 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.
>>
>>
>> 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
(deken
http://puredata.info/Members/avilleret/software/Jamoma/1.0-beta3/Jamoma-v1.0-beta3-(Windows-i386-32)-externals.zip
nottested
http://puredata.info/Members/chr15m/freeverb~(Windows-i386-32)-externals.zip ok
http://puredata.info/Members/chr15m/pdlua(Windows-i386-32)-externals.zip ok
http://puredata.info/Members/chr15m/plugin~(Windows-i386-32)-externals.zip
libdl.dll
http://puredata.info/Members/chr15m/software/v0-0extended/adaptive/adaptive-v0.0.extended-(Windows-i386-32)-externals.zip
ok
http://puredata.info/Members/chr15m/software/v0-0extended/arraysize/arraysize-v0.0.extended-(Windows-i386-32)-externals.zip
ok
http://puredata.info/Members/chr15m/software/v0-0extended/bassemu~/bassemu~-v0.0.extended-(Windows-i386-32)-externals.zip
ok
Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
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"
> An: "PureData developer's list"
> 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
>
>
> 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.
>
>
> 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] 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
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.
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
signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
