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.