Community Packages

Please read this before reporting a bug:

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#27579 - [lib32-glibc] please add symlink

Attached to Project: Community Packages
Opened by Alexander F. Rødseth (xyproto) - Wednesday, 14 December 2011, 21:54 GMT
Last edited by Florian Pritz (bluewind) - Friday, 16 December 2011, 11:24 GMT
Task Type Feature Request
Category Packages: Multilib
Status Closed
Assigned To Florian Pritz (bluewind)
Jan Alexander Steffens (heftig)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No



Several Linux applications out there does not work without /lib/

Adding a symbolic link from /lib/ to /lib/ solves the issue, and lets several applications (especially commercial ones, that are branded to be LSB-compatible) run without a hitch.

The popularity of the ld-lsb package in AUR is a testament to how useful this is (498 votes right now).

If this symbolic link was created by lib32-glibc, the "ld-lsb" AUR package [1] would no longer be needed to run (especially) commercial software.

It's cheap and easy to implement and solves a lot of problems.

All it would take, is:

install -dm755 "$pkgdir/lib"
ln -sf "/lib/" "$pkgdir/lib/"

Please consider this option.

Thank you.

This task depends upon

Closed by  Florian Pritz (bluewind)
Friday, 16 December 2011, 11:24 GMT
Reason for closing:  Won't implement
Comment by Alexander F. Rødseth (xyproto) - Wednesday, 14 December 2011, 22:36 GMT
Another, cleaner option might be to move ld-lsb to community and depend on it. That way people can still search for "lsb" if they need it.
Also note that google-earth depends on ld-lsb, for example. The horrible, but popular, license management program "lmflex" (flexnet) also needs it.
Comment by Allan McRae (Allan) - Thursday, 15 December 2011, 10:05 GMT
I guess this won't happen without the actual glibc package on i686 adding it too... (which is not going to happen)
Comment by Jan Alexander Steffens (heftig) - Thursday, 15 December 2011, 10:13 GMT
I agree with Allan here. If this is important, glibc should implement it first. lib32-glibc would follow suit.
Comment by Florian Pritz (bluewind) - Thursday, 15 December 2011, 11:19 GMT
I don't think we'd stop you from moving this to community, but I don't want to do it in lib32-glibc. Symlinking libraries yourself tends to be the wrong way to do it.

You can also try asking glibc upstream, but judging from a blog post Ulrich wrote a while ago, which basically states that ldb is broken and useless, he won't include it either.
Comment by Alexander F. Rødseth (xyproto) - Thursday, 15 December 2011, 14:56 GMT
I understand your positions and agree with the arguments. I can try asking glibc upstream first.
Comment by Alexander F. Rødseth (xyproto) - Thursday, 15 December 2011, 15:11 GMT
I was about to ask glibc upstream about this, then realized it would mean introducing a file conflict for distros that actually try to be LSB-compliant, like Red Hat and CentOS.
This alone would probably mean that the idea would be rejected. So, this would have to be introduced at a level closer to the user and further away from upstream.

Perhaps the ld-lsb package is the cleanest way after all. (Not that this should be needed in the first place, but, the reality of the situation makes it so).

On the other hand, this is only about a single file, /lib/, which is only in the lib32-glibc package, and not in the regular glibc package.

I still think it would be a good idea to create the symlink in lib32-glibc, as it's Arch-specific enough and as it's only about that particular package.

If you still think it's a bad idea, just close this feature request, and I'll fully understand it.