This is the mail archive of the libc-help@sourceware.org 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 10 Feb 2009, Justin Mattock uttered the following:
> On Mon, Feb 9, 2009 at 3:15 PM, Nix <nix@esperi.org.uk> wrote:
>>> 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.

I meant that you can set that on the make and configure command lines.

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

<http://www.pathname.com/fhs/> may be interesting then.

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

Yes, the LFS tutorials are pretty damn good.

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

This has minimal effect on virtually every app. Even crypto-heavy apps
aren't much affected by CPU optimizations on x86 (unlike on SPARC).
Simply recompiling for 64-bit will have *far* more impact than any other
CPU-specific optimizations on x86, because that gives you more registers,
helping alleviate the platform's chronic register starvation.

> just to make sure I go:
> make
> make check
> make install
>
> not
> make
> make install
> make check

That's a good idea for virtually every app that has a testsuite, and an
especially good idea for those (like glibc) that can completely shag
your system if installed wrong. Some use 'make test' instead. A very few
apps require installation before testing, often because they dlopen()
things from fixed paths (ImageMagick and Subversion spring to mind), but
this should be an ordering you try only if the first ordering fails.


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