Greetings! Thanks for these notes, Vadim!
"Vadim V. Zhytnikov" <address@hidden> writes:
Some extra observations.
I took directory with successful GCL build
which was made before binutils upgrade (bunitils 2.14.90.0.6),
and tried rebuild it but not from very beginning but
starting with pcl. In other words I use old saved_gcl
to build pcl and finally saved_ansi_gcl.
Build succeeded. So problem lies already in saved_gcl
not in later compile/link stages as it may seems at first.
I've checked that lockbfd and custreloc GCL builds
work to me as expected - locbfd is linked with
locally compiled libbfd.a/libiberty.a and custreloc
without libbfd/libiberty at all.
But in spite of this all these types of GCL ANSI build -
statsysbfd, locbfd, custreloc fail to me exactly
at the same place if I use binutils 2.14.90.0.8.
I'd be glad if someone with binutils 2.14.90.0.8 could
confirm the problem. Unfortunately it seems that this
binutils version is available only for Fedora 2 beta.
I don't have this distro near at hand.
The latest binutils in Debian testing/unstable are
2.14.90.0.7.
I'm going to test the problem with --enable-debug
but I'm not sure how to combine make build
and gdb. Any ideas?
All of the above points to some sort of C miscompilation. The loading
code is obviously not effected given your results with custreloc. Can
you identify which specific files involved in the upgrade break the
build? I.e., I would be flabbergasted if the mere copying of
/usr/lib/libbfd.a into place on an old system would break the build.
Does your distribution separate the binutils into runtime and -dev
packages like on Debian? If so, can you isolate which package is the
culprit? When testing with custreloc or locbfd, you don't need the
-dev installed. Have other header files on your system changed in the
upgrade? I take it gcc itself has not. My bet is on the headers.
When Debian unstable gets .8, I'll be happy to try and
reproduce/debug.