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.