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,_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" <christof.re...@gmx.at><mailto:christof.re...@gmx.at> >> An: pd-dev <pd-dev@lists.iem.at><mailto: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.re...@gmx.at><mailto:christof.re...@gmx.at> >> An: "Miller Puckette" <m...@ucsd.edu><mailto:m...@ucsd.edu> >> Cc: pd-dev@lists.iem.at<mailto: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" <m...@ucsd.edu><mailto:m...@ucsd.edu> >> An: "IOhannes m zm??lnig" <zmoel...@iem.at><mailto:zmoel...@iem.at> >> Cc: pd-dev@lists.iem.at<mailto: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<mailto:Pd-dev@lists.iem.at> >> https://lists.puredata.info/listinfo/pd-dev >> >> >> >> >> >> >> _______________________________________________ >> Pd-dev mailing list >> Pd-dev@lists.iem.at<mailto:Pd-dev@lists.iem.at> >> https://lists.puredata.info/listinfo/pd-dev >> >> >> >> >> >> >> _______________________________________________ >> Pd-dev mailing list >> Pd-dev@lists.iem.at<mailto:Pd-dev@lists.iem.at> >> https://lists.puredata.info/listinfo/pd-dev >> >> >> >> >> >> >> _______________________________________________ >> Pd-dev mailing list >> Pd-dev@lists.iem.at<mailto:Pd-dev@lists.iem.at> >> https://lists.puredata.info/listinfo/pd-dev >> >> >> >> >> >> >> _______________________________________________ >> Pd-dev mailing list >> Pd-dev@lists.iem.at<mailto: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
<<attachment: pdrp-dep-walk.zip>>
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
