<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jordan,<br>
<br>
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. <br>
So the questions are: <br>
1) Do we need to add to buildrom so it will produce the toolchain and
then compile busybox? <br>
2) Go back to an earlier version of uclibc 0.9.22? <br>
3) Or just use glibc? <br>
<br>
For reference:<br>
<h2><a name="wrapper">What happened to the old toolchain wrapper?</a></h2>
<p> 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. </p>
<p> 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
uClibc toolchain. </p>
<p> Some discussion on the reasoning behind this decision can be found
here: <a
href="http://www.uclibc.org/lists/uclibc/2003-October/007315.html">
http://www.uclibc.org/lists/uclibc/2003-October/007315.html</a> in the
uClibc mailing list archives.<br>
<br>
</p>
<br>
<br>
<br>
<br>
<br>
<pre class="moz-signature" cols="72">*********************
Marc Karasek
MTS
Sun Microsystems
<a class="moz-txt-link-freetext" href="mailto:marc.karasek@sun.com">mailto:marc.karasek@sun.com</a>
ph:770.360.6415
*********************
</pre>
<br>
<br>
Jordan Crouse wrote:
<blockquote cite="mid:20080507203125.GD2564@cosmic.amd.com" type="cite">
<pre wrap="">On 07/05/08 15:27 -0400, Marc Karasek wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Jordan,
It gets even wierder.. If I compile BB in the work dir it comes out
dynamic, if I use buildrom it comes out static...
</pre>
</blockquote>
<pre wrap=""><!---->
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
</pre>
<blockquote type="cite">
<pre wrap="">Jordan Crouse wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 07/05/08 12:36 -0400, Marc Karasek wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Jordan,
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.
</pre>
</blockquote>
<pre wrap="">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
without
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.
Jordan
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>