Jan Engelhardt wrote:
On Sunday 2013-01-13 05:32, Linda Walsh wrote:
Then I kept getting lots of error messages like: `/usr/lib64/libvirt/virt-aa-helper: /lib64/libc.so.6: version `GLIBC_2.16' not found (required by /usr/lib64/libvirt/virt-aa-helper)' prelink: /usr/bin/virsh: Could not parse `/usr/bin/virsh: /lib64/libc.so.6: version `GLIBC_2.16' not found (required by /usr/lib64/libvirt.so.0)' prelink: /usr/bin/virt-viewer: Could not parse `/usr/bin/virt-viewer: /lib64/libc.so.6: version `GLIBC_2.16' not found (required by /usr/lib64/libvirt.so.0)'
(except it was GLIBC_2.15... I used to be able to install higher level libraries and **usually** have them work just fine -- but with a hard-coded symbol in the binary, that's no longer possible.
Are you saying ALL programs use the new GLIBC features, as that used to not be the case.
All programs in openSUSE version xyz use the features of the particular glibc that is shipped in openSUSE xyz.
I find that hard to believe. I would believe that some use new features, but sometimes, the difference between versions are bug fixes. I can't believe that all programs relied on the bug fix and would fail without it. Just to be clear. I realize that there is no guarantee taking a program from V.[v+n] and having it run on a V.v system, however, it was possible to ***try*** this in suse versions prior to 12.0 -- USUALLY with success if prereqs were met. Now, It is far more difficult. A user has to build a custom GLIBC library for 2.14, that includes the 2.15 and 2.16 symbols just to satisfy run-time references. It seems encouraging the development of libraries with false versions in them is not a great thing to do. But it seems to be the only solution to run new programs (say from 12.2 or factory) on 12.1. In the 9.x series and the 10.x series I upgraded piecemeal and experience no major problems in downtime. Did it for 11.1 as well, but for 11.4, I did a full upgrade and it was a disaster, with myself finding problems 3-6 months later caused by the upgrade. So why are GLIBC versions being hard coded into binaries when they didn't used to be -- and that "worked" fine (for some definition of 'fine' ;-)). It wouldn't be so bad if I could just rebuild packages from 'later releases' on a current version, BUT, in many cases, the build files have changed, making this difficult or near impossible. So question -- if I build a binary on OBS -- can I specify what OS it is being built for? Or is it always going to build for factory? I.e. if I take the source rpm for "12.2/3 can I tell OBS to build it in a 12.1 environment? Example -- perl5.16 doesn't seem to build on 12.1. Last summer others showed me it building on OBS as proof that it built, but that's not the same as saying it builds on 12.1, for example. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org