which versions of c++filt and libiberty.a are preferable?

[unknown]

Hi, I'm trying to decide which versions of c++filt and libiberty.a to
use. copies of both files come with gcc and binutils. I doubt it makes
whole lot of difference, but I wonder if anyone has any opinion which is
better. I noticed in the libiberty directory of both packages that
Makefile.in mentions something about c++filt no being included with
binutils, but in the binutils package, binutils/NEWS mentions that c++
may be included with gcc in the future (which I guess now it is) s I'm
guessing this means use the c++filt that comes with gcc. Hw about
libiberty.a? any reanon to pick one over the other?

Jack Brown

[unknown]

Post by unknown
better. I noticed in the libiberty directory of both packages that
Makefile.in mentions something about c++filt no being included with
binutils, but in the binutils package, binutils/NEWS mentions that c++

should read: "something about c++filt now being included" (just to
avoaid any confusion.

Jack Brown

[Greg Schafer]

Post by unknown

Post by unknown
better. I noticed in the libiberty directory of both packages that
Makefile.in mentions something about c++filt no being included with
binutils, but in the binutils package, binutils/NEWS mentions that c++

should read: "something about c++filt now being included" (just to
avoaid any confusion.

You did check the list archives didn't you? :)

Regarding c++filt, the thread starts here:-

http://archive.linuxfromscratch.org/mail-archives/lfs-dev/2002/05/0798.html

Greg

[Greg Schafer]

Post by Greg Schafer

Post by unknown

Post by unknown
better. I noticed in the libiberty directory of both packages that
Makefile.in mentions something about c++filt no being included with
binutils, but in the binutils package, binutils/NEWS mentions that c++

should read: "something about c++filt now being included" (just to
avoaid any confusion.

You did check the list archives didn't you? :)
Regarding c++filt, the thread starts here:-
http://archive.linuxfromscratch.org/mail-archives/lfs-dev/2002/05/0798.html

Actually, I now note that cvs book was just amended to install libiberty.h
from binutils. In that case, it would make sense to install libiberty.a from
binutils also.

But to be honest, libiberty looks to be a hodge podge of various misc
utility routines used by various GNU packages. As such, it's interfaces
are likely not very stable and might change often. Hence probably why
it is not installed as a shared lib. It's hard to imagine lots of packages
needing it. Can anyone name 2 packages that need an installed copy of
libiberty? (not gcc, binutils or gdb)

Greg

[Timothy Bauscher]

Post by Greg Schafer
Actually, I now note that cvs book was just amended to install libiberty.h
from binutils. In that case, it would make sense to install libiberty.a from
binutils also.

Hrm, I just noticed that the libiberty library is installed
by GCC. So, I wonder if we should copy the header from GCC
instead. It would make more sense...

[Greg Schafer]

Post by Timothy Bauscher

Post by Greg Schafer
Actually, I now note that cvs book was just amended to install libiberty.h
from binutils. In that case, it would make sense to install libiberty.a from
binutils also.

Hrm, I just noticed that the libiberty library is installed
by GCC. So, I wonder if we should copy the header from GCC
instead. It would make more sense...

When in doubt, refer to Debian! Thats what I do :)

They install the lib and header from binutils.

With the current order, thats how we end up isn't it?

Greg

[Timothy Bauscher]

Post by Greg Schafer

Post by Timothy Bauscher
Hrm, I just noticed that the libiberty library is installed
by GCC. So, I wonder if we should copy the header from GCC
instead. It would make more sense...

When in doubt, refer to Debian! Thats what I do :)
They install the lib and header from binutils.
With the current order, thats how we end up isn't it?

Jeesh Greg, your response time is absurdly quick :)

Well, I think that GCC and Binutils swapped libiberty a while
ago. I remember updating the file contents of each and noticing
something like this. So, I don't think that "debian does it"
is a good excuse here, since Debian is, err, *cough*, *old*.

[Greg Schafer]

Post by Timothy Bauscher

Post by Greg Schafer

Post by Timothy Bauscher
Hrm, I just noticed that the libiberty library is installed
by GCC. So, I wonder if we should copy the header from GCC
instead. It would make more sense...

When in doubt, refer to Debian! Thats what I do :)
They install the lib and header from binutils.
With the current order, thats how we end up isn't it?

Jeesh Greg, your response time is absurdly quick :)

Too much coffee! Gcc bugs have me hyped :)

Post by Timothy Bauscher
Well, I think that GCC and Binutils swapped libiberty a while
ago. I remember updating the file contents of each and noticing
something like this. So, I don't think that "debian does it"
is a good excuse here, since Debian is, err, *cough*, *old*.

Actually, Debian unstable is bleeding edge. The search tools at:-

http://www.debian.org/distrib/packages are a good resource. But
you are correct in "debian does it" is no excuse, but it helps me
often in making decisions. Can you tell what my host distro was
2 years ago?

Not sure what you mean by "swapped" as both packages use libiberty.
Anyhoo, for libiberty, I vote to just stick with status quo seeing
as you've now sorted out the header installation.

Greg

[Timothy Bauscher]

Post by Greg Schafer
Too much coffee! Gcc bugs have me hyped :)

Yah. I've alerted Gerard to your latest patch, since you
seemed to be pretty convinced about it fixing many problems.
IIRC, he's got GCC-3.2 in his sandbox, but I think he wanted
to do more testing before his commit.

Post by Greg Schafer

Post by Timothy Bauscher
Well, I think that GCC and Binutils swapped libiberty a while
ago.

But you are correct in "debian does it" is no excuse, but it
helps me often in making decisions. Can you tell what my host
distro was 2 years ago?

I used Debian as my host distro as well.

Post by Greg Schafer
Not sure what you mean by "swapped" as both packages use libiberty.
Anyhoo, for libiberty, I vote to just stick with status quo seeing
as you've now sorted out the header installation.

***@random:~# grep libiberty /etc/logs/*
/etc/logs/gcc-3.1:/mnt/lfs/usr/lib/libiberty.a

Binutils used to install libiberty, IIRC. Anywho, it just
makes more sense to me to take cp the header file from the
same place we get the library.

[Greg Schafer]

Post by Timothy Bauscher
Yah. I've alerted Gerard to your latest patch, since you
seemed to be pretty convinced about it fixing many problems.
IIRC, he's got GCC-3.2 in his sandbox, but I think he wanted
to do more testing before his commit.

More news later on this. Testing all the combos is very time
consuming and cpu intensive. Celery 533 just don't cut it no more.

Post by Timothy Bauscher

Post by Greg Schafer

Post by Timothy Bauscher
Well, I think that GCC and Binutils swapped libiberty a while
ago.

But you are correct in "debian does it" is no excuse, but it
helps me often in making decisions. Can you tell what my host
distro was 2 years ago?

I used Debian as my host distro as well.

Post by Greg Schafer
Not sure what you mean by "swapped" as both packages use libiberty.
Anyhoo, for libiberty, I vote to just stick with status quo seeing
as you've now sorted out the header installation.

/etc/logs/gcc-3.1:/mnt/lfs/usr/lib/libiberty.a
Binutils used to install libiberty, IIRC. Anywho, it just
makes more sense to me to take cp the header file from the
same place we get the library.

But binutils overwrites the one from gcc! You change your build order?
Or what am I missing?

Greg

[Timothy Bauscher]

Post by Greg Schafer
But binutils overwrites the one from gcc! You change your build order?
Or what am I missing?

I was relying on my find command, which only checks for
new unique filenames, instead of looking at the timestamps.
So, it doesn't detect when files are overwritten. In that
case, it doesn't make any difference which header we use.

Sorry for the confusion ;)

[unknown]

Post by Greg Schafer
But binutils overwrites the one from gcc! You change your build order?
Or what am I missing?
Greg

Actually that reminds me...

Gcc's installation instructions suggest building binutils before gcc, in
which case gcc would normaly overwrite binutils' version of these files.

were fine building it after gcc because we have the static version, but
building it afterwards is what is causeing the resulting files to be
owned by binutils

Jack Brown

[unknown]

Post by unknown

Post by Greg Schafer
But binutils overwrites the one from gcc! You change your build order?
Or what am I missing?
Greg

Actually that reminds me...
Gcc's installation instructions suggest building binutils before gcc, in
which case gcc would normaly overwrite binutils' version of these files.
were fine building it after gcc because we have the static version, but
building it afterwards is what is causeing the resulting files to be
owned by binutils
Jack Brown

Having loked things over a bit more I think were doing the right thing
as it stnds already (ie. using the versions from binutils).

Comparing the libiberty directories in both gcc-3.2 and binutils-2.13
(which also happen to include the sources for c++filt), it looks as
though the sources that come with binutils are slightly more up to date,
and differ only slightly.

Jack Brown

[unknown]

on a final note,

I also ntice that binutils provides man and info pages for the files in
question, so anyone reading those would lbe left with the impression
that they had been installed by binutils. (since binutils is mentioned
as being their source)

Jack Brown

[Matthias Benkmann]

Post by unknown
Comparing the libiberty directories in both gcc-3.2 and binutils-2.13
(which also happen to include the sources for c++filt), it looks as
though the sources that come with binutils are slightly more up to date,

Right now. When the next GCC version is released, this is likely to be the
other way around, especially concerning c++filt. There's no way the
binutils maintainers can foresee changes in GCC's mangling scheme.

MSB

[unknown]

Post by Timothy Bauscher

Post by Greg Schafer
Too much coffee! Gcc bugs have me hyped :)

Yah. I've alerted Gerard to your latest patch, since you
seemed to be pretty convinced about it fixing many problems.
IIRC, he's got GCC-3.2 in his sandbox, but I think he wanted
to do more testing before his commit.

Post by Greg Schafer

Post by Timothy Bauscher
Well, I think that GCC and Binutils swapped libiberty a while
ago.

But you are correct in "debian does it" is no excuse, but it
helps me often in making decisions. Can you tell what my host
distro was 2 years ago?

I used Debian as my host distro as well.

Post by Greg Schafer
Not sure what you mean by "swapped" as both packages use libiberty.
Anyhoo, for libiberty, I vote to just stick with status quo seeing
as you've now sorted out the header installation.

/etc/logs/gcc-3.1:/mnt/lfs/usr/lib/libiberty.a
Binutils used to install libiberty, IIRC. Anywho, it just
makes more sense to me to take cp the header file from the
same place we get the library.

Actually binutils installs the library too (same as gcc).

I guess what got me thinking about this was the fact that gcc had the
recent changes regarding c++:

c++ ... c++filt ... (If you catch my drift)

so I wondered if mabe we shouldn't be using gcc's c++filt because of
this. Also the fact that in the NEWS file they mention that c++filt
might eventually be taken over by gcc made me wonder if mabe they were
only installing it in case your running an older gcc, and mabe gcc's
version is more proper. For the record Debian does seem to be using
binutils version of c++filt (in Woody) but then they also install both
gcc-2.95 and gcc-3.1, so to sumarize... I haven't a clue ;-)

Jack Brown

[Matthias Benkmann]

Post by unknown
I guess what got me thinking about this was the fact that gcc had the

I agree with this. c++filt is a demangler for C++. If the mangling scheme
changes (it's not supposed to but it sometimes does, when GCC bugs are
fixed; AFAIK this happened fairly recently) in GCC, I'd expect c++filt
from the GCC package to be updated at the same time.

MSB

[Greg Schafer]

Post by Matthias Benkmann

Post by unknown
I guess what got me thinking about this was the fact that gcc had the

I agree with this. c++filt is a demangler for C++. If the mangling scheme
changes (it's not supposed to but it sometimes does, when GCC bugs are
fixed; AFAIK this happened fairly recently) in GCC, I'd expect c++filt
from the GCC package to be updated at the same time.

Certainly makes sense.

So now we have libiberty stuff from binutils. And c++filt from gcc.

We all agree this is the best way to go?
(only objections please! - no need for 500 agreements :-)

Greg

[unknown]

Post by Greg Schafer

Post by Matthias Benkmann

Post by unknown
I guess what got me thinking about this was the fact that gcc had the

I agree with this. c++filt is a demangler for C++. If the mangling scheme
changes (it's not supposed to but it sometimes does, when GCC bugs are
fixed; AFAIK this happened fairly recently) in GCC, I'd expect c++filt
from the GCC package to be updated at the same time.

Certainly makes sense.
So now we have libiberty stuff from binutils. And c++filt from gcc.
We all agree this is the best way to go?
(only objections please! - no need for 500 agreements :-)
Greg

I think we should be using the same source for both libiberty and
c++filt since they seem to be tied together. I'm thinking of the fact
that the sourcefiles for c++filt and libiberty are both located in the
libiberty directory of each package, and they seem to share a Changelog :-)

unpack one of the packages (either binutils or gcc) and look inside the
directory libiberty for the file cp-demangler.c.

[Matthias Benkmann]

This being said, right now I think I'm going to use the libiberty and
c++filt from binutils for my current build, but in general it seems like
really gcc's version "should" be a more proper choice normally...

Well, the perfect solution seems to be to always take both from the most
recent package, meaning that when a new GCC version is released, both
should be used from that package. When a new binutils version is released,
both should be used from that package.

MSB

[unknown]

Post by Matthias Benkmann

This being said, right now I think I'm going to use the libiberty and
c++filt from binutils for my current build, but in general it seems like
really gcc's version "should" be a more proper choice normally...

Well, the perfect solution seems to be to always take both from the most
recent package, meaning that when a new GCC version is released, both
should be used from that package. When a new binutils version is released,
both should be used from that package.
MSB

intrestingly enough though, the _sources for liberty from binutils 2.13
are actually newer than the ones that come with gcc 3.2 inspite of the
fact that gcc 32 is newer. If your intrested in finding out more, read
the actual change logs that come with it, it make it fairly clear that
they are both using the same code base, but that currently binutils has
a more up to date snapshot.

Jack Brown

[Greg Schafer]

Post by unknown
intrestingly enough though, the _sources for liberty from binutils 2.13
are actually newer than the ones that come with gcc 3.2 inspite of the
fact that gcc 32 is newer. If your intrested in finding out more, read
the actual change logs that come with it, it make it fairly clear that
they are both using the same code base, but that currently binutils has
a more up to date snapshot.

Well, this would have to be the most interesting bit of info I have
found on this matter so far:-

http://gcc.gnu.org/onlinedocs/libiberty/Using.html#Using

The bit about "--enable-install-libiberty" looks very interesting
indeed. I might have to test it out.

I think we are just going to have to decide which one we want to
use and forget about always trying to use the newest. It's just not
practical.

Greg

[unknown]

Post by Greg Schafer
Well, this would have to be the most interesting bit of info I have
found on this matter so far:-
http://gcc.gnu.org/onlinedocs/libiberty/Using.html#Using
The bit about "--enable-install-libiberty" looks very interesting
indeed. I might have to test it out.
I think we are just going to have to decide which one we want to
use and forget about always trying to use the newest. It's just not
practical.
Greg

Good eye Greg!

I'm gonna start looking thins over right now.

I'm curious if you have any idea how libiberty and c++filt are related,
since the c++filt source files seem to reside inside the libiberty
directory.

as far as choosing a versiongoe, it seems to me that we should probably
use gcc's version, for a couple reasons. for one thing it seems to me we
would want for c++filt to behave in whatever maner gcc is expecting, so
probably safer to go with gcc version. Also breifly looking over the
link you cited, they sugest that one reason a person might want to
install libiberty's hearers is so that programs like readline
(aparently) can use the same version as the compiler.

on another note they seem to indicate that libiberty has more than one
header file associated with it, is just copying over libiberty.h enough?

Jack Brown

[Greg Schafer]

Post by unknown
I'm curious if you have any idea how libiberty and c++filt are related,
since the c++filt source files seem to reside inside the libiberty
directory.

Ok, rather than me continuing to make off-the-cuff comments, I thought I'd
get stuck right in and do some real research :)

Lets put this sucker to bed.

* c++filt is comprised of 2 separate object files. Plus it links in code
from libiberty.a

* in the binutils sources, the object files are cplus-dem.o and
underscore.o. underscore.c is just a one-liner auto-generated stub

* in the gcc sources, the object files are cxxmain.o and underscore.o.
cxxmain.c is just a symlink to libiberty/cplus-dem.c

* having established that the main file in question is cplus-dem.c, I can
confirm that there are no differences between the 2 versions

* where the differences lie is in the code that is linked in from
libiberty.a. The main source file here that concerns c++filt appears
to be cp-demangle.c. Here, the binutils version contains an extra
feature to deal with extended unicode characters, and a tiny bugfix.

* the --enable-install-libiberty thing is only in the binutils version
but it doesn't work anyway. Unless you are doing a "target" build or
you fudge the "make install" command line. It does install some extra
headers but they don't appear to be at all useful.

So in summary, I think the way it is now is perfect. We use libiberty.{a,h}
and c++filt from binutils and just forget about it.

The libiberty sources are auto-synched between the gcc and binutils cvs
respositories anyway. The only time we could ever get into strife is if
the binutils and gcc versions we use get very far apart in terms of their
release dates which I just cannot see happening.

You guys can do whatever you want :)

I'm sticking to the status quo and signing off this thread.

Greg

[Rob 'Feztaa' Park]

Post by Greg Schafer
We all agree this is the best way to go?
(only objections please! - no need for 500 agreements :-)

Did it occur to anybody to ask the GCC people? Seems to me like they
might know a thing or two about it ;)

[Jesse Tie-Ten-Quee]

Yo,

Post by Rob 'Feztaa' Park
Did it occur to anybody to ask the GCC people? Seems to me like they
might know a thing or two about it ;)

We did and that doesn't really change anything. (btw, Kudos for MSB
doing this, a few months ago)

http://archive.linuxfromscratch.org/mail-archives/lfs-dev/2002/05/0798.html

[Jack Brown]

[Jack Brown]

[Jack Brown]

[Jack Brown]

[Jack Brown]

[Jack Brown]

[Jack Brown]