winelib .so change in 20050930?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

winelib .so change in 20050930?

Michael Ost
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



Reply | Threaded
Open this post in threaded view
|

Re: winelib .so change in 20050930?

Alexandre Julliard
Michael Ost <[hidden email]> 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.

--
Alexandre Julliard
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: winelib .so change in 20050930?

Michael Ost
On Fri, 2005-10-07 at 11:02, Alexandre Julliard wrote:

> Michael Ost <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: winelib .so change in 20050930?

Alexandre Julliard
Michael Ost <[hidden email]> 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.

--
Alexandre Julliard
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: winelib .so change in 20050930?

Michael Ost
In reply to this post by Alexandre Julliard
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




show-winelib-problem.sh (934 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: winelib .so change in 20050930?

Alexandre Julliard
Michael Ost <[hidden email]> 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__ */

--
Alexandre Julliard
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: winelib .so change in 20050930?

Michael Ost
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