libiberty.{a,h} again..

Greg Schafer gschafer at
Thu Feb 13 22:43:13 PST 2003


I know this has been hashed to death before but I find myself revisiting
this issue yet again.

I propose we drop installation of libiberty.{a.h} altogether.

Apart from the now obsolete objprelink, can anyone name a single program
that depends on an already installed libiberty?

Consider this is a challenge! :-)

For your information, this page suggests we should not be installing it:-

AFAICT, RH do istall it in their distro. Debian do as well. It is part of
their "binutils-dev" package. I just searched their "Packages.gz" for woody
and there are only 4 bizarre looking "kernel-patch" type packages that
depend on binutils-dev and even then it appears they need some libbfd headers
and not libiberty.

Can anyone put up a good case why we should keep libiberty? The fact that
both gcc and binutils install libiberty.a is a bug in both packages IMHO.

Please, no discussion on c++filt, which is a different issue altogether.

Unsubscribe: send email to listar at
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list