Question @ 10,000 feet

Spahn, Daniel DSpahn at
Tue Nov 18 11:20:58 PST 2008

-----Original Message-----
From: lfs-support-bounces at [mailto:lfs-support-bounces at] On Behalf Of Mike McCarty
Sent: Tuesday, November 18, 2008 1:35 PM
To: LFS Support List
Subject: Re: Question @ 10,000 feet

Alexander Haley wrote:


> What is to stop me from telling glibc to install itself into
> /usr/weird/path/foo and gcc into /bar/zap/ .. and then somehow
> configuring them to understand their relationship? Is that even
> feasible? Would doing this somehow create a deeper understanding (for
> me) of how gcc and glibc fit together?

Nothing should prevent you from doing that, which I am aware of.
Linux is extremely flexible- there are a few sets of standards which are followed based on the preference of the distribution. They key thing to remember is that you need to know what changes you make to the default structure... or make sure that corresponding variables are set so packages *can* install. If you need an example of the variance, check out Debian, Gentoo, and Redhat and see here key things, such as so's, init scripts, and configuration files are kept.

> Basically, the fundamental thing that bugs me is ... I type 'make
> install' and scads of files arrive on the file system ... and I really
> don't quite know their role, purpose or importance ... Do I really
> need to know the purpose of each and every library file that is
> installed? Probably not .. but, I am irked that I'm typing 'make
> install' and just crossing my fingers that the system is getting it
> right .... (of course the system often gets it right .. but does it
> teach me? no. or at least, not yet.)

What do you want to learn from it? Essentially, this particular
question is just a matter of organization. There COULD be just
one big library containing everything anyone could ever want
in a Standad C Library, and the kitchen sink, as well. However,
not many C programs use, for example, the arcsine function.
So, the math related functions are collected together into a
library of related functions. There is no compelling reason
for doing that. It's for the convenience of the maintainers
of the libraries. The fellow who knows how best to write a
super fast strlen(.) may not be the one who knows best how
to write a fast efficient and accurate asin(.) function,
and vice versa.

So, the library gets split up into "related" pieces.

It makes it less unweildy. (Weird. It seems like I should
be saying "It makes it more weildy", but that isn't the
idiom. Anyway...)

Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!
Unsubscribe: See the above information page

More information about the lfs-support mailing list