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" <[email protected]> > An: "Miller Puckette" <[email protected]> > Cc: [email protected] > 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" <[email protected]> > > An: "IOhannes m zm??lnig" <[email protected]> > > Cc: [email protected] > > 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 > > > [email protected] > > > https://lists.puredata.info/listinfo/pd-dev > > > > > > > > > > _______________________________________________ > > Pd-dev mailing list > > [email protected] > > https://lists.puredata.info/listinfo/pd-dev > > > > > > _______________________________________________ > Pd-dev mailing list > [email protected] > https://lists.puredata.info/listinfo/pd-dev > _______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
