This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: libiberty packaging troubles
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: John Levon <levon at movementarian dot org>
- Cc: binutils at sources dot redhat dot com
- Date: Thu, 28 Feb 2002 18:24:45 -0500
- Subject: Re: libiberty packaging troubles
- References: <20020228225904.GA26603@compsoc.man.ac.uk>
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