Re: libiberty (was: Re: Mangle question)

[Hans-Peter Nilsson <hp at axis dot com>]

> Date: Fri, 1 Sep 2000 18:32:46 +0200
> From: Carlo Wood <carlo@alinoe.com>

> A definite problem of "GNU" is the fact that there are so
> many versions of libiberty around.  I've run into this as
> a problem more than once!

I don't agree about an unclear-*source*-version situation, but I
agree bugs in released versions are awkward.  There's libiberty
in binutils and libiberty in GCC.  Right now(?) they're in sync,
source-wise and we all try to keep it that way (I hope).

> I've been doing my tests using cplus_demangle from the libiberty
> of binutils-2.10.0.18, which is pretty recent.

An H.J. Lu release?  The official binutils 2.10 is "old" enough
to still have the bug, recently fixed as I said.  I presume
H.J. will release a new version, picking up the latest libiberty
and cplus-dem.c.

> Actually, it is *because* of the fact that libiberty's version
> is so unlcear that I decided to write my own demangler.

Which will appear to be a solution until projects A, B and C
start maintaining separate versions, or have different release
schedules...  Then we have a problem again.

> At least a surprice to me was that directly after installing
> binutils-2.10.0.18 and linking with -liberty caused my program
> to be linked with a "well hidden" libiberty.a that comes with gcc,
> that is.. on linux. On FreeBSD I found out that this is not the
> case...

Oh, so you link your own programs to libiberty, which changes
each time you install gcc *or* binutils.{so, a}.  Ugh.

> Something is not right with the version management of libiberty
> imho :).

Right.  Perhaps something can be done, a patch submitted...

> Hmm, the symbols that are in there that the demangler can't
> demangle are lot of __tfP... and __tiP... variables, for example:
> [...]

I'll try and take a closer look at *this* next week.

brgds, H-P