Hi,
When I run a 'make crosstest' using MingW I get errors like these:
/usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:289: undefined reference to `IID_IUnknown' safearray.cross.o(.text+0x1814):/usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:290: undefined reference to `IID_IUnknown'
What's happening is that this test references symbols that reside in wine_uuid, which is added to the library search path for the regular Wine build, but left out in the crosscompile build. For good reasons, because wine_uuid is built as a Unix archive, not as an import library, which is what MingW needs.
So I created an import library from the Unix archive:
nm libwine_uuid.a | egrep -v "^$" | egrep -v "^*.o:$" | cut -d" " -f 3 \
wine_uuid.def
i386-mingw32-dlltool -l wine_uuid.lib -d ./wine_uuid.def
And I had a working executable. But this obviously is not the way Wine does it. Wine generates .def files from .spec files. To use Wine's build system I had to create a new dll -- uuid -- and copy the sources over from libs/uuid. This gave me a Wine generated import library.
Next I added uuid as an import library to the Makefile for the oleaut32 test and removed wine_uuid from EXTRALIBS. Did this solve my problem? No it didn't. Because, as it turns out, winebuild does not support importing non-function entry points, such as IID_IUnknown. After googling around a bit I have to conclude that this is quite a fundamental problem. If I understand it correctly, it's because in this case PE style linking can not be emulated using the ELF linker.
Then I decided to bypass linking and go with LoadLibraryA and GetProcAddress, which are already used in the tests to find the functions to be tested. This finally gave me a uniform build system for regular and crosscompiled tests.
My question is, is this acceptable for integration into Wine? The consequence would be that, to be consistent, all parts of Wine that are now linked with wine_uuid would need to be converted. Or is such consistency maybe considered less important than getting crosscompiled tests going?
-Hans
Hans Leidekker hans@it.vu.nl writes:
What's happening is that this test references symbols that reside in wine_uuid, which is added to the library search path for the regular Wine build, but left out in the crosscompile build. For good reasons, because wine_uuid is built as a Unix archive, not as an import library, which is what MingW needs.
IMO the right approach is to use Mingw's libuuid. You shouldn't need to cross compile the Wine one at all.
On Monday 19 May 2003 19:24, Alexandre Julliard wrote:
Hans Leidekker hans@it.vu.nl writes:
What's happening is that this test references symbols that reside in wine_uuid, which is added to the library search path for the regular Wine build, but left out in the crosscompile build. For good reasons, because wine_uuid is built as a Unix archive, not as an import library, which is what MingW needs.
IMO the right approach is to use Mingw's libuuid. You shouldn't need to cross compile the Wine one at all.
I didn't make myself clear enough. I am using MinGW's libuuid for linking the cross compiled test. And I'm not cross compiling Wine's wine_uuid, but converted it to a Wine dll and did a regular compile, as for any Wine dll. This way both cross compiled and non-cross compiled executables can be linked by just specifying -luuid.
You see MinGW has a libuuid because MS development environments have a uuid.lib. So I concluded that Wine should have a libuuid import lib. When I asked earlier on this list I got the hint that the Wine testing framework includes testing conformance of the linking stage.
Anyway, as I described in my previous mail, going this way I ran into serious trouble with winebuild as it doesn't support importing non-function entry points. Is that maybe the reason wine_uuid is linked as a Unix library?
We could do it differently, say by introducing a Makefile variable CROSSIMPORTS:
CROSSIMPORTS = $(IMPORTS) uuid
And change the cross compile target accordingly:
$(CROSSTEST): $(CROSSOBJS) Makefile.in $(CROSSCC) $(CROSSOBJS) -o $@ $(CROSSIMPORTS:%=-l%) $(LIBS)
Would that be an acceptable alternative?
-Hans
Hans Leidekker hans@it.vu.nl writes:
I didn't make myself clear enough. I am using MinGW's libuuid for linking the cross compiled test. And I'm not cross compiling Wine's wine_uuid, but converted it to a Wine dll and did a regular compile, as for any Wine dll. This way both cross compiled and non-cross compiled executables can be linked by just specifying -luuid.
You see MinGW has a libuuid because MS development environments have a uuid.lib. So I concluded that Wine should have a libuuid import lib.
No, libuuid is not an import lib, it's a normal static library. And Wine does have one, only it's named wine_uuid to avoid conflicts with the Unix libuuid. It's true that ideally -luuid should work in all cases. Currently it's handled by winegcc, but this doesn't work when building Wine itself since we don't use winegcc yet.
A possibility is to create some extra symlinks to make -luuid work; another would be to rename the Wine library to libuuid and install it in /usr/lib/wine so that it doesn't conflict with the Unix one. This would be more elegant, but it may be a bit more confusing to people who don't set their library path properly.
On 20 May 2003, Alexandre Julliard wrote:
A possibility is to create some extra symlinks to make -luuid work; another would be to rename the Wine library to libuuid and install it in /usr/lib/wine so that it doesn't conflict with the Unix one. This would be more elegant, but it may be a bit more confusing to people who don't set their library path properly.
Yet another prossibility is to cut to the chase and use winegcc to build wine as well :)
-
Alexandre Julliard -
Dimitrie O. Paun -
Hans Leidekker