This is the mail archive of the
mailing list for the glibc project.
Re: newbie trying to compile libc 2.9 latest
On 5 Feb 2009, Justin Mattock uttered the following:
>>> here is my command line:
>>> sudo /mnt/glib/glibc-20090202/configure --prefix=/usr
>>> CC=/usr/local/bin/i686-pc-linux-gnu-gcc-4.4.0 --enable-add-ons
>>> (I know I need more, but not sure what to use);
> I was using ../configure --prefix=/usr --enable-add-ons
> CC=/usr/local/bin/i686-pc-linux-gcc-4.4.0 CC=/usr/local/bin/make
Why are you setting CC twice, especially (the second time) not to a C
>> You *always* have to provide at least a --build argument, e.g.
>> --build=i686-pc-linux-gnu. The default is i386-pc-linux-gnu, which is
>> too old to build NPTL.
> Should --build=i686-pc-linux-gnu
> be good for a macbook pro?
If it's running Linux, I *think* so, but I'm not sure what they are
internally. There are Mac people here who can answer better than I.
(Aren't they x86-64?)
>> The rest of the configure flags are a matter of taste: personally, last
>> time I built glibc, I built with --prefix=/usr --enable-shared
>> --enable-profile --disable-bounded --enable-bind-now
>> --enable-add-ons=nptl,libidn --enable-kernel=2.6.27
> Will libc work properly without the shared libs?
> trying(for personal use) to build something lightweight.
It will sort of work, but I'm not sure if *anyone* tests glibc with
--disable-shared, because it's so very heavyweight to do so. Expect
'hello world' to turn into something like a 700K binary. static linking
in glibc is really for cases where you *have* to statically link because
the program in question is for recovering from a fried libc, or where
the program is manipulating libc (that basically means sln, ldconfig and
prelink). It's too inefficient to use for anything else. Also you lose
symbol versioning and you if you want name lookups to keep working you
have to keep around the NSS shared libraries for that version of glibc
forever. None of this applies with shared libraries.
People doing static linking tend to use uClibc instead: it's designed
for that and is *much* trimmer (hello world comes out as about 8K there).
>> (Why are you sudoing configure? Never, never, never configure or compile
>> things as root! If you can avoid it, don't even install things as root:
>> use fakeroot or something similar instead. But compilation, no, no,
>> compilers are far too complex beasts to trust with root privileges.)
> This is weired to me i.g. I compiled
> gcc-core with /usr/local/bin/make
> and it compiled up to towards the end
> (something about permissions denied with bash);
I've built GCC many times over the last decade and never had a
permission denied error from it. Are the permissions in the source tree
fried? (You should untar as the same user who does the compilation, or
chown it to that user, unless you really know what you're doing.)
> (keep in mind my brain is fried at the moment
> from compiling, so I'll have to try again later on);
Personally I let the machine do the compiling: my brain gets really
tired of all that building of parse trees ;}
>> Run 'make check' and inspect every failure to make sure that it's one
>> you can live with (e.g. math/test-ildoubl fails on x86-32 and has for
>> years, but it's a tiny least-significant-bit failure that you can
>> probably ignore). ('make check' stops every time it hits a failure: run
>> it again after inspecting that failure and seeing if you're happy with
>> it. Eventually it will complete without error.)
> This is one of the reason why I'm compiling libc from the source
> (want to make sure everything is specified to the hardware);
The only really significant differences on x86 are between x86 with cmov
and x86 without, which is why many distros provide 686-targetted libcs
(note that with glibc you can put per-CPU and per-hardware-capability
stuff in subdirectories of lib/ and have it picked up automatically on
appropriate systems: e.g. lib/i686 or lib/cmov.)
>> Take care not to overwrite your existing glibc when installing. Install
>> somewhere else via 'make install install_root=/installation/location'.
> As of now the hard drive is pretty much empty
> except for a tree that I created, and dev using MAKEDEV.
Not udev? :)
> main concern is once compiling and then installing telling
> make to use /mnt/* as the new root tree.
make install_root=... for glibc, make DESTDIR=... or make prefix=...
for virtually everything else (most packages support both and they don't
*quite* have the same meaning: it's probably best to prefer DESTDIR if