--disable-install-libiberty and libiberty.a

[Matt Burgess]

Hi all,

libiberty.a is built and installed by a number of packages, such as
binutils, gcc, gdb.  When packaging for an OS, it's desirable to only
have libiberty.a installed by one package to avoid conflicts as to which
package 'owns' the file.  Related to this are the following questions:

1) We currently assume that binutils is 'upstream' for libiberty
development, and should therefore 'own' the libiberty.a file.  Is that
assumption correct?

2) The --disable-install-libiberty configure switch for GCC does *not*
suppress the installation of libiberty.a (see also [0] and [1]).  It's
unclear whether it should as the './configure --help' output only
mentions the suppression of header installation, but libiberty.texi
mentions the suppression of libiberty.a as well.  Do folks here think
that '--disable-install-libiberty' should suppress installation of the
archive as well as the headers?  If so, is the fact that it doesn't a
GCC bug or a binutils bug (if the assumption in 1. above holds, I'd also
assume that the copy of libiberty in GCC's source tree is taken verbatim
from there, and therefore this is a binutils bug).

Thanks,

Matt.

[0] http://sourceware.org/bugzilla/show_bug.cgi?id=9422 (GDB bug)
[1] http://trac.macports.org/ticket/23216 (avr-binutils bug)

Re: --disable-install-libiberty and libiberty.a

[Matt Burgess]

On Fri, 2013-03-29 at 06:13 -0700, Ian Lance Taylor wrote:
> On Fri, Mar 29, 2013 at 1:35 AM, Matt Burgess
>  wrote:
> >
> > 1) We currently assume that binutils is 'upstream' for libiberty
> > development, and should therefore 'own' the libiberty.a file.  Is that
> > assumption correct?
> 
> No.  The master sources for libiberty are in the GCC repository.

OK, thanks, that's useful to know.

> > 2) The --disable-install-libiberty configure switch for GCC does *not*
> > suppress the installation of libiberty.a (see also [0] and [1]).
> 
> I agree that --disable-install-libiberty should prevent installing
> libiberty.a.  This would then be a GCC bug.

Thanks for confirming.  This is now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56780.

Regards,

Matt.