[arch-general] Installing packages with different glibc
Does it create complications if I install packages built with a newer glibc-2.10.1-2 on a system with an older glibc-2.9-7? According to LFS they say if you chnage glibc you should rebuilt all the installed packages with the newer glibc. Does this hold true for Arch?
On Wed, Jun 10, 2009 at 19:45, Baho Utot<baho-utot@columbus.rr.com> wrote:
Does it create complications if I install packages built with a newer glibc-2.10.1-2 on a system with an older glibc-2.9-7?
According to LFS they say if you chnage glibc you should rebuilt all the installed packages with the newer glibc.
Does this hold true for Arch?
Any packages in a repo should be fine. Other than that, try it. If you get errors, recompile :P
On Wed, 2009-06-10 at 22:05 -0400, Daenyth Blank wrote:
On Wed, Jun 10, 2009 at 19:45, Baho Utot<baho-utot@columbus.rr.com> wrote:
Does it create complications if I install packages built with a newer glibc-2.10.1-2 on a system with an older glibc-2.9-7?
According to LFS they say if you chnage glibc you should rebuilt all the installed packages with the newer glibc.
Does this hold true for Arch?
Any packages in a repo should be fine. Other than that, try it. If you get errors, recompile :P
OH Yea try he says.... pacman -Syu installing stuff shutdown -r now.......... broken desktop machine :P
On Thu, 2009-06-11 at 04:53 -0400, Baho Utot wrote:
On Wed, 2009-06-10 at 22:05 -0400, Daenyth Blank wrote:
On Wed, Jun 10, 2009 at 19:45, Baho Utot<baho-utot@columbus.rr.com> wrote:
Does it create complications if I install packages built with a newer glibc-2.10.1-2 on a system with an older glibc-2.9-7?
According to LFS they say if you chnage glibc you should rebuilt all the installed packages with the newer glibc.
Does this hold true for Arch?
Any packages in a repo should be fine. Other than that, try it. If you get errors, recompile :P
OH Yea try he says....
pacman -Syu installing stuff shutdown -r now.......... broken desktop machine :P
What is the reason exactly for using glibc 2.9-7 instead of 2.10 btw?
On Thu, 2009-06-11 at 10:54 +0200, Jan de Groot wrote:
On Thu, 2009-06-11 at 04:53 -0400, Baho Utot wrote:
On Wed, 2009-06-10 at 22:05 -0400, Daenyth Blank wrote:
On Wed, Jun 10, 2009 at 19:45, Baho Utot<baho-utot@columbus.rr.com> wrote:
Does it create complications if I install packages built with a newer glibc-2.10.1-2 on a system with an older glibc-2.9-7?
According to LFS they say if you chnage glibc you should rebuilt all the installed packages with the newer glibc.
Does this hold true for Arch?
Any packages in a repo should be fine. Other than that, try it. If you get errors, recompile :P
OH Yea try he says....
pacman -Syu installing stuff shutdown -r now.......... broken desktop machine :P
What is the reason exactly for using glibc 2.9-7 instead of 2.10 btw?
Actually I have not tried it yet..... I am compiling/building in a clean chroot and it has 2.10 installed there but one of my systems has 2.9-7 installed. I didn't want to break the system by installing packages built from the clean chroot w/2.10. I will upgrade the glibc to 2.10 later after I am OK with it if it happens to break something, as I need the system not to break until next month. :) Then if it breaks it will be OK.
Baho Utot wrote:
Does it create complications if I install packages built with a newer glibc-2.10.1-2 on a system with an older glibc-2.9-7?
Yes and no. Depending if the executable or library that is linked to glibc uses a symbol with declaring what version use via ELF versioning. You obtain it with a simple "readelf -s /path/to/executable | grep @GLIBC_2.10". Do this "readelf -s /lib/libc.so.6 | grep @GLIBC_2.10" and get an idea of the minimal functions that are only in version 2.10 ;) And for threaded programs /lib/libpthread-2.10.1.so, but don't worry about this at this time.
According to LFS they say if you chnage glibc you should rebuilt all the installed packages with the newer glibc.
Not at all as you can see :)
Does this hold true for Arch?
I doubt at this time. But later when the programs use specific features of this version, for example malloc_info () fallocate (), yes. If you are interested in these topics, can read a good paper from Ulrich Drepper [#1] Good Luck! [#1] http://people.redhat.com/drepper/dsohowto.pdf -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
On Wed, 2009-06-10 at 23:49 -0300, Gerardo Exequiel Pozzi wrote:
Baho Utot wrote:
Does it create complications if I install packages built with a newer glibc-2.10.1-2 on a system with an older glibc-2.9-7?
Yes and no. Depending if the executable or library that is linked to glibc uses a symbol with declaring what version use via ELF versioning. You obtain it with a simple "readelf -s /path/to/executable | grep @GLIBC_2.10".
Do this "readelf -s /lib/libc.so.6 | grep @GLIBC_2.10" and get an idea of the minimal functions that are only in version 2.10 ;)
And for threaded programs /lib/libpthread-2.10.1.so, but don't worry about this at this time.
According to LFS they say if you chnage glibc you should rebuilt all the installed packages with the newer glibc.
Not at all as you can see :)
Does this hold true for Arch?
I doubt at this time. But later when the programs use specific features of this version, for example malloc_info () fallocate (), yes.
If you are interested in these topics, can read a good paper from Ulrich Drepper [#1]
Good Luck!
Ok more reading to do :) Thanks
Gerardo Exequiel Pozzi schrieb:
Baho Utot wrote:
Does it create complications if I install packages built with a newer glibc-2.10.1-2 on a system with an older glibc-2.9-7?
Yes and no. Depending if the executable or library that is linked to glibc uses a symbol with declaring what version use via ELF versioning. You obtain it with a simple "readelf -s /path/to/executable | grep @GLIBC_2.10".
Do this "readelf -s /lib/libc.so.6 | grep @GLIBC_2.10" and get an idea of the minimal functions that are only in version 2.10 ;)
I'm just taking a quick look over some random binaries: $ readelf -s file | grep @GLIBC|cut -d@ -f2 | cut -d\ -f1|sort -u For /bin/bash, this tells me our bash should work with glibc 2.4. /bin/ls should even work with 2.3. In general, all should work unless a new symbol is used, or an old symbol had incompatible changes. This is not often the case in glibc, but there's many more problems with C++ programs and the standard C++ libs.
On Thu, 2009-06-11 at 11:48 +0200, Thomas Bächler wrote:
This is not often the case in glibc, but there's many more problems with C++ programs and the standard C++ libs.
Usually glibc and libstdc++ are backwards compatible. ABI doesn't change so programs compiled against older versions will always work with newer libraries. There's an exception though: programs that do their library versioning after the compiler that was used. Examples of this are Qt and Boost. Compiling Qt 3.x with gcc 4.4 meant recompiling KDE 3.x things because ABI changed in Qt because of a compiler change.
Jan de Groot schrieb:
Usually glibc and libstdc++ are backwards compatible. ABI doesn't change so programs compiled against older versions will always work with newer libraries.
It's about forward compatibility. If you compile a program with a newer libstdc++, it will often not work with an older one.
There's an exception though: programs that do their library versioning after the compiler that was used. Examples of this are Qt and Boost. Compiling Qt 3.x with gcc 4.4 meant recompiling KDE 3.x things because ABI changed in Qt because of a compiler change.
This is still true for boost, but not for Qt 4. Qt 3 however is really annoying in that respect.
participants (5)
-
Baho Utot
-
Daenyth Blank
-
Gerardo Exequiel Pozzi
-
Jan de Groot
-
Thomas Bächler