Re: [Mingw-cross-env-list] Xerces library problem

[Volker Grabsch]

tek <address@hidden> schrieb:
> -rw-r--r-- 1 tek tek    8 Jul 11 04:11 usr/i686-pc-mingw32/lib/libxerces-c.a
> -rwxr-xr-x 1 tek tek 1528 Jul 11 04:11 usr/i686-pc-mingw32/lib/libxerces-c.la
>
> Note the size fields. So, it did not work. Checking logs for xerces  
> build, I noticed these lines of interest:
>
> libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 
> shared libraries
> libtool: link: i686-pc-mingw32-ar cru .libs/libxerces-c.a
> libtool: link: i686-pc-mingw32-ranlib .libs/libxerces-c.a
>
> Searching on the web led me to the assumption that -no-undefined (or  
> --no-undefined) should be given to the linker options when building  
> Xerces may resolve the issue.

That would merely convert the warning to an error message. It
would make the issue more prominent, but it wouldn't solve it.

However, I just provided a test program for Xerces, so that we'll
notice immediately if that bug occurs on any of our test systems:

http://hg.savannah.gnu.org/hgweb/mingw-cross-env/rev/249a63832bc8
http://hg.savannah.gnu.org/hgweb/mingw-cross-env/rev/356964dc9085

> I just wonder: is something broken in mingw-cross-env with Xerces or did  
> I miss something?

On my Debian 64-bit system Xerces is built correctly:

$ ls -l usr/i686-pc-mingw32/lib/libxerces-c.*
-rw-r--r-- 1 vog vog 35907988 Jun 16 01:33 usr/i686-pc-mingw32/lib/libxerces-c.a
-rwxr-xr-x 1 vog vog     1380 Jun 16 01:33 
usr/i686-pc-mingw32/lib/libxerces-c.la


I'm also actively using Xerces in a project, and it works flawlessly.
Please check whether your system meets the requirements:

    http://mingw-cross-env.nongnu.org/#requirements

Also, please tell us what system exactly you are using, and send your
complete "log/xerces" to us (compressed). That allows us to compare
your log with the logs of a successful build, making subtle differences
easier to spot.

> My project also makes intensive use of SDL without  
> problems (well, at least no error reported about it either in  
> mingw-cross-env and my project link time) and OpenGL with minor problems  
> (it mostly has to do with GL shader calls, I'll deal with it in time).

In case you have any fixes to the header files, feel free to
contribute them to the MinGW and MinGW-w64 projects.

> My second question is: do you think I should use the Debian package  
> mingw32 instead of mingw-cross-env? Are there some drawbacks (besides  
> the fact I would have to deal manually with a few builds)?

I recommend to give Mingw-cross-env a try, because that way many
people will profit from your improvements to e.g. the Xerces build
script.

However, even if you build Xerces "by hand", it would be great if
you'd provide your exact build commands to us. Those might help us
to fix our Xerces build script.

Note that building the cross-compiler is very easy compared to
cross-compiling all the libraries, especially to cross-compile
_static_ versions of the libraries. So it doesn't really matter
whether you use Debian's mingw32, or ours, or build it yourself.
It's all about the libraries.

There are essentially two alternatives to Mingw-cross-env.

First, the SuSE build system seems to provide mingw32 cross compilers
as well as ports of many libraries. I haven't tried it myself, and I
don't know which libraries they support. If you are interested in that,
the people on the MinGW-users mailing list might help you.

(There is also a Debian win32 cross-compiling project, but it doesn't
work well. I originally tried to base Mingw-cross-env on dpkg-cross,
but I had to add special cases for Windows at all edges and corners,
so I gave and and simply put them into a separate script - and
Mingw-cross-env was born.)

Second, you could try to compile them natively, using Wine or a native
Windows system. In fact I considered basing Mingw-cross-env on Wine
rather than cross compilers, but I decided not to go that route, for
performance reasons as well as to be independent of big packages like
Wine. That way you can abvoid many cross-compiling specific issues,
but in your concrete case I guess something else went wrong.


Greets,
Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR