Under solaris I get some undefined references popping up from yesterdays cvs (that I'm not used to seeing). Undefined first referenced symbol in file GetStartupInfoA ../../dlls/libwinecrt0.a(exe_main.o) GetModuleHandleA ../../dlls/libwinecrt0.a(exe_main.o) GetCommandLineA ../../dlls/libwinecrt0.a(exe_main.o) WinMain ../../dlls/libwinecrt0.a(exe_main.o)
I'm used to seeing main undefined in libraries (presumably because the abblications using the dlls define the symbol), but not this collection. the wine executable fails with
wine: failed to initialize: ld.so.1: wine: fatal: relocation error: file /opt/cfw/wine/lib/wine/ntdll.dll.so: symbol GetCommandLineA: referenced symbol not found
Which seems to suggest it shouldn't be this way. Apparently there is a library that isn't being linked properly somewhere.
Bob
On Wednesday 05 October 2005 07:27, Robert Lunnon wrote:
Under solaris I get some undefined references popping up from yesterdays cvs (that I'm not used to seeing). Undefined first referenced symbol in file GetStartupInfoA ../../dlls/libwinecrt0.a(exe_main.o) GetModuleHandleA ../../dlls/libwinecrt0.a(exe_main.o) GetCommandLineA ../../dlls/libwinecrt0.a(exe_main.o) WinMain ../../dlls/libwinecrt0.a(exe_main.o)
I'm used to seeing main undefined in libraries (presumably because the abblications using the dlls define the symbol), but not this collection. the wine executable fails with
wine: failed to initialize: ld.so.1: wine: fatal: relocation error: file /opt/cfw/wine/lib/wine/ntdll.dll.so: symbol GetCommandLineA: referenced symbol not found
Which seems to suggest it shouldn't be this way. Apparently there is a library that isn't being linked properly somewhere.
Bob
Hmm, wierd, seems those symbols are contained in kernel32.dll.so but the dependency isn't declared in the other libraries, and kernel32 is loaded after ntdll (or not at all)
Robert Lunnon bobl@optushome.com.au writes:
Under solaris I get some undefined references popping up from yesterdays cvs (that I'm not used to seeing). Undefined first referenced symbol in file GetStartupInfoA ../../dlls/libwinecrt0.a(exe_main.o) GetModuleHandleA ../../dlls/libwinecrt0.a(exe_main.o) GetCommandLineA ../../dlls/libwinecrt0.a(exe_main.o) WinMain ../../dlls/libwinecrt0.a(exe_main.o)
I'm used to seeing main undefined in libraries (presumably because the abblications using the dlls define the symbol), but not this collection. the wine executable fails with
If main() is undefined then the new winecrt0 will define it and bring in these symbols. It sounds like there is a problem with the link command, main() shouldn't be referenced at all when building dlls.
On Wednesday 05 October 2005 21:09, Alexandre Julliard wrote:
Robert Lunnon bobl@optushome.com.au writes:
Under solaris I get some undefined references popping up from yesterdays cvs (that I'm not used to seeing). Undefined first referenced symbol in file GetStartupInfoA ../../dlls/libwinecrt0.a(exe_main.o) GetModuleHandleA ../../dlls/libwinecrt0.a(exe_main.o) GetCommandLineA ../../dlls/libwinecrt0.a(exe_main.o) WinMain ../../dlls/libwinecrt0.a(exe_main.o)
I'm used to seeing main undefined in libraries (presumably because the abblications using the dlls define the symbol), but not this collection. the wine executable fails with
If main() is undefined then the new winecrt0 will define it and bring in these symbols. It sounds like there is a problem with the link command, main() shouldn't be referenced at all when building dlls.
Yes, thats the way I see it, from what I can see winegcc is being called with -shared but is not emitting -shared in the subsequent gcc command and includes libwinecrt0.a which would be wrong for linking a shared library. Seems winegcc is broken.
Bob
Robert Lunnon bobl@optushome.com.au writes:
Yes, thats the way I see it, from what I can see winegcc is being called with -shared but is not emitting -shared in the subsequent gcc command and includes libwinecrt0.a which would be wrong for linking a shared library. Seems winegcc is broken.
Including libwinecrt0.a is correct, it contains the runtime for both dlls and exes. The -shared flag is not defined in LDDLLFLAGS for Solaris, so it sounds that it's the configure check that is wrong.
On Wednesday 05 October 2005 21:44, Alexandre Julliard wrote:
Robert Lunnon bobl@optushome.com.au writes:
Yes, thats the way I see it, from what I can see winegcc is being called with -shared but is not emitting -shared in the subsequent gcc command and includes libwinecrt0.a which would be wrong for linking a shared library. Seems winegcc is broken.
Including libwinecrt0.a is correct, it contains the runtime for both dlls and exes. The -shared flag is not defined in LDDLLFLAGS for Solaris, so it sounds that it's the configure check that is wrong.
Yes, fixed that but the linker still insists on including main() in the shared library. If I remove libwinecrt0.a from the link then the link goes OK and nm shows no references to main() in the shared library. Perhaps wine should have different runtime startofffs for shared objects and executables like gcc does for executable objects now at least this will remove any reliance on linker behaviour?
Robert Lunnon bobl@optushome.com.au writes:
Yes, fixed that but the linker still insists on including main() in the shared library. If I remove libwinecrt0.a from the link then the link goes OK and nm shows no references to main() in the shared library. Perhaps wine should have different runtime startofffs for shared objects and executables like gcc does for executable objects now at least this will remove any reliance on linker behaviour?
Well, we could add a dummy main() to make the linker happy, but I'd really like to understand where that reference comes from.
On Wednesday 05 October 2005 22:49, Alexandre Julliard wrote:
Robert Lunnon bobl@optushome.com.au writes:
Yes, fixed that but the linker still insists on including main() in the shared library. If I remove libwinecrt0.a from the link then the link goes OK and nm shows no references to main() in the shared library. Perhaps wine should have different runtime startofffs for shared objects and executables like gcc does for executable objects now at least this will remove any reliance on linker behaviour?
Well, we could add a dummy main() to make the linker happy, but I'd really like to understand where that reference comes from.
libwine.so references main it's linked through the -lwine argument to winegcc.
On Thursday 06 October 2005 23:15, Robert Lunnon wrote:
On Wednesday 05 October 2005 22:49, Alexandre Julliard wrote:
Robert Lunnon bobl@optushome.com.au writes:
Yes, fixed that but the linker still insists on including main() in the shared library. If I remove libwinecrt0.a from the link then the link goes OK and nm shows no references to main() in the shared library. Perhaps wine should have different runtime startofffs for shared objects and executables like gcc does for executable objects now at least this will remove any reliance on linker behaviour?
Well, we could add a dummy main() to make the linker happy, but I'd really like to understand where that reference comes from.
libwine.so references main it's linked through the -lwine argument to winegcc.
I think I have it licked! Before I fixed configure.ac to pass the right -shared flag to gcc I had built and installed libwine, the linker was resolving this old copy which because of the bad switch was including crt0.o which references main. I'd better purge myself of the old bad shared libraries
Arrrgh, well at least its solved now.
Bob
On Wednesday 05 October 2005 21:09, Alexandre Julliard wrote:
Robert Lunnon bobl@optushome.com.au writes:
Under solaris I get some undefined references popping up from yesterdays cvs (that I'm not used to seeing). Undefined first referenced symbol in file GetStartupInfoA ../../dlls/libwinecrt0.a(exe_main.o) GetModuleHandleA ../../dlls/libwinecrt0.a(exe_main.o) GetCommandLineA ../../dlls/libwinecrt0.a(exe_main.o) WinMain ../../dlls/libwinecrt0.a(exe_main.o)
I'm used to seeing main undefined in libraries (presumably because the abblications using the dlls define the symbol), but not this collection. the wine executable fails with
If main() is undefined then the new winecrt0 will define it and bring in these symbols. It sounds like there is a problem with the link command, main() shouldn't be referenced at all when building dlls.
Aha, I understand, on SysV winegcc adds -Wl,-G to link a shared library but doesn't add -shared so gcc (which doesn't know about the linker commands includes the c runtime startoff crt0.o which of course defines main, so the linker dutifully includes main in the shared library.
Not good
Bob
-
Alexandre Julliard -
Robert Lunnon