Lessons to be learnt from recent events

Gerard Beekmans gerard at linuxfromscratch.org
Tue Jan 28 23:52:48 PST 2003


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.

> Frankly its been done off list because really not much interest was shown.

That would have been my fault, my apologies. I'm actually extremely interested 
in it. I just didn't reply to the email hoping the thread would just continue 
discussing the ideas so I could jump in later when I had a bit more time 
(such as tomorrow I've allocated about 10 hours straight work for LFS to 
catch up on outstanding questions/ideas/aprovals/etc).

>  - 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 
for doing it. Maybe it'll become clear as I read on. I'm just coming up with 
random questions as I go.

>  - 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?

>  - 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).

>  - 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.

> How it hangs together... well that will be in the hint :-)

It has potential. If it actually works (we'll make it work) I want it in the 
book. I recommend not spending effort in hint'ing it, but making it into a 
format that can be included in the book right away.

Then again, there's no way we will have this done, debugged and tested before 
the next book release. So a hint is maybe in order. Depends on how much time 
is needed to get it wrapped up.

> Greg and I will be running a few more builds to sanity check it ( ch5 is
> pretty much sorted ), but all bodes well.

Need some help? I got spare CPU cycles and time...

> Still a little more investigation to do...
> BTW dont use the posted scripts, its moved along a bit since then...
>
> If someone really wants to play we can provide one for Ch5, but it is a
> fast moving target at present...

No don't do scripts, too much work keeping them up-to-date (exactly because 
this would be a fast moving thing like you said).

-- 
Gerard Beekmans
www.linuxfromscratch.org

-*- If Linux doesn't have the solution, you have the wrong problem -*-
-- 
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