svn build, glibc error..

Kevin Day thekevinday at gmail.com
Fri Jul 7 13:11:21 PDT 2006


On 7/5/06, Robert Connolly <robert at linuxfromscratch.org> wrote:
>
> Sorry about that. I never tested with binutils-2.17 to see if it worked
> with
> glibc-2.3.6, I just assumed it would. Greg Schafer provided links to the
> following patches on the alfs mailing-list:
>
> http://sources.redhat.com/ml/glibc-cvs/2005-q4/msg00564.html
> http://sources.redhat.com/ml/glibc-cvs/2005-q4/msg00565.html
> http://sources.redhat.com/ml/libc-alpha/2005-11/msg00033.html
>
> I don't plan on keeping glibc-2.3.6 for very long, so I don't want to
> waste
> time sending patches to patches at lfs. If it looks like it'll be a while
> before
> I get glibc-2.4 in, I might revert the book to using binutils-2.16.1.
>
> robert
>
>
There is another problem I noticed with binutils-2.17
I recompiled my toolchain against 2.17.
After that, I chrooted and built the basic packages against that, or tried
to.
When I moved the ld-new to ld, under the chroot system it broke.

Strange.

So did an ldd and it turns out that the ld-new is a script
The scripts breaks because it doesn't know where things are.
A possible fix would be to run a number of sed commands to make the script
understand where things are.
Another possible fix would be to do a sort of bootstrap.

So, my attempt at a work-around was to build yet another pass of
gcc/binutils/uClibc in hopes that the links to the /tools/lib would vanish
in the bootstrapping process.

My first attempt seemed quite successful, until a program called lshw fail
to find cos(), and other common math lib's. I attempted to force -lm to
lshw's build process, but that had failed. So, I looked around and found
libstdc++ to be broken, not one single link to the libc existed (did it
randomly decide to change the rpath settings?).  libstdc++ seems to be the
only broken library that was missing libc links. No other gcc library was
mis-linked.

I made a second attempt on a freshly compiled toolchain doing 3 bootstrap
compiles of gcc/uClibc/binutils to see what happens.

With that done, I noticed that the installed ld, is now a binary on the
chrooted system.
The actual ld program is a binary, but the ld-new is a script?
Was that normal behavior for binutils prior to 2.17, as I never checked the
ld-new to see if it was a binary or a script?


-- 
Kevin Day
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20060707/35f5e559/attachment.html>


More information about the hlfs-dev mailing list