With the advent of 20050930 wine can no longer load the shared libraries used by my winelib app. Are there any docs or descriptions about how to deal with this change?
I have an app that gets built into, say, ./app/app.exe.so. It uses a shared library, say ./lib/liblib.so, that uses win32 APIs. To build ./lib/liblib.so I just compiled and linked using gcc.
To build app.exe.so I would use winebuild to scan the object files at ./app/*.o and ./lib/*.o. That created wrappers for all the win32 functions both in ./app and ./lib. The wrappers code from winebuild gets linked in to app.exe.so. Wine used to be able to deal with this. With 20050930 wine complains that the win32 references in liblib.so can't be resolved and quits.
I am guessing that something about wine dll loading has changed, so that the function wrappers for a wine DLL have to be in the file itself. That is, I would have to run winebuild on the lib object files, create lib.dll.so and then link app.exe.so against that.
I started down this path with some success and then realized that, gulp, I would have to create a spec file for my libraries. Hundreds of C++ functions in several libraries. If this is indeed required, is there any help in building a spec file? Is it possible to export C++ functions as opposed to straight C?
Winelib has always been the wild and woolly frontier. We haven't been bitten in a while; I guess we were due! ... mo
Michael Ost most@museresearch.com writes:
I started down this path with some success and then realized that, gulp, I would have to create a spec file for my libraries. Hundreds of C++ functions in several libraries. If this is indeed required, is there any help in building a spec file? Is it possible to export C++ functions as opposed to straight C?
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.
On Fri, 2005-10-07 at 11:02, Alexandre Julliard wrote:
Michael Ost most@museresearch.com writes:
I started down this path with some success and then realized that, gulp, I would have to create a spec file for my libraries. Hundreds of C++ functions in several libraries. If this is indeed required, is there any help in building a spec file? Is it possible to export C++ functions as opposed to straight C?
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.
OK. That's right. But I'm still flailing trying to build my winelib app with 20050930. Could you tell me what's missing from the steps below? Or point me to some docs? This used to work in 20050419, except that I had to compile the C output from winebuild. A million thanks. ... mo
* junk.cpp #include <stdio.h> #include <windows.h> int main(int argc, char* argv[]) { ::MessageBox(NULL, "Howdy World", "Junk", MB_OK); return(0); }
* build steps $ cc -I/usr/include/wine/windows -c junk.cpp -o junk.o $ winebuild --exe -o junk.spec.o --filename junk.exe.so -L/usr/lib/wine junk.o -luser32 $ g++ -shared -o junk.exe.so junk.o junk.spec.o
* run it $ wine ./junk.exe.so wine: could not load L"Z:\home\most\cvs-muse\sandbox\mo\junk\junk.exe.so": /home/most/.wine/dosdevices/z:/home/most/cvs-muse/sandbox/mo/junk/junk.exe.so: undefined symbol: __wine_spec_init_ctor
Michael Ost most@museresearch.com writes:
OK. That's right. But I'm still flailing trying to build my winelib app with 20050930. Could you tell me what's missing from the steps below? Or point me to some docs? This used to work in 20050419, except that I had to compile the C output from winebuild. A million thanks. ... mo
You need to link against libwinecrt0.a. Though using winegcc would probably be easier, it takes care of all that for you.
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
Michael Ost most@museresearch.com writes:
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 problem is that they resolve to the same symbols in the dll. Something like this should fix it:
Index: dlls/winecrt0/crt0_private.h =================================================================== RCS file: /opt/cvs-commit/wine/dlls/winecrt0/crt0_private.h,v retrieving revision 1.3 diff -u -p -r1.3 crt0_private.h --- dlls/winecrt0/crt0_private.h 2 Sep 2005 14:43:03 -0000 1.3 +++ dlls/winecrt0/crt0_private.h 12 Oct 2005 14:02:15 -0000 @@ -36,6 +36,6 @@ enum init_state CONSTRUCTORS_DONE /* the constructors have been run (implies dll registered too) */ };
-extern enum init_state __wine_spec_init_state; +extern enum init_state __wine_spec_init_state __attribute__((visibility ("hidden")));
#endif /* __WINE_CRT0_PRIVATE_H__ */
On Wed, 2005-10-12 at 07:08, Alexandre Julliard wrote:
The problem is that they resolve to the same symbols in the dll. Something like this should fix it:
That did it! Thanks... mo
-
Alexandre Julliard -
Michael Ost