Arch Linux

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

FS#41160 - glibc 2.19-5: ldd 64-bit RTLDLIST path incorrect

Attached to Project: Arch Linux
Opened by Jacob Godserv (javaJake) - Thursday, 10 July 2014, 18:39 GMT
Last edited by Dave Reisner (falconindy) - Thursday, 10 July 2014, 19:15 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture x86_64
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

The current RTLDLIST path says:
RTLDLIST="/usr/lib/ld-linux.so.2 /usr/lib64/ld-linux-x86-64.so.2 /usr/libx32/ld-linux-x32.so.2"
The correct list (according to my research) should be:
RTLDLIST="/usr/lib/ld-linux.so.2 /usr/lib/ld-linux-x86-64.so.2 /usr/libx32/ld-linux-x32.so.2"

The ld-linux-x86-64.so.2 file is found under /usr/lib, so ldd needs to be updated so it can understand this. I discovered this after we rebooted a long-running Arch Linux box and the kernel panicked. (The mkinitcpio script uses ldd to discover library dependencies, so it'd make a useless initramfs with no libraries. That was painful...)
This task depends upon

Closed by  Dave Reisner (falconindy)
Thursday, 10 July 2014, 19:15 GMT
Reason for closing:  Not a bug
Additional comments about closing:  /usr/lib64 points to /usr/lib, making this a non-issue.
Comment by Jacob Godserv (javaJake) - Thursday, 10 July 2014, 18:41 GMT
I marked this as critical because this will render an Arch Linux system unbootable if it's using mkinitcpio to create a boot image, which is part of the installation guide.
Comment by Dave Reisner (falconindy) - Thursday, 10 July 2014, 18:54 GMT
I'd say the real problem here is that /usr/lib64 is a directory on your system rather than a symlink to /usr/lib.

The filesystem package ships this symlink:

$ pacman -Qo /usr/lib64
/usr/lib64 is owned by filesystem 2014.07-1
$ ls -l /usr/lib64
lrwxrwxrwx 1 root root 3 Jul 4 08:44 /usr/lib64 -> lib

So, you'll need to figure out what you broke.
Comment by Jacob Godserv (javaJake) - Thursday, 10 July 2014, 19:12 GMT
Ah. Yes. We tested a custom-compiled chromium by dumping it into the root filesystem. I thought we had undone all the changes, but apparently not.

Thank you for the pointer. This bug is most likely invalid.

Loading...