On Fri, 2005-10-07 at 11:02, Alexandre Julliard wrote:
You shouldn't need to export them, you can still link to the library directly at the Unix level, a Winelib dll is still an ELF library.
You are right, and using winegcc helped alot. I can link, but ... then the program crashes when it runs. I attached a bash script that demonstrates the problem. It builds two winelib apps: "good" and "bad". "bad" has the problem and won't run. "good" doesn't, and will.
It seems that winebuild --exe is not working correctly when linking if there are no winelib DLLs with exports.... or perhaps it's still user error %) ?
The winebuild step triggered by wineg++ is not generating __wine_spec_init or __wine_dll_register entry points. These entry points *are* made if there are exports in the shared library's spec file. The entry points should be pulled in with libwinecrt0.a, since they are defined there. But they are not and I can't figure out why.
The .exe.so file is created without complaints, but when you try to run it it seg faults. The crash is related to the absent __wine_spec_init entry point. I found where (in kernel/process.c) and will submit a patch to make wine quit gracefully in such a case, by the way.
The 'nm' output of the two looks very similar except bad.exe.so: * has no __wine_spec_init * has no __wine_dll_register * has undefined __wine_spec_init_ctor * has undefined __wine_spec_init_state
I'm so close! Hopefully it's just some little missing param or something. I am guessing that making Wine calls in a shared library without exports is not common, but that's how our code works. I am hoping that it's your intention that it work... or else I gotta spec out hundreds and hundreds of mangled C++ function names!
- mo