Hi, everyone. I'm trying to create a distribution of my own from scratch (no, not Linux From Scratch) and I wanted to know what the role of glibc is in a Linux system.

Do programs use glibc all the time and make calls to it constantly or is it used only during compilation and linking?

If glibc is the primary library for all programs, what's the difference between linking it dynamically and statically? Wouldn't linking it statically be redundant since it already has all the functions in it?

Finally, if I install the glibc libraries in a non-standard location (that is, not in /lib or /usr or whatever), how do I tell the configure scripts of other programs and the linker to look for the libraries in a different location? Or is it an environment variable?

Thanks very much!
-earksiinni

Here is a start:

"Any Unix-like operating system needs a C library: the library which defines the ``system calls'' and other basic facilities such as open, malloc, printf, exit...


The GNU C library is used as the C library in the GNU system and most systems with the Linux kernel. "

--from http://www.gnu.org/software/libc/libc.html



As to your question:

"Finally, if I install the glibc libraries in a non-standard location (that is, not in /lib or /usr or whatever), how do I tell the configure scripts of other programs and the linker to look for the libraries in a different location?"

I think that is done with switches on the command line when you run the configure script. IE:

./configure --someswitch path/to/library

I believe you have to check the documentation of each install to know what the switches are

hmm...alright, fair enough

it would be nice to know about compiling glibc statically and dynamically, though

Yes. but i dont know that answer. Hopefullt an expert will step in.

first at the risk of popping you bubble by the nature of the question it appears you are in way over your head at this point. Beyond that
basically since libc is the core linux system for dynamic linking
libc-foo.so itself is dynamically linked only against ld.foo.so
obviously it needs to be built as a shared library. (position independant code)
If you make it static archive and we are just talking theory here because i would imagine that is imposible ! and or your system could never work at all this way
nor will you even be able to try without major hacking at the very least the Makefiles.
Every program that runs on your Linux system would have to be static and huge and contain all the peices of the clib that it uses within each binary.
plus you would have to hand write all the Makefiles for everything i think.
nothing would compile.
Plus you may be locked into creating every other library even as static archive as well.
Your system will run out of ram very quickly and run like crap if at all.
remember when you are saying glibc you are talking about
BINARIES: catchsegv, gencat, getconf, getent,
glibcbug, iconv, iconvconfig, ldconfig, ldd, lddlibc4, locale,
localedef, mtrace, nscd, nscd_nischeck, pcprofiledump, pt_chown,
rpcgen, rpcinfo, sln, sprof, tzselect, xtrace, zdump and zic
LIBRARIES: ld.so, libBrokenLocale.[a,so],
libSegFault.so, libanl.[a,so], libbsd-compat.a, libc.[a,so],
libc_nonshared.a, libcrypt.[a,so], libdl.[a,so], libg.a, libieee.a,
libm.[a,so], libmcheck.a, libmemusage.so, libnsl.a,
libnss_compat.so, libnss_dns.so, libnss_files.so, libnss_hesiod.so,
libnss_nis.so, libnss_nisplus.so, libpcprofile.so,
libpthread.[a,so], libresolv.[a,so], librpcsvc.a, librt.[a,so],
libthread_db.so and libutil.[a,so]

build Linux from Scratch about 12 times and 12 different ways then start asking these kinds of questions i think

Explanation of "static" vs. "dynamic" linking:

All programs rely very heavily upon a library of subroutines, from the mundane to the ridiculous, which are not present in the source-code that you have written but that are "assumed" to exist. And they do exist, in a library such as glibc.

In order for the program to actually run, howeve, those "other" routines must somehow be brought together with your program, to create one complete mass of executable code wherein "everything is there." That's "linking."

With static linking, all of those various routines are brought together at compile-time and placed into one, necessarily rather-large but also self-contained, executable file.

With dynamic linking, that joining-together process occurs at runtime. And furthermore, if (as is usually the case) several programs are all sharing the same library, just one copy of that library will reside in-memory and all of those programs will share it. The executable file is smaller, no-longer self-contained, and takes a little more time to start running.