[coreboot] Buildrom

[Marc Karasek]

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 at 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
>>>
>>>   
>>>       
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080508/00be04fe/attachment.html>