I bet most externs use one or another thing from msvcr*dll. String functions, malloc, etc...
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? M On Wed, Jan 23, 2019 at 12:37:13AM +0100, IOhannes m zm??lnig wrote: > 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. > > > > > 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*? > > yes, i think so (but i'm really not quite sure). > > LDFLAGS="-static-libgcc -shared -Wl,--enable-auto-import $(PDBINDIR)/pd.dll" > > sounds like: > - statically linking the C-runtime ("-static-libgcc"). > - don't search the PDBINDIR for potentially clashing libraries. > > but i really don't know. > > afaict, Gem really requires to link against msvcrt. > and gives me endless troubles, because of this??. > other libraries probably don't (e.g. the pd-lib-builder ones). > > > gfmad > IOhannes > > ??and then there's libwinpthread-1.dll, which gives me evenmore > headache...but mor eon that another day. > > _______________________________________________ > 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