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