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 12, 2009 at 2:21 PM, Nix <firstname.lastname@example.org> wrote:
> On 10 Feb 2009, Justin Mattock uttered the following:
>> On Mon, Feb 9, 2009 at 3:15 PM, Nix <email@example.com> 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);
>> 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.
sysvinit seems to be one to watchout for(ignores DESTDIR, install_root)
but in the Makefile you can set ROOT = *
(fried my system with that one : ^ )
>>> 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.
I'll have a look into it.
>>> 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
> Yes, the LFS tutorials are pretty damn good.
It really is..
after libc compile and install I decided to give it a try; able to
boot the new kernel
(2.6.29-rc4)as well as operate and recompile libc and the kernel, and
most of the apps.
although I didn't compile gcc-core --with-languanges=c++(for some
reason 4.4.0 didn't let me, or I'm missing
something); and now I'm seeing it with some apps that call cpp during
the ./configure routine.
(something about what to do with /lib/cpp); I'll have to probably
figure out why gcc
wouldn't compile with c++ support in the first place(probably because
of gcc-core being
a prerelease or something in that direction);
>> 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.
Alright(this gets me very excited here); when looking at dmesg I see
processor using core2/atom configuration.
for both cores(not sure if this is good or not but it gets me going);
Now the positive side when running the new system is
(keep in mind shes(the system) still learning to walk)
I'm getting a different reaction with the gpe storm firing off.
I'll have to dig up the bug report for you when I get some time.
(long story short)
As a workaround I always used acpi_osi=Darwin to keep the gpe
storm detector from firing in the kernel(ever since it was introduced
in 2.6.24 or so).
Now with this new core2/atom configuration
It's the opposite using acpi_osi=Darwin triggers the storm,
and running the system normally shows no sighns of a trigger.
keep in mind it still early though.
>> just to make sure I go:
>> make check
>> make install
>> 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.
when looking at the lfs tutorials theres some notes on make check taking
longer than normal with some test suites.
In any case I need to look into gcc-core not wanting to compile c++
language so I can pinpoint the issue with cpp complaint with apps
that use it(I'll send an example when I get some time);
Justin P. Mattock