Re: newbie trying to compile libc 2.9 latest

[Nix <nix at esperi dot org dot uk>]

On 5 Feb 2009, Justin Mattock uttered the following:
> On Thu, Feb 5, 2009 at 11:04 AM, Nix <nix@esperi.org.uk> 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

You *have* GNU make, right?

(config.log would be useful for diagnostics here.)

> 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);

MAKE=/your/make/here

CC is, well, the C compiler. make is not a C compiler!

>> 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

If and only if you want a 64-bit libc (in which case you should be
installing in .../lib64 instead of .../lib).

I've not yet built glibc on an x86-64 box, so I'll have to recuse myself
from this bit.

>> 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);

.la files are tiny text files. Did you forget to pass --disable-static,
so you got static libraries for everything?

>                          but if the xserver needs those
> then I'll have to make do.

X does not need the .la files, no, but why not leave them? They're tiny.

>>> 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.

Hang on, is that something you *are* doing or something you find you
*need* to do? You certainly shouldn't need to sudo when building GCC, at
all, and you shouldn't need to build stage3 by hand unless you're doing
something special (generally, hacking gcc, want a quick build, and can't
use quickstrap or bubblestrap for some obscure reason: this is *very*
rare these days).

>>>> 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:
> http://axiom.anu.edu.au/~okeefe/p2b/buildMin/buildMin-1.html

Um, that tutorial is dated September 2000. Decade-old tutorials are
perhaps not the best thing to follow blindly... my advice is to look at
what a gentoo full bootstrap does and figure out why it does each bit.

On immediate inspection, it recommends MAKEDEV (bad idea; you should
generally use udev unless you have a very good reason not to: you're
more likely to get a properly-populated and permissioned device tree);
its kernel build instructions are wrong and weren't even right in 2000;
its glibc instructions don't mention --build=..., don't mention running
'make check' (lethally bad), but do at least mention install_root=; the
bash instructions are needlessly elaborate because they contain
workarounds for bugs in decade-obsolete versions of bash; sh-utils no
longer exists as it was merged with GNU fileutils and GNU textutils to
produce GNU coreutils back in 2000 or thereabouts...

... not everything it says is wrong, but really quite a lot is.

>> 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

glibc doesn't use ROOT. Use of ROOT to specify the installation location
is very rare: lilo uses it, sysvinit uses it, makedev uses it, and I
think that's it among common packages.

Also, it's syntactically incorrect. ROOT=/mnt/* is really unlikely to
work, as a second's thought about how wildcard expansion works in Unix
shells would reveal (hint: /mnt/* expands to /mnt/a /mnt/b mnt/c if
there are three files in /mnt named a b and c...)

I'm afraid that if you don't get basic Unix shell stuff like that,
trying to build a system from scratch, well, it'll be a trial by fire at
the very least. (It might be fun, I suppose.)

> seemed to not work.

It never will.

> make install_root=/ install

Yes. However, I see on linux-kernel that you then tried to install the
*kernel* the same way. install_root is *glibc-specific* and can't be
expected to work for any other package. Most packages support DESTDIR;
most packages that use GNU Autoconf (e.g. have a configure script)
support prefix=; some (often raw-Makefile-based) don't support anything
and need makefile hackery (thankfully rare these days).

> (hopefully it's not too painful
> to compile everything, rather than
> just apt-get);

You are doing 'make check', right? That's what takes the time with many
packages (not so much glibc as GCC). It's really really a very bad idea
to install glibc without checking it first: you only have proof that a
few simple things work (including, thankfully, the dynamic loader
itself) once glibc is installed.