From patchwork Thu Dec 2 23:33:55 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: libobjc - start reorganization of headers/API Date: Thu, 02 Dec 2010 13:33:55 -0000 From: Matthias Klose X-Patchwork-Id: 74044 Message-Id: <4CF82CE3.3090601@ubuntu.com> To: Nicola Pero Cc: gcc-patches@gnu.org On 02.12.2010 21:43, Nicola Pero wrote: > >> I didn't check which of the original symbols are "private" or public, but some >> symbols are missing, so maybe the soversion should of the library should be bumped? > > Yes, I think we should bump the soversion of libobjc; not only some symbols were > removed, but a lot of others were added. And this is one of the rare cases where > adding symbols may have broken compatibility, because we added a new API compatible > with the Apple one, but some Objective-C programs that use libobjc already had a subset > of that API internally defined on top of the traditional GNU libobjc one. To prevent > conflicts and be on the safe side, these programs would need to be recompiled with their > internal Apple objc runtime API compatibility layer disabled if the new libobjc is being > used. > > If you want to produce a patch that bumps the soversion of libobjc, I'll pre-approve it. I'm testing the following patch. Will commit after a successful bootstrap and installation test. Matthias 2010-12-03 Matthias Klose * configure.ac (VERSION): Bump the version to 3:0:0. * configure: Regenerate. Index: configure.ac =================================================================== --- configure.ac (revision 167398) +++ configure.ac (working copy) @@ -27,7 +27,7 @@ # We need the following definitions because AC_PROG_LIBTOOL relies on them PACKAGE=libobjc # Version is pulled out to make it a bit easier to change using sed. -VERSION=2:0:0 +VERSION=3:0:0 AC_SUBST(VERSION) # This works around the fact that libtool configuration may change LD