C++ externals fail on Windows

[umlaeute]

just taking @katjav's comment in #39 to a new issue:

All went fine, except one thing: Pd wouldn't load the C++ object in my test set (it works fine on Linux).
I haven't got the opportunity to figure out why but intuition says 'name mangling troubles'.
I don't know how Pd (from Miller's distribution) was built.

[umlaeute]

hmm: putting the _setup function into an extern "C" { /* ... */ } block should allow to see the host (Pd) any symbols exported from the external - but this should apply equally to linux and msw.

the other way round (making Pd symbols available to externals) needs to do the same (but it already does).
otoh, i thought that the linking stage would fail if pd.dll doesn't provide all the required symbols (but mingw/gcc might shadow that somehow).

[Lucarda]

@umlaeute @katjav

Some Tests not using pd-lib-builder:

I was able to finish compile of PDContainer (sources from extended (cpp)) against Millers's 0.48-1.

But I'm unable to load it (same trouble as @katjav) but I'm on win8.1 so I get some clue from the OS popup:

Edit1 : So I tried compiling against my Msys2 build of 0.48-1. But I get the same errors.

[katjav]

Today I booted an ancient XP box with Pd-extended 0.42 installed and an old pdlibbuilder. Similar issue there but the system gave a clue: libgcc_s_dw2-1.dll was not found. It could be resolved by statically linking the standard C lib using option -static-libgcc.

Currently I don't have access to the Windows 64 box I was using yesterday but I guess the same option would make it work there.

[katjav]

So, pdlibbuilder has never worked for C++ on Windows? This pd-list message may point to the same issue although it isn't specific:

https://lists.puredata.info/pipermail/pd-list/2016-11/116972.html

Would any C++ class for Pd need the C lib just because of the extern "C" thing?

[Lucarda]

I was able to de-mess the thing.

In my case libgcc_s_dw2-1.dll is not an issue as i have it installed on system folders, thats why I didn't get the popup "missing dll".
My problem get solved when I copied libstdc++-6.dll from Msys2/*/bin to the [external] folder (where PDContainer.dll is located).
This type of mess is not easy to debug. The thing is that PDContainer.dll was connecting to a wrong (older?) libstdc++-6.dll located on the normal place for that, windows/syswow64, syswow64 is for global 32bit.dlls on a 64bit OS.

So now I get the [external] loaded and running.

I was able to detect this using http://www.dependencywalker.com/ it showed that libstdc++-6.dll was loaded but it was "red" indicating "something" :: that "entry point" thing that stopped Pd from loading the [external].
Heres how it look now. Showing all deps.:

There is some search order for deps in windows.

1 same dir as the calling dll
2 same dir as the Main program
3 global system folder.

These are all the libstdc++-6.dll in my "not clean for tests" win8.1 machine. Showing different versions, sizes, etc

These are the flags from the original Makefile.

CC_FLAGS = -DPD -DWINDOWS -c -mms-bitfields -Wall
LD_FLAGS = -export-dynamic -shared -o

I'm unable to translate by myself this Makefile to be used with pd-lib-builder. It's a single binary from many sources.

[Lucarda]

I was able to get rid of the deps adding -static-libgcc -static-libstdc++ :

CC_FLAGS = -DPD -DWINDOWS -c -mms-bitfields -Wall
LD_FLAGS = -static-libgcc -static-libstdc++ -export-dynamic -shared -o

[Lucarda]

Good News

I've transported the -static-libgcc -static-libstdc++ to a 64bit build. It worked perfect on 1st try.

It would be nice to get rid of "libwinpthread-1.dll" but this is not happening "out-of-the-box" with MinGW64. Details so far on #36

[Lucarda]

I have reopened #36 because is orthogonal to this: ie static linking.
And is working also on w64. : )

[katjav]

Summarizing what we found so far:

1. standard C and C++ libs are both required for C++ externals in our tests
2. global libstdc++-6.dll incompatible with libstdc++-6.dll from Msys2

Because of issue 2 pdlibbuilder already links standard libraries statically:

• -static-libgcc for C code
• -static-libstdc++ for C++ code

I was hoping that we could get rid of these binary code duplicates in the future if vanilla Pd could provide .dlls for standard libs. But at least for the moment it rather seems that we have to build more duplicate code into externals, that is: standard C libs into C++ objects, to solve the first issue.

[Lucarda]

global libstdc++-6.dll incompatible with libstdc++-6.dll from Msys2

Windows "pristine" machines does not have any of those dlls. The incompatibility comes when some older software had installed those dlls on global folders.

I was hoping that we could get rid of these binary code duplicates in the future if vanilla Pd could provide .dlls for standard libs.

Recent (since a couple of years) Pds for windows were compiled using static C and C++ libs to avoid this issue so Pd don't ship those.

The New Coming Pd (is very most likely to get merged) also use static libs:

pure-data/pure-data@51088cd

You will be very happy to read the latests news on this same PR: pure-data/pure-data#299

Summarizing -static-libgcc -static-libstdc++ looks the way to go.

[katjav]

Commit f1b0e3c adds -static-libgcc for C++ externals on Windows, which should fix the current issue.

[umlaeute]

indirectly related, i found that statically linking libc/libstdc++ will give serious troubles when using exceptions.
e.g. https://stackoverflow.com/a/42162114/1169096