This is the mail archive of the
mailing list for the Cygwin project.
Re: MinGW cross-compiler: missing libraries
- From: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
- To: cygwin at cygwin dot com
- Date: Tue, 14 Jun 2011 13:49:50 -0400
- Subject: Re: MinGW cross-compiler: missing libraries
- References: <4DF795DC.email@example.com>
- Reply-to: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
On 6/14/2011 1:09 PM, Zouzou wrote:
> I would first like to congratulate everyone involved in getting the
> long-awaited MinGW cross-compiler out. Much appreciated.
> There is a program I would like to compile with it, that depends on the
> bfd and iberty libraries. These are provided by a standard MinGW install
> (with "mingw-get install gcc") but are not part of the MinGW
> cross-compiler packages in Cygwin.
> I have checked the mingw64 packages and they don't seem to contain these
> libraries either.
> Have I missed a dependency, or are they just not part of the distribution?
They are not part of the distribution. There is a libiberty.a in
/usr/i686-pc-mingw32/lib/ but IIRC that is a "host" library (e.g.
cygwin, not mingw) and really should not have been included in the
It's usually a bad idea to rely on a pre-compiled version of the iberty
library, because even if you did have a $target version, it was
configured and compiled for the needs of the original package (that is,
binutils or gcc) that provided it -- which may not match your needs.
Plus, it is licensed as pure GPL IIRC, *without* the runtime exception
-- so linking it makes your app GPL by the viral nature (this may be ok,
but you need to realize that). [This pure GPLness also applies to
For portability, use http://www.gnu.org/software/gnulib/ instead of
libiberty. FWIW, there is currently talk on the gcc lists about
eliminating any installation of libiberty for any purpose, and treating
it entirely as an internal "convenience library" (to use the libtool
Also, remember that if you link the libbfd.a static library, you not
only must distribute YOUR sources to all recipients of your compiled
app, but ALSO you must distribute the sources of libbfd! That's one
reason why the rebase package defines its own mechanisms for parsing the
PE/COFF header instead of linking to libbfd -- even though rebase itself
is GPL, it's just a PAIN to worry about libbfd's sources. Since rebase's
needs were limited, libbfd is a bit of overkill anyway...so, rebase
rolls its own PE/COFF routines.
With regards to the difference between mingw.org's compiler packages
including these two libraries, and cygwin's cross compiler packages NOT
including them, well:
1) for mingw.org, $host == $target, so the $host libiberty works when
used as a $target lib. However, as mentioned above, it really shouldn't
be installed anyway, gcc-4.7 probably won't install it, so don't count
on it being there in the future, even in the mingw.org packages.
2) for libbfd -- I suspect this too is a $host library. It is possible
for $compiler-maintainer to build libbfd for $target, and install it --
but I think it is probably better, in the long run, that you do so
yourself if your app needs that library, even when using the mingw.org
native toolchain. That way you can control how it is built -- AND
ensure that you satisfy the GPL for it by shipping JUST its sources (and
not ALL of binutils or gcc). I don't know *exactly* how to do this
(short of 'cvs -d:<sourceware repository> co bfd'), but a little
experimentation and google-fu should be sufficient.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple