Re: winelib .so change in 20050930?
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
set -x
cat EOF shared.cpp
#include windows.h
#include unistd.h
void show_window()
{
char bufr[128];
gethostname(bufr, sizeof(bufr));
strcat(bufr, says, 'Howdy World!');
::MessageBox(NULL, bufr, App, MB_OK);
}
EOF
wineg++ -c shared.cpp -o shared.o
cat EOF app.cpp
#include stdio.h
extern void show_window();
int main(int argc, char* argv[])
{
show_window();
return(0);
}
EOF
wineg++ -c app.cpp -o app.o
echo shared.spec
wineg++ -shared shared.spec shared.o -o libshared.dll.so
wineg++ -o bad.exe.so app.o -L`pwd` -lshared.dll
wineg++ -o bad bad.exe.so
echo '@ stdcall _Z11show_windowv()' shared.spec
wineg++ -shared shared.spec shared.o -o shared.dll.so
winebuild -w --def -o libshared.def --export shared.spec
wineg++ app.o -o good.exe.so -L`pwd` -lshared
wineg++ -o good good.exe.so
set +x
echo CRASHES: LD_LIBRARY_PATH=`pwd` ./bad
echo WORKS: ./good
Re: winelib .so change in 20050930?
Michael Ost [EMAIL PROTECTED] 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.h2 Sep 2005 14:43:03 - 1.3 +++ dlls/winecrt0/crt0_private.h12 Oct 2005 14:02:15 - @@ -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 [EMAIL PROTECTED]
Re: winelib .so change in 20050930?
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
Re: winelib .so change in 20050930?
Michael Ost [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: winelib .so change in 20050930?
On Fri, 2005-10-07 at 11:02, Alexandre Julliard wrote:
Michael Ost [EMAIL PROTECTED] 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
LZ:\\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
Re: winelib .so change in 20050930?
Michael Ost [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
