Eric Frias wrote:
Does anyone have a solution they're happy with?
<>Not happy and is a bit out of dated but it Looks it could still work today.
Do a .spec file for each C++ dll with one c function like: void mydll_export( ) { } // you need real code + .spec declaration
In your app or in the dlls that use the above dll do a function like: void using_ddls() { mydll_export( ) ; mydll2_export() ; } // this code forces the winebuild to pull-in listed dlls as well
link every thing the regular wine way this way DLLS load in the right order, get initialized, and their Windows "import tables", like calls to kernel32 etc, gets initialized by the loader. But (and here is where I'm out of dated) also specify the .so as a link option to the gcc linker. (ld)
In the old system, before winegcc. One would do -lmydll on the winebuild command line. And than in turn -lmydll on the ld command line - for resolve of C++ symbols. Now that we use winegcc I'm not sure what is the switch for additional libs like .so and static libs. Look maybe it is documented. (Dimi how do you add external libs to a winelib link stage under winegcc?)
But be careful with this approach. It is an order of a magnitude slower on load time than DLL linkage on windows. I came to a dead end with one of my projects, where I managed to compile and run every thing but I had to revert to PE compiled code because it took my app 4-6 minutes to load. (PE takes 40 seconds). It was a 1.2 M lines of C++ code divided in to 37 DLLs + MFC in a dll.
We have talked about the right solution with Alexander on Wineconf. What he suggested was: 1 - make the __declspec( export ) macro expand to a gcc "section" declaration. So the compilers put all of them in a special section. No one knew how C++ classes behave with "sections" and we suspected each member function has to be put into the section by hand. On windows a __declspec( export ) on the class declaration automatically exports all members. Maybe MinGW could help out here.
2 - Use a tool like nm or readelf to extract all symbols (including C++), in above section, and with a script convert them to a .spec file.
3- I think that current winebuild have problems with some variants of the C++ mangled symbols like the use of the "@" character. So maybe a new "C++" style function should be added to the .spec syntax, that will not try to interpret the symbols.
Free life Boaz