[PD-dev] removing pd/bin/msvr*.dll from Pd/win
msp at ucsd.edu
Wed Jan 23 00:42:36 CET 2019
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?
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).
> ??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
More information about the Pd-dev