[arch-dev-public] Toolchain changes
In my ongoing quest to bring packages to being as vanilla as possible, I have made some adjustments to the toolchain. These are nothing that anybody should notice, but I though it worth a post here. The changes: 1) /lib and /lib64 symlinks have been moved from glibc to the filesystem package. Also a /usr/lib64 symlink has been added (see below). This will make updates more difficult (though not impossible) for those who do not have the /lib symlink yet. But if you have not upgraded in over six months, why do you use a rolling release? The workaround I provided of temporarily using a glibc-2.16 package without the lib symlink is in the process of dying anyway with packages build built with glibc-2.17. 2) The "pure64" patch has been removed from glibc. Well, part of it. I added a sed to keep the 64bit system library directory as /lib. Even though /lib64 is effectively the same, pacman-4.0 can not handle that well. This changes the ELF interpreter on x86_64 from /lib/ld-linux-x86-64.so.2 to /lib64/ld-.... Again, symlinks make this not matter. 3) I do not adjust the paths in ldd any more - this required the /usr/lib64 for it to keep working. The /lib64 symlink is not enough as I configure glibc to use /usr/lib as its system library directory. 4) ldconfig gets a symlink in /usr/bin. This will probably be helpful in the future when /sbin dies. Also, I do not remove the default of ldconfig searching /usr/lib /usr/libx32 /usr/lib64, so "ldconfig -v" will complain about /usr/lib64 being given more than once as it is /usr/lib (and any other directory added in ld.so.conf) and about /usr/libx32 being absent. I might see if this can be fixed through adding a configure option upstream, but given no-one will probably notice it is not worth fixing. Wouldn't it be great if everything was just ./configure; make; make install... tl:dr; things will get more difficult for those who have not updated in six months, but no-one should notice any other change. Allan
Am 22.01.2013 07:22, schrieb Allan McRae:
This changes the ELF interpreter on x86_64 from /lib/ld-linux-x86-64.so.2 to /lib64/ld-.... Again, symlinks make this not matter.
While this is a bit sad, it makes Arch's binaries compatible with other distributions.
1) /lib and /lib64 symlinks have been moved from glibc to the filesystem package. Also a /usr/lib64 symlink has been added (see below).
I hate to say that, but I'm actually glad that there's now a /usr/lib64 symlink. Even though I prefer /usr/lib over /usr/lib64 on pure 64bit system (why be so redundant),it will help at least one application – I already have to create such symlink for one of my AUR packages. Lukas
On Tue, Jan 22, 2013 at 1:22 AM, Allan McRae
In my ongoing quest to bring packages to being as vanilla as possible, I have made some adjustments to the toolchain. These are nothing that anybody should notice, but I though it worth a post here.
The changes:
1) /lib and /lib64 symlinks have been moved from glibc to the filesystem package. Also a /usr/lib64 symlink has been added (see below).
This will make updates more difficult (though not impossible) for those who do not have the /lib symlink yet. But if you have not upgraded in over six months, why do you use a rolling release? The workaround I provided of temporarily using a glibc-2.16 package without the lib symlink is in the process of dying anyway with packages build built with glibc-2.17.
2) The "pure64" patch has been removed from glibc. Well, part of it. I added a sed to keep the 64bit system library directory as /lib. Even though /lib64 is effectively the same, pacman-4.0 can not handle that well.
This changes the ELF interpreter on x86_64 from /lib/ld-linux-x86-64.so.2 to /lib64/ld-.... Again, symlinks make this not matter.
3) I do not adjust the paths in ldd any more - this required the /usr/lib64 for it to keep working. The /lib64 symlink is not enough as I configure glibc to use /usr/lib as its system library directory.
4) ldconfig gets a symlink in /usr/bin. This will probably be helpful in the future when /sbin dies. Also, I do not remove the default of ldconfig searching /usr/lib /usr/libx32 /usr/lib64, so "ldconfig -v" will complain about /usr/lib64 being given more than once as it is /usr/lib (and any other directory added in ld.so.conf) and about /usr/libx32 being absent. I might see if this can be fixed through adding a configure option upstream, but given no-one will probably notice it is not worth fixing.
Wouldn't it be great if everything was just ./configure; make; make install...
tl:dr; things will get more difficult for those who have not updated in six months, but no-one should notice any other change.
And much harder for people who have already decided to play around with /bin as a symlink. This all broke me pretty hard because I tried to upgrade glibc by itself (I necessarily needed a different package which doesn't have "duplicate" ldconfig files in it). My own fault, of course, but it should be noted that anyone else could potentially run into this if glibc isn't upgraded at the same time as the filesystem package. Oh well, at least I'll be home tonight to fix it.
I think I need to write a news announcement for this, even though everything should go smoothly, it never does. ---DRAFT--- Update filesystem-2013.01-1 and glibc-2.17-2 together Due to moving of the /lib symlink from the glibc package to the more appropriate filesystem package, it is required to update glibc-2.12-2 and filesystem-2013.01-1 together. This will happen automatically when you run "pacman -Syu". Remember, partial updates are not supported... A potential issue with the upgrade on x86_64 is finding conflicting files in /usr/lib64. All Arch Linux packages that had files in this directory have been updated, so update these individually first. Any AUR packages with files in this directory should be updated to install them in /usr/lib. ---END DRAFT--- The other option is to add a filesystem>=2013.01 dependency to glibc, but that would result in some nasty circular dependencies due to deps in the filesystem package. Allan
On 24 January 2013 01:57, Allan McRae
I think I need to write a news announcement for this, even though everything should go smoothly, it never does.
---DRAFT--- Update filesystem-2013.01-1 and glibc-2.17-2 together
Due to moving of the /lib symlink from the glibc package to the more appropriate filesystem package, it is required to update glibc-2.12-2 and filesystem-2013.01-1 together. This will happen automatically when you run "pacman -Syu". Remember, partial updates are not supported...
A potential issue with the upgrade on x86_64 is finding conflicting files in /usr/lib64. All Arch Linux packages that had files in this directory have been updated, so update these individually first. Any AUR packages with files in this directory should be updated to install them in /usr/lib.
---END DRAFT---
The other option is to add a filesystem>=2013.01 dependency to glibc, but that would result in some nasty circular dependencies due to deps in the filesystem package.
Allan
I'd go with the news item instead of the versioned dependency. It's worth reiterating that partial updates are not supported and the second paragraph contains useful information for people who run into any problems.
Am 24.01.2013 00:57, schrieb Allan McRae:
---DRAFT--- Update filesystem-2013.01-1 and glibc-2.17-2 together
Due to moving of the /lib symlink from the glibc package to the more appropriate filesystem package, it is required to update glibc-2.12-2 and filesystem-2013.01-1 together. This will happen automatically when you run "pacman -Syu". Remember, partial updates are not supported...
A potential issue with the upgrade on x86_64 is finding conflicting files in /usr/lib64. All Arch Linux packages that had files in this directory have been updated, so update these individually first. Any AUR packages with files in this directory should be updated to install them in /usr/lib.
---END DRAFT---
The usual "under no circumstances, use the --force option" warning would be helpful.
The other option is to add a filesystem>=2013.01 dependency to glibc, but that would result in some nasty circular dependencies due to deps in the filesystem package.
You can use versioned conflicts on both packages to achieve this without creating dependency cycles.
participants (5)
-
Allan McRae
-
Dave Reisner
-
Evangelos Foutras
-
Lukas Jirkovsky
-
Thomas Bächler