-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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...)
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
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!
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
