Re: newbie trying to compile libc 2.9 latest

[Justin Mattock <justinmattock at gmail dot com>]

On Mon, Feb 9, 2009 at 3:15 PM, Nix <nix@esperi.org.uk> wrote:
> 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?

yeah: make-3.81
from gnu.org

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

If I really have to change the Makefile I look for that.

>
> 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 did not know that.

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

I have a major case of O.C.D...
just kidding
(at the end of the day I'll probably leave them)

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

This was what I was doing wrong,
bad habit with using aterm -e sudo su

>>>>> 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.
>
the sad thing is 2000 seems like it was just yesterday.
this is more like it
http://www.linuxfromscratch.org/lfs/view/development/chapter01/chapter01.html

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

I did a test install of udev a day ago, everything seemed o.k.
just have to get used to not having things automatically
put there.i.g.(/etc/udev/rules.d/*)

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

linux from scratch is what I'll use.
(this way I get things correct);

as for the fun side(when I'm not in pain with my back) it is..
especially things like atomically setting every app(if said correctly)
to the processor.

>
>> seemed to not work.
>
> It never will.
>
>> make install_root=/ install

yep

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

I'll try and remember too(seems to take a while);
just to make sure I go:
make
make check
make install

not
make
make install
make check

regards;

-- 
Justin P. Mattock