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" <[email protected]> > An: pd-dev <[email protected]> > 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" <[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 > _______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
