This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] change GLIBC PPC64/ELF2 ABI default to 2.17
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Adam Conrad <adconrad at 0c3 dot net>
- Cc: munroesj at us dot ibm dot com, Brooks Moses <brooks dot moses at dpdx dot net>, libc-alpha at sourceware dot org, carlos at redhat dot com
- Date: Fri, 31 Jan 2014 14:31:43 -0800 (PST)
- Subject: Re: [PATCH] change GLIBC PPC64/ELF2 ABI default to 2.17
- Authentication-results: sourceware.org; auth=none
- References: <20140131201607 dot GG99202 at jinx> <1391202081 dot 1683 dot 17 dot camel at spokane1 dot rchland dot ibm dot com> <20140131213241 dot GP15976 at 0c3 dot net> <20140131215927 dot 769937441B at topped-with-meat dot com> <20140131221818 dot GQ15976 at 0c3 dot net>
Package systems are only part of the issue. If someone gets a binary by
whatever means (for example, ISVs often just distribute tarballs rather
than using any distro package systems, problematic as that can sometimes
be), then in the normal cases you can't start the binary up and then have
it die later with a symbol resolution failure. The symbol version
requirements in the executable make it die safely at startup, before you
might have expected the program to succeed at doing anything, rather than
at some hard-to-predict time during the run when no graceful recovery is
possible.
I'm less knowledgeable about the RPM/Fedora/RHEL packaging details than I
used to be. But I believe it's the case that rpmbuild examines the actual
binaries to see what SONAME+version-set combinations they require, and
makes those the dependencies of the binary package. Likewise, it examines
DSO binaries to see what SONAME+version-set combinations are provided, and
makes those abstract dependency tags (called "Provides"/"Requires" in
rpmspeak) what the binary package containing a DSO lists. Binary packages
don't usually have explicit package dependencies on the binary packages
that provide the shared libraries they use. The SONAME+version-set
dependency tags are satisfied by the matching tags on the library binary
packages. (My description is a bit overly cumbersome because I can't
remember all the terminology that rpm uses for the dependency features.)
This methodology exactly mirrors how the underlying dependencies between
binaries work and are checked at runtime. Thus the package system does not
impose any artifical dependencies: if you build a package on a newer Fedora
system but it does not use any symbol versions introduced recently, then
you can install that package on an older Fedora system just fine. That's
entirely sensible, since it should run just fine there too.
I don't know why you'd do it any other way. (Well, I can think of some
well-intentioned reasons as well as some entirely indefensible ones,
but I don't think there are any actual good reasons.)
Thanks,
Roland