This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: newbie trying to compile libc 2.9 latest

On Thu, Feb 5, 2009 at 6:19 PM, Justin Mattock <> wrote:
> On Thu, Feb 5, 2009 at 11:04 AM, Nix <> 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
>> compiler?
> 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:
> --build=x86-64-pc-linux-gnu
> 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.
> but
> make install_root=/ install
> did.
> 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
> just apt-get);
> regards;
> --
> Justin P. Mattock

Hey alright libc finally compiled.
(the beast is alive);
ran into some issues though i.g.
there's some issues when compiling
on a livecd(reason for gcc-core having the permissions
denied; should have been in the home directory);
also probably better having a created account to login into.
Also ran out of disk space(I guess compiling gcc-core takes more
than I had anticipated)

Anyways after finally seeing libc complete,
I issued sudo make install
and then started receiving
Segmentation fault (core dump) in the terminal.
(my guess is, I probably installed some of the new libc
libs over the ubuntu lib's);
here's what I ended up using:

  ./configure ABI=32
--build=core2 CFLAGS="-march=core2 -O2 -pipe -fomit-frame-pointer"

thanks to:
for some pointers. Although I'm still not sure If it was
the command above/or some package that I installed.

Thanks for the info.


Justin P. Mattock

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]