[PD-dev] removing pd/bin/msvr*.dll from Pd/win

[Miller Puckette]

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 at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev