Lessons to be learnt from recent events

Ryan.Oliver at pha.com.au Ryan.Oliver at pha.com.au
Wed Jan 29 01:51:44 PST 2003


Gerard Beekmans wrote:
> On January 29, 2003 12:30 am, Ryan.Oliver at pha.com.au wrote:
>> Therefore we build Ch6 with tools that are ALREADY built against the new
>> glibc.
>
>No more static binaries. That'd be very nice.
>

Nice if you haven't got too much space to work with, also keeps the
build descriptions pretty similar to ch6 ( apart from --prefix ).

Also gives us a build we can do from the get-go using nls ( English is my
native tongue, I wouldn't want to do this in swahili ;-) )

>>  - create /static dir (empty) on host system
>>  - mount --bind ${LFS}/static /static
>
>That would be due to gcc's hardcoding /static right? Or are there more
>reasons

That's one reason, gcc's default search paths ( run gcc -print-search-dirs
)
Its the hard coding of the location of the dynamic linker (ld-linux.so) in
all the binaries and libs ( run ldd on anything shared... ) thats the main
reason...

>>  - Build binutils in /static - no modifications (keeps glibc happy)
>
> Care to elaborate? No modifications as in no modifications to the source
> (we don't do that anyway) or no modif's to the paths that might be
> hard-coded ala gcc?

:-) Sorry, should have elaborated.
First binutils is built static against the system libs exactly as is
currently done in the book.

Some Makefile adjustments are made on the subsequent builds...

>>  - Install kernel headers in /static/include
>>  - Build glibc in /static
>>  - Rebuild ld from binutils ensuring the linker scripts point at
>> /static/lib.
>
> Can't that be done before Glibc is installed? Ie: force use of
/static/lib
> even though it's empty the first time doing it (I guess kind of like the
> case where you create a symlink with a missing target that gets installed
> later).

Not really. The first binutils is so we have an up-to-date assembler and
linker to build glibc from our current host system.

Rebuilding ld here we, depending on the binutils version (Greg?), either
a) pass --with-libdir=/static/lib (or is it --with-libpath, Greg?)   or
b) modify the ld/Makefile, setting LIB_PATH = /static/lib and modifying
   GENSCRIPTS so genscripts.sh gets passed LIB_PATH=$(LIB_PATH)
   ( most of my testing was with GNU binutils 2.13, which doesnt have
     the configure option )

This overrides ld's ldscripts default search order to be /static/lib,
so ld links against /static/lib

>>  - Build gcc in /static - it will use our linker and assembler installed
in
>>    /static/TARGET-TRIPLE/bin ( where target triple is for example
>>     i686-pc-linux-gnu ) to build itself linked against the new glibc.
>>    We can either modify a header file before build or modify the specs
file
>>    afterwards to make gcc use the dynamic linker in /static.
>>  - Rebuild binutils with this c compiler.
>
>The spec file would be best - its meant for making those kind of changes.
>

Probably, but I don't want to have to write the sed for that :-)
You can set it in gcc/config/ARCH/linux.h and forget about it :-)

>> How it hangs together... well that will be in the hint :-)
>
> It has potential. If it actually works (we'll make it work)

It works :-) Most of the time Greg and I have spent on this has been
refining
it

We'll get something a bit more meaningful to you guys soonish ;-)

Regards
Ryan Oliver
Peter Harding And Associates Pty. Ltd.
Eml: ryan.oliver at pha.com.au
Ph:  +613 9641 2222
Fax: +613 9641 2200
Web: http://www.pha.com.au

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list