An idea: isolate libs [was: Pure LFS]

Miguel Bazdresch miguel at
Thu Feb 6 04:50:44 PST 2003

* Greg Schafer <gschafer at> [03-0203 20:44]:
> The other interesting configure switch is --with-local-prefix=/stage1. The
> purpose of this switch is to remove /usr/local/include from gcc's include 
> search
> path. It is not absolutely essential but we want to try and minimise the
> influence from the host system so this is a logical thing to do. The gcc 
> install page[2] says:-
> "The same value can be used for both --with-local-prefix and --prefix provided
> it is not /usr. This can be used to avoid the default search of
> /usr/local/include."
> which is exactly what we want. You can see the gcc search include order by
> compiling a test program with "-v" e.g. gcc -v foo.c. The following snippets


I don't yet fully understand everything that is involved in 
what you're trying to do here, but while digesting it in my mind 
I had an idea.

It seems like we're trying to prevent, at all costs, from linking to the
host's libraries. So, why don't we make those libraries unreachable
before compilation? The easiest way is just to rename them. For example,
if there is a risk of something linking to a library in directory 
/path/to/lib, first do a

mv /path/to/lib /path/to/lib_

Somebody mentioned that gcc could still link to libraries mentioned
explicitly with -I. This would catch that happening.

A sneaky extension to this idea would be to create a symlink pointing to
the equivalent directory inside /stage1 after renaming:

mv /path/to/lib /path/to/lib_
ln -s /stage1/path/to/lib /path/to/lib

so that any references to /path/to/lib that were not catched by every
other effort (including those created by -I) would instead go to our 
libraries in /stage1.

Obviously the damage to the host would be undone after compilation.

I apologise if my understanding of this subject is even lower than I
thought and I'm talking nonsense.

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

More information about the lfs-dev mailing list