Re: forget *documenting* libiberty -- how about *installing* it?

[Marc Espie <espie at quatramaran dot ens dot fr>]

In article <200101040126.RAA03605@racerx.synopsys.com> you write:

>> Can we consider adding installation rules for the libiberty header files?
>> The only suggestion I have for "where" is the obvious one of "in a libiberty
>> subdir" so that users would need to write

>>     #include <libiberty/splay-tree.h>
>>     #include <libiberty/md5.h>

>> and so forth.

>In the past, when things like this were discussed the issue always came up
>that, currently, binutils and gdb both ship a libiberty and they are
>usually out of phase with each other.  So libiberty doesn't really have
>a version number and it's a problem if you use an installed copy because
>depending on the order in which gdb, binutils and gcc are installed you
>might get a different one.  Any news on that front?  Or is it still the
>same?


The only way to solve that is to start treating libiberty as a real library:
not change interfaces around, and add new names instead, and provide the
old interface for a reasonable period.

Considering gdb, binutils, gcc, I believe it would be reasonable to keep
the old interfaces alive for one or two releases of each product.

I think that, right now, the various libiberties are kept reasonably
synched with one another, and it would be okay to merge them, except for
that problem of interfaces changing sometimes...

When I finally update OpenBSD to binutils 2.10, I spent one hour reading
through libiberty changes, as we're only building one libiberty for
binutils/gdb/gcc.  This went by without any nasty surprise. It's just a question
of being slightly careful.