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