On Tue, Jan 28, 2014 at 09:48:38PM +0100, Frans de Boer wrote:
> On 01/28/2014 09:09 PM, Frans de Boer wrote:
> > On 01/28/2014 08:37 PM, Ken Moffat wrote:
> >> On Tue, Jan 28, 2014 at 07:27:58PM +0200, Markku Pesonen wrote:
> >>>
> >>> I got those errors when I had removed the static version of libz
> >>> (/usr/lib/libz.a). Static version of glibc is also needed.
> >>>
> >> Thanks for that pointer.
> >>
> >> ĸen
> >>
> > Hm, there should be a libz.a somewhere, but none is build. I will look
> > into the matter and will report back my findings.
>
> Sorry, I had a leftover from a previous experiment where I removed the
> static files after install. So, the absence of libz.a is hereby
> explained. I will check other scripts for the BSS phase on that fact too.
>
> That does not explain the static allocation errors by it self, but will
> start fresh again with a BSS build and monitor what is happening.
>
> Regards, Frans.
>
I hope your attempt goes better than mine!
I discovered that I had an error in the functions I use while
building, libc.a was being renamed to libc.a - but even with that
renamed, and libz.a being made available, for me the tests still
fail.
Looking at the last test:
binutils-2.23.2/ld/testsuite/ld-ifunc/ifunc.exp
The tests seem to be run from the check-DEJAGNU target
and that uses LIBS=$(LIBS) which is -lz -ldl so that explains the
need for libz.a : the static tests pass -static to the linker.
This particular test is
if ![default_ld_link $ld "tmpdir/static_prog" "-static -Ltmpdir
tmpdir/static_prog.o -lifunc"] {
fail "Could not link a static executable"
set fails [expr $fails + 1]
}
and for me, now, the problem seems to be $ld.
If I try to run the command in binutils/build/ld using _any_ ld
(either the existing version in /tools/bin. or the newly built
ld-new which is what actually gets used) it fails like this:
ld -o tmpdir/static_prog -static -Ltmpdir tmpdir/static_prog.o -lifunc
ld: warning: cannot find entry symbol _start; defaulting to
0000000000400140
tmpdir/static_prog.o: In function `main':
prog.c:(.text.startup+0x28): undefined reference to `printf'
prog.c:(.text.startup+0x41): undefined reference to `puts'
prog.c:(.text.startup+0x4d): undefined reference to `puts'
prog.c:(.text.startup+0x62): undefined reference to `puts'
prog.c:(.text.startup+0x71): undefined reference to `puts'
I tried adding other libs, but only managed to progress to blowing
up against undefined unwind symbols and __gcc_personality_v0 which
may be a g++ thing. Adding libstdc++ and libsupc++ didn't help.
There was a suggestion elsewhere to link in libgcc_s to fix a
__gcc_personality_v0 problem, but that is a _shared_ lib and the
test forces -static.
BUT if I run it using gcc :
gcc -o tmpdir/static_prog -static -Ltmpdir tmpdir/static_prog.o -lifunc
it succeeds and I can then do
./tmpdir/static_prog
ifunc working correctly
I found that binutils-build/ld/ld-new was being used by instrumenting
binutils-2.23.2/ld/testsuite/lib/ld-lib.exp
by adding a line
send "ld is $ld"
in the default_ld_link proc. Oh well, I've learned how to print a
variable in an expect script :-(
And it seems to me that when I run the testsuite it will only work
if $ld is expanded to gcc. And yet it appears to work for some other
people.
I think I'll make a fresh attempt, maybe tomorrow, but in the mean
time any suggestions are welcome. Although the build was scripted,
the ld tests still fail if I run 'make check' by hand in
binutils-build/ld. For those who want to know about my environment:
root in chroot /building/binutils-build/ld# printenv
TERM=xterm-color
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin
JOBS=4
PWD=/building/binutils-build/ld
REALDEV=
PS1=\u in chroot \w\$
SHLVL=1
HOME=/root
_=/tools/bin/printenv
OLDPWD=/building/binutils-build
root in chroot /building/binutils-build/ld#
Oh, and type-pa ld shows /tools/bin/ld
(yes, still building in /mnt/lfs/building - /sources is still an nfs
mount from another machine :)
$REALDEV could be /dev/sdX, it gets used in real builds to help me
work out values for fstab and for the rootfs backups, but I've bound
/scratch/lfs to /mnt/lfs for this debugging build.
$JOBS gets passed to make -j during (most) compiles (but never to
installs).
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
