Fixincludes - some analysis

Dagmar d'Surreal dagmar.wants at
Fri Jan 24 20:25:19 PST 2003

On Fri, 2003-01-24 at 19:30, Bruce Dubbs wrote:
> Greg Schafer wrote:
> >Sidenote: I don't understand at all why /usr/local/include comes first in
> >the search path. This seems very counter-intuitive to me. The gcc page at:-
> >   contains some commentary on why
> >this is so but I still don't get it.
> >
> Its there so a programmer can easily override a default header file by 
> merely putting an updated one in /usr/local/lib.  Otherwise the path 
> would have to be explicitly defined every time or the actual header in 
> /usr/lib changed.

Okay, but there's one eye-roller of a problem with this...  The linker
now considers the "system" library directories /lib, and /usr/lib to be
"trusted" and they are searched _first_.  Don't ask me when this
changed, because it took me by suprise, too.  The only time frame I can
give you would be "after glibc 2.0 was released and before glibc 2.2.3
came out".  Anything listed in /etc/ is searched (and used)
after those, meaning horrible things may happen if one compiles
searching /usr/local/include first over /usr/include and then links
expecting to get the library that went with those headers in
/usr/local/lib instead of /usr/lib.  This sort of thing is why I was
waving my little baton so flagrantly about removing duplicate freetype
and zlib files from the /usr/X11R6 prefix.  Different versions break the
hell out of things when assumptions are made that involve directories
other than /lib and /usr/lib being used.
The email address above is just as phony as it looks, and for obvious reasons.
Instant messaging contact nfo: AIM: evilDagmar  Jabber: evilDagmar at

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