Glibc-2.6.1

[Matthew Burgess]

New version. Release announcement at ​http://sourceware.org/ml/libc-alpha/2007-05/msg00055.html. From NEWS:

• New Linux interfaces: epoll_pwait, sched_getcpu.
  
• New generic interfaces: strerror_l.
  
• nscd can now cache the services database. Implemented by Ulrich Drepper.

[ken@…]

Give it a few days to see if 2.6.1 comes out​http://sourceware.org/ml/libc-ports/2007-05/msg00045.html - thanks to Greg Schafer and the DIY list archives for this link.

Meanwhile, anything with a local copy of futimens will need attention - this function is new to 2.6, but locally present in at least coreutils, gzip, tar. Again, the DIY list archives seem a good place to start.

[robert@…]

This Glibc also depends on -march=i486, if you want threading support. GCC's default is -march=i386. Instead of using march=i486 just for Glibc, I suggest using --with-arch=i486 with GCC so everything is built with this option.

I've done this a few times, Debian also does this. It adds the symbol 'bzero' to libc.so, which caused a Glibc test failure in localplt-i386-linux-gnu.data with other Glibc versions. This might have been fixed for Glibc-2.6, since we don't have a choice.

I think I read Glibc-2.6 also depends on linux-2.6.16 to pass all the tests.

[ken@…]

Tar-1.17 should be ok out of the box, it has been changed to use gl_futimens.

[Matthew Burgess]

Now 2.6.1.

[robert@…]

Just as a note, on an Pentium4 with gcc-4.2.1:

I'm getting several extra test suite failures when using --enable-omitfp, which is unusual... Glibc-2.6.1 is the first release that has had a problem with --enable-omitfp, for me.

My best results have been without --enable-omitfp, and

env CC="gcc -march=i486" CXX="g++ -march=i486"

Building GCC with --with-arch=i486 gave the same results... math/test-double.out always fails.

--enable-bind-now has no affect on the tests. I'm also using --enable-kernel=2.6.22.

It looks like Glibc-2.6.1 was not developed or tested well against gcc-4.2.1, but this may only be a test suite problem and not a run time problem.

[Jeremy Huntwork]

Adding

CC="gcc -march=i486"

before Glibc's configure statement should suffice and seems less intrusive to the rest of the build.

[alexander@…]

While this works for sure, a more optimal solution is to compile gcc in such a way that it compiles for i486 or later by default. Rationale: you can't copy code to real i386 anyway, so why lose by default (in all other applications) optimizations that are possible due to new CPU instructions?

I.e.: add --build --host --target to gcc and binutils.

[robert@…]

From an operating system perspective the best solution is to build GCC with --with-arch=i486, explaining that since this will be Glibc's minimum it's improper to pretend applications will run on an i386.

The performance gain from compiling with -march=i486 is close to nothing. This is more of a binary compatibility issue, and I think it's important that if --with-arch=i486 is used in the LFS book that performance is not used as a justification. I wouldn't want this to pave the way for default optimizations in LFS.

IMHO, when you build an operating system all the libraries and applications should be compiled for the exact same architecture (within reason), and using -march=i486 for only 1 package is a bit messed up.

I think I also understand the argument for using CC="gcc -march=i486", in that it's the minimalistic solution, but I think LFS leans towards correctness rather than minimalism.

[Jeremy Huntwork]

Replying to robert@linuxfromscratch.org:

From an operating system perspective the best solution is to build GCC with --with-arch=i486, explaining that since this will be Glibc's minimum it's improper to pretend applications will run on an i386.

I have been reconsidering the above, and I think will try this out on the jh branch.

[dnicholson@…]

Replying to jhuntwork@linuxfromscratch.org:

Replying to robert@linuxfromscratch.org:

From an operating system perspective the best solution is to build GCC with --with-arch=i486, explaining that since this will be Glibc's minimum it's improper to pretend applications will run on an i386.

I have been reconsidering the above, and I think will try this out on the jh branch.

I have nothing to contribute right now, and I haven't thought about the consequences, but I think what Robert is proposing sounds like the the cleanest way to approach this issue. I don't see a good reason to have the compiler's target architecture be one that can't be used by the C libraries. I could definitely be missing something, but I just wanted to add a +1 from a distance.

[robert@…]

The --with-arch=i486 works with Glibc's test suite, all tests can pass with it. It also has no effect on GCC and Binutils tests. I can't imagine any other application would have a problem with it.

For something like cross compiling kernels for i386, the -march=i386 would still work. This is the furthest I could stretch my mind to think of a problem with --with-arch=i486.

[Jeremy Huntwork]

As per discussions on lfs-dev (see the thread starting here: ​http://linuxfromscratch.org/pipermail/lfs-dev/2007-September/060268.html) we opted to adjust CFLAGS.

Fixed as of r8375.

[Mike Smith]

Replying to dnicholson@…:

Replying to jhuntwork@linuxfromscratch.org:

Replying to robert@linuxfromscratch.org:

From an operating system perspective the best solution is to build GCC with --with-arch=i486, explaining that since this will be Glibc's minimum it's improper to pretend applications will run on an ​life insurance quotes i386.

I have been reconsidering the above, and I think will try this out on the jh branch.

I have nothing to contribute right now, and I haven't thought about the consequences, but I think what Robert is proposing sounds like the the cleanest way to approach this issue. I don't see a good reason to have the compiler's target architecture be one that can't be used by the C libraries. I could definitely be missing something, but I just wanted to add a +1 from a distance.

Thank you for this.