autoconf 2.61 gets largefile support wrong when running on a system that has glibc 2.3. As a result applications using largefile detection as advertised will end up with a broken seek implementation and consequently are not able to read files, may hang indefinitely while reading the same file segment over and over, or possibly crash. A long bug report on this issue as it happens with ruby is documented in bug 161566. An explanation of the bug is given in comment #14 on that bug, but the crucial information that is missing there is that this wrong detection only happens when using glibc 2.3. glibc 2.4 and better get the detection right with autoconf 2.61. I'm not sure if it makes sense to patch autoconf to get detection right on glibc 2.3 as well, but perhaps we can make sure that people don't end up with the autoconf 2.61 - glibc 2.3 combination on their system by masking autoconf 2.61 on profiles that still depend on glibc 2.3?
(In reply to comment #0) > I'm not sure if it makes sense to patch autoconf to get detection right on > glibc 2.3 as well, but perhaps we can make sure that people don't end up with > the autoconf 2.61 - glibc 2.3 combination on their system by masking autoconf > 2.61 on profiles that still depend on glibc 2.3? Hmmm, which profiles exactly? This outdated unsupported stuff? # grep -Rni "<sys-libs/glibc" /usr/portage/profiles /usr/portage/profiles/default-linux/ppc/ppc64/2006.0/64bit-userland/packages:8:<sys-libs/glibc-2.4 /usr/portage/profiles/default-linux/ppc/ppc64/2006.1/64bit-userland/packages:8:<sys-libs/glibc-2.4 /usr/portage/profiles/default-linux/sparc/sparc32/2006.1/2.4/packages:8:<sys-libs/glibc-2.4 /usr/portage/profiles/default-linux/sparc/sparc64/2006.1/2.4/packages:9:<sys-libs/glibc-2.4
If there are no arches that need glibc 2.3 anymore then my vote would be to make autoconf 2.61 simply depend on glibc-2.4 or better (iff using glibc) to fix problems for those laggards who don't update all their stuff on a regular basis. Note that repoman provides a bigger list when I tried to make ruby depend on glibc 2.4 or better (just to see what would happen): DEPEND.bad 11 dev-lang/ruby/ruby-1.8.6_p36-r4.ebuild: ~alpha(default-linux/alpha/2006.1) ['>=sys-libs/glibc-2.4'] dev-lang/ruby/ruby-1.8.6_p36-r4.ebuild: ~alpha(default-linux/alpha/2006.1/desktop) ['>=sys-libs/glibc-2.4'] dev-lang/ruby/ruby-1.8.6_p36-r4.ebuild: ~alpha(default-linux/alpha/no-nptl) ['>=sys-libs/glibc-2.4'] dev-lang/ruby/ruby-1.8.6_p36-r4.ebuild: ~alpha(default-linux/alpha/no-nptl/2.4) ['>=sys-libs/glibc-2.4'] dev-lang/ruby/ruby-1.8.6_p36-r4.ebuild: ~hppa(default-linux/hppa/2006.1) ['>=sys-libs/glibc-2.4'] dev-lang/ruby/ruby-1.8.6_p36-r4.ebuild: ~mips(default-linux/mips/2006.1/cobalt/o32) ['>=sys-libs/glibc-2.4'] dev-lang/ruby/ruby-1.8.6_p36-r4.ebuild: ~mips(default-linux/mips/2006.1/generic-be/o32) ['>=sys-libs/glibc-2.4'] dev-lang/ruby/ruby-1.8.6_p36-r4.ebuild: ~mips(default-linux/mips/2006.1/ip27/o32) ['>=sys-libs/glibc-2.4'] dev-lang/ruby/ruby-1.8.6_p36-r4.ebuild: ~mips(default-linux/mips/2006.1/ip28/o32) ['>=sys-libs/glibc-2.4'] dev-lang/ruby/ruby-1.8.6_p36-r4.ebuild: ~mips(default-linux/mips/2006.1/ip30/o32) ['>=sys-libs/glibc-2.4'] dev-lang/ruby/ruby-1.8.6_p36-r4.ebuild: ~ppc64(default-linux/ppc/ppc64/2006.1/64bit-userland) ['>=sys-libs/glibc-2.4']
The problem with simply putting a dependency on glibc-2.4 or higher is that one can build a source tarball with autoconf-2.61 that gets distributed to other systems. I did exactly that when I build jfsutils-1.1.12.tar.gz, only to find that the utilities don't work when built on other systems. I've backed off to autoconf-2.60, hoping that fixes the problem for now.
It's likely that default-linux/ppc/ppc64/2006.1/64bit-userland will get deprecated soon. Unless then I cannot do anything about the <sys-libs/glibc-2.4 stuff in that profile.
sparc doesn't have nothing to do here, since we removed the 2.4 profiles
this bug still relevant ?
It's no longer an issue for me.
I can't imagine this is still an issue