Jordan,
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?
For reference:
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 uClibc toolchain.
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.
********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************
Jordan Crouse wrote:
On 07/05/08 15:27 -0400, Marc Karasek wrote:
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...
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
Jordan Crouse wrote:
On 07/05/08 12:36 -0400, Marc Karasek wrote:
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.
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