Reinstate installation of libiberty.a (and .h)

[greg@…]

See the thread starting here for details (and a suggested gcc patch):-

​http://linuxfromscratch.org/pipermail/lfs-dev/2003-August/036143.html

[jeremy@…]

We should get this back in for LFS 5.0, if possible

[jeremy@…]

Consensus on the list was to leave this one out. libiberty developers say that if it's included, the package should provide it's own code, and we want to stick with that.

[greg@…]

I'm sorry Jeremy but I do not see any consensus on the list and therefore disagree with you.

I've only recently noticed that the new website lists me as "LFS Toolchain Maintaner" (which BTW makes me feel honoured :-) and makes me somewhat tempted to "pull rank" on this one.

The history of libiberty.{a,h} inclusion was due to the needs by apps. When the old "objprelink" became obsolete then so did the need for libiberty.{a,h}. Now that there is clear evidence of other current apps needing libiberty.{a,h} then I think we are doing a dis-service to LFS builders by not including them. Sure, this flies in the face of the wishes of the lib's maintainer, but if we are "fair dinkum" then we will do what is right for the users (which also happens to emulate what the 2 big distros are doing). LFS-4.1 includes them. Only current CVS does not.

I will be the first to say "I told you so" the first time someone mentions they weren't able to compile a pkg coz we don't include libiberty.{a,h}

/me boggles at the irony of arguing for something to be reincluded whwn it was me who wanted it removed in the first place :-)

[tushar@…]

Most (I was going to say 90%) of the users won't need libiberty.a. There are only three known packages that need it and they are not packages most of the users would install. Maybe put optional instructions for people who would like to install it along with an explaination. Others can skip those instructions.

[andreas.dombrowsky@…]

​http://gcc.gnu.org/ml/gcc-patches/2002-03/msg00942.html seems to indicate the master copy of libiberty is in GCC. Shouldn't we keep the system libiberty, should we decide to install it, in sync with GCC in view of that?

[greg@…]

Responding to Andreas.

Yes and No. The master CVS repo for libiberty is with gcc, but the others are kept in sync with it. In the context of core LFS where the only 2 libiberty using pkgs are gcc and binutils, it makes sense to use the binutils one for 2 main reasons:-

1) due to the nature of how gcc branches for release purposes, the libiberty contained within the gcc tarball is much more likely to be older than the one contained in the binutils tarball. Binutils releases are fairly frequent these days and the the top-level build system (shared by gcc, binutils, gdb and of which libiberty is a part of) will generally be newer inside the binutils tarball. In other words, the time between creating a CVS branch for release purposes and the actual release is much shorter with binutils.

2) libiberty is often used in conjunction with libbfd. It just makes more sense to use a libiberty that came with libbfd.