libiberty packaging troubles

libiberty packaging troubles

[John Levon]

My application needs to demangle C++ strings. Now, it seems that more
recent libiberty versions have automatic demangling for both ABI
versions. We would like to take advantage of this so that a user can get
sensible results even with a self-installed gcc version with different
mangling to the system compiler, and have it all "just work".

Currently we are linking against an installed libiberty. This sucks
because :

1) the header files are incomplete (demangle stuff). Recently it was
mentioned there was no interest in fixing this, because linking against
installed libiberty is not approved of

2) all the limitations of the system's libiberty are present, including
crashes, and corrupted data (seen recently by a user). As I said it
would be good if this "just worked"

So the supposed solution is to include the latest libiberty source in
our source. However there also some problems with this :

1) We need libbfd as well, there is a risk associated with using a newer
libiberty in our source against an older system libbfd

2) the source is large, and would more than double the size of our
source releases

3) neither the gcc or binutils version of libiberty are
self-encapsulated. They rely on a number of headers outside of libiberty
directory.

4) I could not find an answer as to which package had the master source
of libiberty

For obvious maintenance reasons, I would like to avoid touching /any/
libiberty code. But this seems very painful to do, given 2) and 3). I
could spend time filtering out which headers are needed by libiberty
but this is liable to breakage on updates to the vendor import of
libiberty.

I can make the necessary object files directly and not have unused
sources in my CVS tree, but this is equally painful to do

Does anybody have suggestions ? Is there a self-contained libiberty
somewhere ?

My other option is to investigate Carlo Wood's demangler in libcwd,
and see if I can get both demanglers to work automatically (are there
ambiguous cases between the two ABIs ? Why doesn't gcc add a hint in
the binary which mangling scheme was used :/)

thanks for any suggestions
john

p.s. I only care about x86/Linux

-- 
I am a complete moron for forgetting about endianness. May I be
forever marked as such.

Re: libiberty packaging troubles

[Daniel Jacobowitz]

On Thu, Feb 28, 2002 at 10:59:04PM +0000, John Levon wrote:
> 1) We need libbfd as well, there is a risk associated with using a newer
> libiberty in our source against an older system libbfd

Libbfd is the same as libiberty in this context.  If you want to use
libbfd, you need to include it.

> 2) the source is large, and would more than double the size of our
> source releases

Yeah, well.

> 3) neither the gcc or binutils version of libiberty are
> self-encapsulated. They rely on a number of headers outside of libiberty
> directory.

All of which should be in the top-level 'include' directory.  There's
no harm in just including the entire directory.

> 4) I could not find an answer as to which package had the master source
> of libiberty

GCC.  The copy in Binutils' CVS is generally updated within an hour,
though.

> Does anybody have suggestions ? Is there a self-contained libiberty
> somewhere ?

Not yet.  I believe this is on someone's todo list...

> My other option is to investigate Carlo Wood's demangler in libcwd,
> and see if I can get both demanglers to work automatically (are there
> ambiguous cases between the two ABIs ? Why doesn't gcc add a hint in
> the binary which mangling scheme was used :/)

There are no ambiguities.  All v3 manglings start with _Z, and all v2
manglings (mostly...) start with the name of the function being
mangled.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: libiberty packaging troubles

[John Levon]

On Thu, Feb 28, 2002 at 06:24:45PM -0500, Daniel Jacobowitz wrote:

> > 1) We need libbfd as well, there is a risk associated with using a newer
> > libiberty in our source against an older system libbfd
> 
> Libbfd is the same as libiberty in this context.  If you want to use
> libbfd, you need to include it.

ouch.

is there any particular reason this linking isn't allowed ? Does nobody
else think it's a problem that every single app that uses this stuff has
to replicate it ?

> > 2) the source is large, and would more than double the size of our
> > source releases
> 
> Yeah, well.

with bfd as well, it's more like 10x the size.

> All of which should be in the top-level 'include' directory.  There's
> no harm in just including the entire directory.

ok, I noticed the gcc include/ directory has a lot less in it.

> GCC.  The copy in Binutils' CVS is generally updated within an hour,

thanks

> > Does anybody have suggestions ? Is there a self-contained libiberty
> > somewhere ?
> 
> Not yet.  I believe this is on someone's todo list...

well that's a minor problem now compared to libbfd.

> There are no ambiguities.  All v3 manglings start with _Z, and all v2
> manglings (mostly...) start with the name of the function being
> mangled.

thanks.

I think the only sensible thing I can do is punt the issue and continue
on the "non-approved" track. I don't know what including another 10Mb of
source myself will help with !

I should probably let you get back to releasing 2.12 ...

regards
john

-- 
I am a complete moron for forgetting about endianness. May I be
forever marked as such.

Re: libiberty packaging troubles

[Daniel Jacobowitz]

On Fri, Mar 01, 2002 at 01:27:58AM +0000, John Levon wrote:
> On Thu, Feb 28, 2002 at 06:24:45PM -0500, Daniel Jacobowitz wrote:
> 
> > > 1) We need libbfd as well, there is a risk associated with using a newer
> > > libiberty in our source against an older system libbfd
> > 
> > Libbfd is the same as libiberty in this context.  If you want to use
> > libbfd, you need to include it.
> 
> ouch.
> 
> is there any particular reason this linking isn't allowed ? Does nobody
> else think it's a problem that every single app that uses this stuff has
> to replicate it ?

It doesn't have a defined interface.  The only time it's present on the
system as a shared library is to save space, and I'm not 100% sure why
we ever install the static library.

A binary incompatible change in libbfd probably goes in every month at
the least.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: libiberty packaging troubles

[John Levon]

On Fri, Mar 01, 2002 at 01:51:54AM -0500, Daniel Jacobowitz wrote:

> It doesn't have a defined interface.  The only time it's present on the
> system as a shared library is to save space, and I'm not 100% sure why
> we ever install the static library.

or the (broken) headers !

As for the "no defined interface", well, my code is currently working
across a wide range of bfd/libiberty versions. It's not unreasonable to
demand a recompile if the user changes library version.

I assume the interface is not broken gratuitously. After all, several
projects rely on that interface at source level anyway.

> A binary incompatible change in libbfd probably goes in every month at
> the least.

This isn't a problem, or hasn't been yet. Unless you're getting the
shared library versioning wrong (if so, why ?) there's no problem: just
like any other library, if I want to use the BIC new version of a
library, then the users can recompile. After all, libraries are supposed
to be able to avoid this kind of problem.

regards
john


-- 
I am a complete moron for forgetting about endianness. May I be
forever marked as such.

Re: libiberty packaging troubles

[Andreas Schwab]

Alan Modra <amodra@bigpond.net.au> writes:

|> On Fri, Mar 01, 2002 at 01:51:54AM -0500, Daniel Jacobowitz wrote:
|> > 
|> > A binary incompatible change in libbfd probably goes in every month at
|> > the least.
|> 
|> For the benefit on anyone submitting patches, any such change is
|> supposed to trigger an increase in the bfd version number.
|> (bfd/configure.in:AM_INIT_AUTOMAKE)
|> 
|> Since we're on 2.12.90, I guess Daniel's assertion implies a 2.13.0
|> release in under 10 months.  ;-)

Why?  In 10 months we just have 2.12.100.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: libiberty packaging troubles

[Alan Modra]

On Fri, Mar 01, 2002 at 01:46:49PM +0100, Andreas Schwab wrote:
> Alan Modra <amodra@bigpond.net.au> writes:
> 
> |> Since we're on 2.12.90, I guess Daniel's assertion implies a 2.13.0
> |> release in under 10 months.  ;-)
> 
> Why?  In 10 months we just have 2.12.100.

Ssshh.  Don't you want more frequent releases?