On 10/01/2010 10:30 AM, Erik van Pienbroek wrote:
Op vrijdag 01-10-2010 om 09:36 uur [tijdzone -0700], schreef John
Stebbins:
> Is this a known issue? Anyone else seen it?
Hi John,
This looks like a known issue.
The .dll.a file is an import library which only contains a list of
symbols which are exported in the .DLL. The regular .a file is a static
library which doesn't care about exported symbols (iow: all symbols are
exported).
There are some bugs in zlib 1.2.3 which prevent some symbols from being
exported in the dll/dll.a files. One of the affected libraries of this
bug is the latest glib, see [1] for details. To fix this, I've updated
zlib to 1.2.5 in Fedora 14 and rawhide. I might update the zlib package
in Fedora 13 as well if there's a demand for it, but I don't have any
plans to update the Fedora 12 package as that release is reaching
end-of-life.
Thanks for the info. Nice to know it's a solved problem.
Hmm, I am running fedora 13 (upgraded from 12). yum doesn't seem to think there is an
fc13 package for zlib. In fact,
the versions I have are from an old rawhide repo I have since disabled.
mingw32-zlib.noarch 1.2.3-19.fc12 @rawhide/11.92
mingw32-zlib-static.noarch 1.2.3-19.fc12 @rawhide/11.92
Removing those and reinstalling produces:
mingw32-zlib.noarch 1.2.3-19.fc12 @fedora
mingw32-zlib-static.noarch 1.2.3-19.fc12 fedora
Is something configured wrong someplace?
You can try to manually install the Fedora 14 package of
mingw32-zlib
(which can be found at [2]) and see if the libxml2 build succeeds with
it.
Yes, this works.
Speaking of which, why are you building libxml2? We've already
got a
mingw32-libxml2 package in Fedora which works fine. If you want to help
with maintaining the package, feel free to apply for it in pkgdb.
Our application is cross platform, and as such, the build system is also designed
to be cross platform. The maintainer
of the windows code actually uses mingw on osx to build releases, so he must build
libxml2. I build on fedora to help
out with the occasional bug.