On Fri, Jun 17, 2005 at 09:32:49AM +0100, Andrew Suffield wrote: > On Fri, Jun 17, 2005 at 12:15:25AM -0700, Steve Langasek wrote: > > On Fri, Jun 17, 2005 at 08:07:34AM +0100, Andrew Suffield wrote: > > > On Fri, Jun 17, 2005 at 04:26:36AM +0100, Scott James Remnant wrote: > > > > On Thu, 2005-06-16 at 17:20 -0700, Steve Langasek wrote: > > > > > So, maybe it's time to revisit the weaknesses of the shlibs system, > > > > > particularly as they apply to glibc. Scott James Remnant had done some > > > > > poking in this area about a year ago, which involved tracking when > > > > > individual symbols were added to a package -- apparently, many packages > > > > > would actually be happy with glibc 2.1 or so (at least on i386), but we have > > > > > no way to track this... > > > > I was just thinking the same with this thread ... > > > > The principal problem with the "shlibsyms" stuff was that in order to > > > > track when symbols are added to a package, you need the list of the set > > > > of symbols that were in the last version -- and as the source packages > > > > are put together before the binary, the source package wouldn't contain > > > > the updated set of symbols. > > > Once we begin to deploy icheck, we will have all this > > > information. Haven't yet figured out how to do anything with it. > > > It is not sufficient to track when symbols are added to a package. You > > > must also check when their meaning changes. I have not yet been able > > > to find a way to do this on a per-symbol basis, only a per-library > > > one (I can find examples that break all the 'obvious' approaches). > > However, breaking the meaning of any symbol is supposed to mean that we punt > > by changing the soname, no? > The notable exception would be glibc, which is the really interesting > case here. Right; the issue there being that you have to figure out which version of the symbol the function in your headers currently maps to, not that ELF symbols are themselves repurposed without changing the soname. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature