> 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" <zmoel...@iem.at> >>> An: "PureData developer's list" <pd-dev@lists.iem.at> >>> 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 >>> >>> <techdetails> >>> 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. >>> </techdetails> >>> >>> 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 _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev