This is the mail archive of the
mailing list for the glibc project.
Re: newbie trying to compile libc 2.9 latest
On Thu, Feb 5, 2009 at 11:04 AM, Nix <firstname.lastname@example.org> wrote:
> 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
when I look at the output of ./configure I see gnu make = no
so I figured I might as well make sure some how someway
the new version of make was being used for the compiling.
(using an older version caused some errors);
>>> 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?)
yeah I think so.
leading me to wonder if I should set:
instead of i686
>>> 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).
I think what I'll do is leave the main internal libs
as is, and then further down the road(xserver or so);
start thinning it down.(a few days ago I compile all of the
xserver stuff, and ended up with .la, which took more space
than I had anticipated); but if the xserver needs those
then I'll have to make do.
>>> (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 figured it out(at least I think I did);
sudo mkdir stage3-gcc.
when making gcc-core during then end of
compiling, make needs to mkdir but can't
because of the permissions.
> 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 ;}
but it's worth it.
>>> 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.)
I'll have to do some reading up with this.
(this way I get things right);
>>> 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? :)
here's the url of the tutorial I'm following:
a few days ago I just did a debootstrap install, then
everything else was source(xserver,aterm etc..)
but then said to myself how to do what debootstrap does
without debootstrap.(this way I can make the system thinner);
>> 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
> it's available).
ROOT=/mnt/* make install
seemed to not work.
make install_root=/ install
in any case I'll have to ./configure --help
to make sure.
I really appreciate you're help.
Thank you very much.
(hopefully it's not too painful
to compile everything, rather than
Justin P. Mattock