Marc.Karasek at Sun.COM
Thu May 8 18:08:42 CEST 2008
I thnk I may have found a possible answer to this issue. In digging
further I noticed that the file produced under buildrom is not a real
file (it is only 496 bytes). So it is the linking that is the problem.
Buildrom uses uClibc 0.9.29 (correct?). I also noticed that you were
using -nostdlib option to link with the uClibc libraries. In doing
some investigating, it looks like this is no longer supported. Since
0.9.22 uclibc has pulled the toolchain wrapper that made this
possible. They now want you to produce a full uclibc toolchain if you
want to use uclibc libs.
So the questions are:
1) Do we need to add to buildrom so it will produce the toolchain and
then compile busybox?
2) Go back to an earlier version of uclibc 0.9.22?
3) Or just use glibc?
What happened to the old toolchain wrapper?
It is possible in some limited cases to re-use an existing glibc
toolchain and subvert it into building uClibc binaries by using gcc
commands such as "-nostdlib" and "-nostdinc". In fact, this used to be
the recommended method for compiling programs with uClibc, and we made
this easy to do by providing a uClibc toolchain wrapper, which attempted
to automagically subvert an existing glibc toolchain.
This toolchain wrapper was removed from uClibc 0.9.22, and it will not
be coming back. This is because it proved impossible to completely
subvert an existing toolchain in many cases, and therefore proved to be
a real maintainence burder. As uClibc became more capable, the many
problems with re-using an existing glibc toolchain led us to conclude
that the only safe and sane way to build uClibc binaries was to use a
Some discussion on the reasoning behind this decision can be found here:
http://www.uclibc.org/lists/uclibc/2003-October/007315.html in the
uClibc mailing list archives.
mailto:marc.karasek at sun.com
Jordan Crouse wrote:
> On 07/05/08 15:27 -0400, Marc Karasek wrote:
>> It gets even wierder.. If I compile BB in the work dir it comes out
>> dynamic, if I use buildrom it comes out static...
> Hmm - you might be dealing with some strange kconfig issues here. Copy
> packages/busybox/conf/defconfig to work/busybox/busybox-1.10.1/.config and
> run 'make oldconfig' to make sure your config is up to date. Then check
> the resulting .config to make sure that CONFIG_STATIC isn't set.
>> Jordan Crouse wrote:
>>> On 07/05/08 12:36 -0400, Marc Karasek wrote:
>>>> I need some help on an error message.
>>>> I am trying to move to busybox 1.10.1 to see if this fixes the SimNOW
>>>> problem with linuxrc. (All I did to change it to 1.10.1 was to modify
>>>> the busybox.mk file to point to the new tar.bz2 file and removed the
>>>> patches. Busybox builds fine but it errors out right after. I also
>>>> added a check in scripts/Makefile.lab for the initrd-rootfs dir. It
>>>> seems that if the dir is not there, then the cp from the skeleton to this
>>>> dir fails. It creates the dir if it is not there, and does nothing if it
>>>> is there.
>>>> When it gets to the point after compiling busybox and is creating the
>>>> initrd-rootfs. It errors out from the python mklibs.py with
>>>> E: Dynamic Linker not found, aborting message. I am not a python
>>>> expert, I have looked at the mklibs.py file and tried to see what it was
>>>> doing. It looks like it is trying to get a list of execs from the
>>>> staging directory.
>>> mklibs.py strips out all the unused symbols from shared libraries, which
>>> is useful for LAB since you can get the benefit of a shared library
>>> carrying around symbols you don't need.
>>> The code tries to figure out the link interpreter automatically by
>>> running readelf --program-headers on each binary and looking for
>>> "Requesting program interpeter". If it doesn't find it, then it
>>> freaks out. I am assuming that its not finding it in your case because
>>> the newer busybox binary is constructed differently. I would have to
>>> look at the binary in more detail to figure out why. In the meantime,
>>> you can disable that line in buildrom at the expense of more bytes in
>>> your shared libraries.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the coreboot