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#30559 - [glibc] 2.16.0-1 PKGBUILD symlink /lib64 to /lib destroys /lib64 contents and breaks archiso build

Attached to Project: Arch Linux
Opened by Brian BIdulock (bidulock) - Friday, 06 July 2012, 07:12 GMT
Last edited by Allan McRae (Allan) - Saturday, 07 July 2012, 23:54 GMT
Task Type General Gripe
Category Packages: Core
Status Closed
Assigned To Allan McRae (Allan)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

In the PKGBUILD for glibc 2.16.0-1 the lines:

mkdir ${pkgdir}/lib64
cd ${pkgdir}/lib64
ln -v -s ../lib/ld* .

were changed to

ln -s /lib ${pkgdir}/lib64

Bug #1: This obliterates the /lib64 directory and anything it contains when
upgrading. The FHS says put 32-bit system binaries in /lib and 64-bit system
binaries in /lib64. Any package complying to the FHS will have its 64-bit
system libraries obliterated when glibc 2.16.0-1 updates on x86_64. After
update compliant packages will no longer be able to place their 32-bit libs
in /lib and their 64-bit libs in /lib64 because they are linked.

Bug #2: glibc is part of base. Base needs to be installed before a chroot
environment can be set up during an archiso build. Because an absolute path
is substituted for relative paths, using pacman with an install root to install
base packages for a chroot environment will result in the work/root-image/lib64
directory being linked to the build host's /lib directory when glibc 2.16.0-1
installs instead of work/root-image/lib64.

Please change this back, or better still place all glibc 2.16.0 64-bit binaries
into /lib64 instead of placing them in /lib and linking from /lib64 (only 32-bit
binaries should in /lib). Also the lib32-glibc package should place its binaries
in /lib instead of /usr/lib32 (/usr might not be available and yet there is
nothing stopping a 32-bit binary requiring 32-bit glibc being present in /sbin
or /bin).

Steps to reproduce bug #1:

* Place a file in /lib64 before upgrading to glibc 2.16.0-1
* Upgrade to glibc 2.16.0-1
* Observe that entire /lib64 directory contents are lost on upgrade

Steps to reproduce bug #2:

* Perform an archiso base build.
* observe that ./work/root-image/lib64 links to /lib on the build system
instead of in the work directory.

This task depends upon

Closed by  Allan McRae (Allan)
Saturday, 07 July 2012, 23:54 GMT
Reason for closing:  Not a bug
Additional comments about closing:  "The glibc maintainer has gone postal."
Comment by Allan McRae (Allan) - Friday, 06 July 2012, 13:04 GMT
#1) It will obliterate nothing unless you are very stupid and use -f. Pacman will complain otherwise. Arch is pure 64-bit so its 64 bit libraries are in /lib. We have /lib32 for 32-bit libraries. The /lib64 "directory" is only provided for compatibility with binary blobs and should have only ever contained symlinks to the linker from /lib. Summary: Not a bug.

#2) Is a bug. The symlink should be to "lib" rather than "/lib". Is already fixed in a glibc that will be uploaded to testing in the next day.



Comment by Konstantin Plotnikov (konstantin) - Friday, 06 July 2012, 17:40 GMT
I could confirm that at #1) pacman complain. But if you made such a change why don't you update "Main page" to give instructions what to do in that case?
Pacman is not able to owerwrite directory with a file even with --force (at least for me), so should this directory be removed manually before update?

By the way, lib64 in package also given with a full path "/lib64" instead of relative.
Comment by Allan McRae (Allan) - Friday, 06 July 2012, 22:20 GMT
Pacman can update an _empty_ directory with a symlink. And the only package in our repos that has files in /lib64 is glibc so there directory will be empty unless you have done something to it on your system. You have to deal with unsupported packages or manually created files yourself.
Comment by Brian BIdulock (bidulock) - Friday, 06 July 2012, 23:50 GMT
FHS 2.3 says, in section 6.1.5:

"The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place 64-bit libraries in /lib64, and 32-bit (or 31-bit on s390) libraries in /lib.
The 64-bit architecture IA64 must place 64-bit libraries in /lib.

Rationale:
This is a refinement of the general rules for /lib<qual> and /usr/lib<qual>. The architectures PPC64, s390x, sparc64 and AMD64 support support [sic] both 32-bit (for s390 more precise 31-bit) and 64-bit programs. Using lib for 32-bit binaries allows existing binaries from the 32-bit systems to work without any changes: such binaries are expected to be numerous. IA-64 uses a different scheme, reflecting the deprecation of 32-bit binaries (and hence libraries) on the architecture."

I don't know what you mean by "pure 64-bit", Arch does not even support ia64. Because #1 deviates from the Linux standard, it is a bug according to the Arch FAQ for bug reporting. In fact, the only reason you need to link /lib64 to /lib is because you are placing libraries in the wrong directory in the first place. All software, including glibc, expects 64-bit binaries in /lib64 and 32-bit binaries in /lib on x86_64 (AMD64).

I reported it because the change is going to affect a lot of others. Sure there are no other essential libraries in core that fill these directories, but that doesn't cover AUR or derivative distros, nor anybody else just wanting to develop for Arch. Also, according to the FHS placing 32-bit essential libraries in /usr/lib32 is simply wrong too. Programs expect them in /lib. Runtime linker paths coded into shared libraries and binaries built on LSB compliant systems will not work.

There is no good reason offerred as to why Arch should choose not to comply with the FHS for Linux. It is in fact easier to do it the right (FHS) way. We would not need a lib32-glibc package because the i686 glibc package would do (it already places 32-bit binaries in /lib). All that is required is for the x86_64 glibc package to place its binaries in /lib64 and the lib32-glibc package could go. This would be fully compliant with the FHS and is the way that all other distros do it on x86_64 anyway.

At any rate, I really don't care, I just wanted to report it because I noticed it and thought that Arch cared about following Linux standards and avoiding having to deal with the incompatibilities with upstream that comes from not following adopted Linux standards. But it seems you don't care. Just as well. The nice thing about the ABS is that I can easily fork the glibc build for my own systems. It will just mean 41 forked packages instead of 40.
Comment by Allan McRae (Allan) - Saturday, 07 July 2012, 00:11 GMT
Arch x86_64 has always been a pure 64 bit implementation - it puts its libraries in {/usr,}/lib where all good libraries should go. Arch x86_64 has never followed the rotting piece of garbage that is the FHS, and we are not the only distribution with this setup. ***cough*** Debian ***cough***


Feel free to build your own glibc... but you will have fun tomorrow when /lib becomes a symlink to /usr/lib.
Comment by Brian BIdulock (bidulock) - Saturday, 07 July 2012, 00:25 GMT
Debian has /lib32 but debian supports non-Linux systems (FHS only requires /lib64 for Linux). They put their essential libraries in /lib32, which is sane compared to /usr/lib32. I wouldn't have a problem if you followed debian's approach, put 32-bit in /lib32 and /usr/lib32, put 64-bit in /lib and /usr/lib and symlink /lib64 to /lib and /usr/lib64 to /usr/lib. But the way Arch is now doesn't make any sense at all.

If you symlink /lib to /usr/lib no system that mounts /usr will boot.

If you want to chase people away from Arch, keep it up.
Comment by Allan McRae (Allan) - Saturday, 07 July 2012, 00:26 GMT
> If you symlink /lib to /usr/lib no system that mounts /usr will boot.

You are an idiot.
Comment by Brian BIdulock (bidulock) - Saturday, 07 July 2012, 00:32 GMT
Personal attacks... great.

Buh-bye.
Comment by Dave Reisner (falconindy) - Saturday, 07 July 2012, 00:35 GMT
It's too bad there's nothing that can be done about early mounting /usr when its on a separate partition.

http://mailman.archlinux.org/pipermail/arch-general/2012-January/024124.html
https://wiki.archlinux.org/index.php/Mkinitcpio#.2Fusr_as_a_separate_partition
Comment by Allan McRae (Allan) - Saturday, 07 July 2012, 00:42 GMT
> They put their essential libraries in /lib32, which is sane compared to /usr/lib32.

There is no essential 32 bit libraries on a 64 bit system. So all essential 32 bit libraries are already in /lib32...

So...

>I wouldn't have a problem if you followed debian's approach, put 32-bit in /lib32 and /usr/lib32, put 64-bit in /lib and /usr/lib and symlink /lib64 to /lib and /usr/lib64 to /usr/lib

32 bin in /usr/lib32... check.
64 bit in /lib and /usr/lib... check
symlink /lib64 to /lib... check (hang on, I thought you had an issue with that...)
symlink /usr/lib64 to /usr/lib.. no. Useless symlink that no software every expects.

So there is no problem here apart from /lib64 being a symlink to "/lib" instead of "lib" which is fixed in the glibc build that is currently being tested before upload.
Comment by Brian BIdulock (bidulock) - Saturday, 07 July 2012, 00:57 GMT
> There is no essential 32 bit libraries on a 64 bit system.

This is where you disagree with both LHS and Debian.
Comment by Frederic Bezies (fredbezies) - Saturday, 07 July 2012, 14:03 GMT
Wondering if this is the reason of my no longer working archlinux + testing, I tried to report in bug #30587.
Comment by Brian BIdulock (bidulock) - Saturday, 07 July 2012, 20:28 GMT
The glibc maintainer has gone postal. Expect worse in upcoming glibc updates.

See also,
#30586
#30587
#30588
#30593

Loading...