Cross compiling tests

[Hans Leidekker]

Hi,

I'm trying to cross compile the regression tests using MinGW as a 
cross compiler (i.e. I have installed the MinGW cross compiler on 
Linux and run 'make crosstest').

First problem I encountered was that my versions of the compiler and 
dlltool weren't detected at configure stage. Mine are called 
i386-mingw-gcc and i386-mingw-dlltool, whereas configure looks for 
i586-mingw32msvc-gcc and i586-mingw32msvc-dlltool. I've sent a patch
to wine-patches that adds the former names to the configure check.

Second major problem happens at the build stage. The Makefile for
a test specifies -L$(DLLDIR) when linking the test executables, which
is where the *Wine* libraries reside. I think this is wrong, we 
should link against the target platform libraries (MinGW in this
case) when cross compiling.

Removing -L$(DLLDIR) from the Makefile also solves a conflict that
arises from the fact that both MinGW and Wine have an implementation 
of the C runtime:

make crosstest
i386-mingw32-gcc generated.cross.o testlist.cross.o -o urlmon_crosstest.exe -L../../../dlls  -lurlmon -lm
../../../dlls/libmsvcrt.a(ds00443.o)(.text+0x0): multiple definition of `atexit'
/usr/local/lib/gcc-lib/i386-mingw32/3.2.2/../../../../i386-mingw32/lib/crt2.o(.text+0x230):/usr/src/redhat/BUILD/mingw-2.4/mingw-runtime-2.4/crt1.c:266: first defined here
../../../dlls/libmsvcrt.a(ds00319.o)(.text+0x0): multiple definition of `_onexit'
/usr/local/lib/gcc-lib/i386-mingw32/3.2.2/../../../../i386-mingw32/lib/crt2.o(.text+0x250):/usr/src/redhat/BUILD/mingw-2.4/mingw-runtime-2.4/crt1.c:274: first defined here

Patch sent to wine-patches. Now most tests happily compile ;-). I
have two tests left that have problems linking. It appears that they
use symbols that are not available in any import library (not even Wine's):

i386-mingw32-gcc dsound.cross.o testlist.cross.o -o dsound_crosstest.exe  -ldsound -luser32 -lkernel32 -lm
dsound.cross.o(.text+0x1656): In function `dsenum_callback':
/usr/local/src/wine-cvs/wine/dlls/dsound/tests/dsound.c:403: undefined reference to `wine_dbgstr_guid'
dsound.cross.o(.text+0x24dd): In function `dscenum_callback':
/usr/local/src/wine-cvs/wine/dlls/dsound/tests/dsound.c:649: undefined reference to `wine_dbgstr_guid'
make: *** [dsound_crosstest.exe] Error 1

The wine_ prefix suggests that this is a Wine internal function, so 
it will never be avaliable on Windows/MinGW. Can these be removed?
Or is there an alternative that works on all platforms? This is the
other one that fails:

i386-mingw32-gcc safearray.cross.o vartest.cross.o testlist.cross.o -o oleaut32_crosstest.exe  -loleaut32 -lm
safearray.cross.o(.text+0x1496): In function `func_safearray':
/usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:277: undefined reference to `IID_IUnknown'
safearray.cross.o(.text+0x14d1):/usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:278: undefined reference to `IID_IUnknown'
safearray.cross.o(.text+0x150e):/usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:281: undefined reference to `IID_IDispatch'
safearray.cross.o(.text+0x1549):/usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:282: undefined reference to `IID_IDispatch'
make: *** [oleaut32_crosstest.exe] Error 1

Same problem I guess. Any suggestion as to how this one might be fixed
is welcome.

-Hans

[Steven Edwards]

> Removing -L$(DLLDIR) from the Makefile also solves a conflict that
> arises from the fact that both MinGW and Wine have an implementation 
> of the C runtime:
>
> make crosstest
> i386-mingw32-gcc generated.cross.o testlist.cross.o -o urlmon_crosstest.exe -L../../../dlls 
> -lurlmon -lm
> ../../../dlls/libmsvcrt.a(ds00443.o)(.text+0x0): multiple definition of `atexit'

/usr/local/lib/gcc-lib/i386-mingw32/3.2.2/../../../../i386-mingw32/lib/crt2.o(.text+0x230):/usr/src/redhat/BUILD/mingw-2.4/mingw-runtime-2.4/crt1.c:266:
> first defined here
> ../../../dlls/libmsvcrt.a(ds00319.o)(.text+0x0): multiple definition of `_onexit'

/usr/local/lib/gcc-lib/i386-mingw32/3.2.2/../../../../i386-mingw32/lib/crt2.o(.text+0x250):/usr/src/redhat/BUILD/mingw-2.4/mingw-runtime-2.4/crt1.c:274:
> first defined here

Yes this is a known bug. Mingw includes its own C exit code. I have been meaning to email them
about this.
> i386-mingw32-gcc dsound.cross.o testlist.cross.o -o dsound_crosstest.exe  -ldsound -luser32
> -lkernel32 -lm
> dsound.cross.o(.text+0x1656): In function `dsenum_callback':
> /usr/local/src/wine-cvs/wine/dlls/dsound/tests/dsound.c:403: undefined reference to
> `wine_dbgstr_guid'
> dsound.cross.o(.text+0x24dd): In function `dscenum_callback':
> /usr/local/src/wine-cvs/wine/dlls/dsound/tests/dsound.c:649: undefined reference to
> `wine_dbgstr_guid'
> make: *** [dsound_crosstest.exe] Error 1
>
> The wine_ prefix suggests that this is a Wine internal function, so 
> it will never be avaliable on Windows/MinGW. Can these be removed?
> Or is there an alternative that works on all platforms? This is the
> other one that fails:

No this builds fine on Mingw for Windows if you import libwine. Is there something wrong with your
workaround. You still need to link to the files in wine/lib.
> i386-mingw32-gcc safearray.cross.o vartest.cross.o testlist.cross.o -o oleaut32_crosstest.exe 
> -loleaut32 -lm
> safearray.cross.o(.text+0x1496): In function `func_safearray':
> /usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:277: undefined reference to
> `IID_IUnknown'

safearray.cross.o(.text+0x14d1):/usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:278:
> undefined reference to `IID_IUnknown'

safearray.cross.o(.text+0x150e):/usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:281:
> undefined reference to `IID_IDispatch'

safearray.cross.o(.text+0x1549):/usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:282:
> undefined reference to `IID_IDispatch'
> make: *** [oleaut32_crosstest.exe] Error 1
>
> Same problem I guess. Any suggestion as to how this one might be fixed
> is welcome.

I think this is the same thing. The static and dynamic libraries in wine/lib are still needed in
some cases even if you use the w32api package and not wines import libs.

Thanks
Steven

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com

[Hans Leidekker]

On Sat, 12 Apr 2003, Steven Edwards wrote:

[MinGW linking error]
> Yes this is a known bug. Mingw includes its own C exit code. I have been meaning to email them
> about this.

OK thanks. But is it really a bug? Don't other compilers do that as well? 
If so I think we should be able to cope with that.

[Another linking error]
> > The wine_ prefix suggests that this is a Wine internal function, so 
> > it will never be avaliable on Windows/MinGW. Can these be removed?
> > Or is there an alternative that works on all platforms? This is the
> > other one that fails:
>
> No this builds fine on Mingw for Windows if you import libwine. Is there something wrong with your
> workaround. You still need to link to the files in wine/lib.

I see, but wine/lib is not in the Makefile for the crosstest target. So 
I'm starting to wonder if anyone is ever seeing a 'make crosstest' finish
successfully? Do you use the Wine Makefile?

[Another linking error]
> I think this is the same thing. The static and dynamic libraries in wine/lib are still needed in
> some cases even if you use the w32api package and not wines import libs.

I'll look into that. Thanks again for your comments.

-Hans

[Alexandre Julliard]

Hans Leidekker  writes:
> Second major problem happens at the build stage. The Makefile for
> a test specifies -L$(DLLDIR) when linking the test executables, which
> is where the *Wine* libraries reside. I think this is wrong, we 
> should link against the target platform libraries (MinGW in this
> case) when cross compiling.

The problem is that Mingw doesn't include import libraries for all the
dlls we need, so some tests will fail to link. A better solution might
be to give priority to Mingw libraries while still falling back to the
Wine ones if needed.

[Hans Leidekker]

On 12 Apr 2003, Alexandre Julliard wrote:
> > Second major problem happens at the build stage. The Makefile for
> > a test specifies -L$(DLLDIR) when linking the test executables, which
> > is where the *Wine* libraries reside. I think this is wrong, we 
> > should link against the target platform libraries (MinGW in this
> > case) when cross compiling.
>
> The problem is that Mingw doesn't include import libraries for all the
> dlls we need, so some tests will fail to link. A better solution might
> be to give priority to Mingw libraries while still falling back to the
> Wine ones if needed.

Well, of the dlls that have a test in Wine MinGW only misses urlmon. If
you look at the objective of cross compiling a test, it would normally
not make sense to cross compile a target that needs a library that the
target platform lacks. But of course this situation different: the test
executable is going run on Windows, not MinGW (though that may change
someday...)

So I guess -L$(DLLDIR) is going to stay and MinGW needs to be fixed so
it can properly link our tests. I'm keeping my fingers crossed ;-)

-Hans

[Alexandre Julliard]

Hans Leidekker  writes:
> Well, of the dlls that have a test in Wine MinGW only misses urlmon.

Yes this seems to have improved, it used to miss a lot more. I'm sure
the Mingw guys would welcome a patch to add urlmon...
> If you look at the objective of cross compiling a test, it would normally
> not make sense to cross compile a target that needs a library that the
> target platform lacks. But of course this situation different: the test
> executable is going run on Windows, not MinGW (though that may change
> someday...)

Well, the import libraries are supposed to be compatible across
Wine/Mingw/Windows, so it shouldn't matter which ones we use. And
trying different combinations is a good way to spot problems, so there
isn't a "right" one to use. I agree that using the Mingw libraries
would be preferable, at least for testing Wine; but using the Wine
libraries is a good way to test Mingw...

[Hans Leidekker]

On 12 Apr 2003, Alexandre Julliard wrote:
> Well, the import libraries are supposed to be compatible across
> Wine/Mingw/Windows, so it shouldn't matter which ones we use. And
> trying different combinations is a good way to spot problems, so there
> isn't a "right" one to use. I agree that using the Mingw libraries
> would be preferable, at least for testing Wine; but using the Wine
> libraries is a good way to test Mingw...

I see. So in a way the Wine regression testing framework includes 
testing the linking phase, not just the executing phase.

[Hans Leidekker]

On 12 Apr 2003, Alexandre Julliard wrote:
> The problem is that Mingw doesn't include import libraries for all the
> dlls we need, so some tests will fail to link. A better solution might
> be to give priority to Mingw libraries while still falling back to the
> Wine ones if needed.

What about this one then? The MinGW linker has an option that allows us
to fudge errors of type "multiple definitions of 'atexit'". With this 
patch tests link against Wine *and* MinGW import libraries, so more tests
compile, link and run.

urlmon is OK now since we still link against Wine imports. Thanks to 
your patch to the dsound test that one is OK too. Only one left failing
is oleaut32. I'm working on getting that one fixed as well. The
natively built test needs libuuid which is specified in $(EXTRALIBS),
but $(EXTRALIBS) is not specified in the linking target for cross 
compiled tests.

Index: configure.ac
===================================================================
RCS file: /home/wine/wine/configure.ac,v
retrieving revision 1.148
diff -u -r1.148 configure.ac
--- configure.ac	12 Apr 2003 00:00:57 -0000	1.148
+++ configure.ac	13 Apr 2003 19:52:21 -0000
@@ -846,11 +846,16 @@

dnl Check for cross compiler to build test programs
     AC_SUBST(CROSSTEST,"")
+    AC_SUBST(LDCROSSFLAGS,"")
     if test "$cross_compiling" = "no"
     then
       AC_CHECK_PROGS(CROSSCC,i586-mingw32msvc-gcc i386-mingw32-gcc,false)
       AC_CHECK_PROGS(DLLTOOL,i586-mingw32msvc-dlltool i386-mingw32-dlltool,false)
-      if test "$CROSSCC" != "false"; then CROSSTEST="$(CROSSTEST)"; fi
+      if test "$CROSSCC" != "false"
+      then
+        CROSSTEST="$(CROSSTEST)"
+        LDCROSSFLAGS="-Wl,--allow-multiple-definition"
+      fi
     fi
     ;;
 esac
Index: dlls/Maketest.rules.in
===================================================================
RCS file: /home/wine/wine/dlls/Maketest.rules.in,v
retrieving revision 1.21
diff -u -r1.21 Maketest.rules.in
--- dlls/Maketest.rules.in	23 Mar 2003 01:12:31 -0000	1.21
+++ dlls/Maketest.rules.in	13 Apr 2003 19:52:21 -0000
@@ -26,6 +26,7 @@

CROSSTEST    = $(TESTDLL:%.dll=%)_crosstest.exe
 CROSSOBJS    = $(C_SRCS:.c=.cross.o) $(TESTLIST:.c=.cross.o)
+LDCROSSFLAGS = @LDCROSSFLAGS@

@MAKE_RULES@

@@ -64,7 +65,7 @@
 crosstest:: @CROSSTEST@

$(CROSSTEST): $(CROSSOBJS) Makefile.in
-	$(CROSSCC) $(CROSSOBJS) -o $@ -L$(DLLDIR) $(DELAYIMPORTS:%=-l%) $(IMPORTS:%=-l%) $(LIBS)
+	$(CROSSCC) $(LDCROSSFLAGS) $(CROSSOBJS) -o $@ -L$(DLLDIR) $(DELAYIMPORTS:%=-l%) $(IMPORTS:%=-l%) $(LIBS)

# Rules for cleaning

[Hans Leidekker]

Something strange is going on with the mailing lists. I sent my last
mail to [e-mail], and cc:ed [e-mail]. Now
I see that both mails end up on [e-mail]. How's that?

-Hans

[Alexandre Julliard]

Hans Leidekker  writes:
> What about this one then? The MinGW linker has an option that allows us
> to fudge errors of type "multiple definitions of 'atexit'". With this 
> patch tests link against Wine *and* MinGW import libraries, so more tests
> compile, link and run.

I think your original idea of using only Mingw libraries was better;
we just need to get an import lib for urlmon into Mingw. If there are
incompatibilities we want them to break the link process, your new
patch will hide them instead.

[Hans Leidekker]

On Monday 14 April 2003 21:35, Alexandre Julliard wrote:
> I think your original idea of using only Mingw libraries was better;
> we just need to get an import lib for urlmon into Mingw. If there are
> incompatibilities we want them to break the link process, your new
> patch will hide them instead.

Yes it does, and I somehow expected this answer ;-) I've resent the
other patch that removes -L$(DLLDIR) from the cross compile target.

-Hans