RFC: ABI break

Aurelien Jarno aurelien at aurel32.net
Thu Dec 29 11:09:45 UTC 2005


Robert Millan a écrit :
> On Thu, Dec 29, 2005 at 10:50:18AM +0100, Aurelien Jarno wrote:
> 
>>On Sat, Dec 24, 2005 at 03:59:07AM +0100, Petr Salinger wrote:
>>
>>>Hi.
>>>
>>>I thought about it, here is an another approach:
>>>
>>>Bump soname intentionally to libc0.2 and clean up our glibc interface.
>>
>>Bumping the soname is tricky, because it implies rebuilding all packages
>>in the archive, respecting the dependencies (which is even more
>>difficult for packages which needs themselves like gnat or ghc6). Have a
>>look at the c++ transition in Debian, and it is only a small part of the
>>packages. Moreover, it won't be possible to change the packages name to
>>track the changes, so this will be probably lead to package loading both
>>version of the libc at runtime, which causes crashes.
>>
>>I don't say we should not change the soname, but we should avoid that if
>>possible. If it is not possible, we should do it, but I expect a
>>duration of one or two months.
> 
> 
> I think we don't need more problems than what we have.  If ABI changes can be
> handled with versioning, we could even diverge from upstream and keep 0.1
> where they have 1, in case upstream wanted to start with 1.
> 
> Note, however, that as long as there's no real ABI change, bumping the soname
> doesn't imply great effort.  Having both libcs loaded in memory is harmless,
> since they're the same code.  Hence:
> 
>   - No crashes or weird bugs.
>   - Libraries don't really need renaming.
> 
> But we'd need to patch a few packages that (stupidly) hardcode the libc soname
> in the source. 
> 
Are you sure they want to start with 1. AFAIK hurd has libc 0.3 and 
support for hurd is (at least partly) merged upstream.

-- 
   .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
  : :' :  Debian GNU/Linux developer | Electrical Engineer
  `. `'   aurel32 at debian.org         | aurelien at aurel32.net
    `-    people.debian.org/~aurel32 | www.aurel32.net



More information about the Glibc-bsd-devel mailing list