Mark Mitchell <[EMAIL PROTECTED]> writes:
> Anyhow, why do we install libiberty.a, but not the libiberty include
> files?
I expect this dates back to the time when libiberty was mainly just a
replacement for missing system functions, and there were no particular
header files associated with it. Plus, if you configure with
--enable-shared, you will get a shared libiberty which probably needs
to be installed. Plus, libiberty is built three times at present, for
the build, host and target systems; we presumably would only want to
install it on the host system. Plus, there is the version skew
problem if you install both gcc and the binutils.
And, finally:
http://gcc.gnu.org/ml/gcc/2001-01/msg00261.html
Personally, I think we should default to not installing libiberty.a,
though we should install libiberty.so if we build it. And then I
think that if we do install libiberty.a, we should install the header
files as well.
> If we defaulted to --enable-install-libiberty, then most GCC
> installations would have the headers, and we'd be OK. If that's the
> wrong thing to do, then my back-up plan is to:
>
> 1. Remove the use of config.h and HAVE_*_H.
>
> 2. Modify the generator not to depend on libiberty headers, including
> hashtab.h, by substituting a simple dictonary object.
>
> 3. Adjust struct-layout-1.exp accordingly.
This is what I would recommend anyhow.
Ian
