Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#1483 - libc.so.6 problem
Attached to Project:
Arch Linux
Opened by Vinay S Shastry (shastry) - Monday, 20 September 2004, 10:56 GMT
Last edited by Judd Vinet (judd) - Wednesday, 03 November 2004, 21:59 GMT
Opened by Vinay S Shastry (shastry) - Monday, 20 September 2004, 10:56 GMT
Last edited by Judd Vinet (judd) - Wednesday, 03 November 2004, 21:59 GMT
|
Detailsif /lib/libc.so.6 is excuted, an error is displayed:
Inconsistency detected by ld.so: rtld.c: 1259: dl_main: Assertion `_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next' failed! I believe its an issue of glibc with the new 2.6 kernel. (i've marked this as critical since any scripts that depend on this feature of libc.so.6 fail because no info on glibc is displayed) |
This task depends upon
That patch *should* fix the problem. Currently building an NPTL package with all bugfixes I found, including the stuff redhat, mandrake, suse and debian use to support 2.4 kernels with an NPTL enabled glibc.
The glibc 2.3.4 cvs snapshots don't have the problem anymore, so it's fixed in CVS. The only problem is: what was fixed in CVS, and how do we backport it to 2.3.3? I've looked into the code, and some things have changed in elf/rtld.c, but the file is a "few" lines longer than the original, so I can't say what exactly changed.
thanks for the info
- follow gentoo and use their glibc-branch-update patch for glibc (http://dev.gentoo.org/~lv/), but only those marked by them as stable on x86
- follow the stable LFS "release" and use their patched glibc tarballs.
I've worked with the gentoo releases for a while, and before 2.3.3 was released I used some LFS tarballs without problems to create NPTL packages. I think both are not a bad idea. In my opinion, we could go for the LFS stable releases.
As stated on the LFS page:
As of this writing, the Glibc maintainers have decided in their wisdom not to make available new release tarballs for download. As such, the LFS toolchain team have provided a tarball of glibc sources pulled from Glibc CVS (Concurrent Versioning System) and generated a tarball from them, including patches where necessary.
The list with glibc tarballs is on the "required packages" page in their manual.