Bug#892153: Objective-C libraries (was: Bug#892153: marked as done (RFS: addresses-for-gnustep/0.4.8-3 [RC]))
Paul Wise wrote: > Hmmm, what about something that looks at the headers? This is possible in theory although it looks complex, fragile and insufficient to me. It would help library maintainers to detect API breaks and subsequently ABI breaks (at least one source for them), but I can't see how it would achieve what symbols files do for C/C++. An object type can be unknown at compile time so it would be impossible to determine which method is going to be actually performed at runtime; two unrelated classes may have methods with the same name. Application code can also obtain a specific method implementation with libobjc functions and execute it directly as a C function -- this is transparent and unrelated to the public API. An ABI compliance checker for Objective-C would be a nice thing but it would be quite a project. Such a tool should be intelligent enough to analyze the whole code and not just the headers.
Bug#892153: Objective-C libraries (was: Bug#892153: marked as done (RFS: addresses-for-gnustep/0.4.8-3 [RC]))
On Mon, Mar 12, 2018 at 4:20 PM, Yavor Doganov wrote: > Because of the dynamic nature of the language this information is not > available at build time. Hmmm, what about something that looks at the headers? -- bye, pabs https://wiki.debian.org/PaulWise
Bug#892153: Objective-C libraries (was: Bug#892153: marked as done (RFS: addresses-for-gnustep/0.4.8-3 [RC]))
Paul Wise wrote: > On Mon, Mar 12, 2018 at 2:02 AM, Yavor Doganov wrote: > > If -initWithAddressBook:readOnly: is removed in a new version of the > > library, that's an API/ABI break but again, it won't be reflected in > > the symbols table. In a C/C++ library you'll see a symbol > > disappearing but it won't happen here. So even the secondary reason > > for using symbols files (detecting ABI breaks, although that's really > > a weak test) is not applicable. > > Is there some public indicator of the actual symbols changes? It > sounds like Debian's core dependencies infrastructure needs to be > extended to understand Objective C ABIs. No, and I don't think there's a bug in the toolchain or some kind of limitation. Every method of every class is avaialble at runtime. Application code can introspect to find out if a method is available, can override a method, swap implementations, etc. The runtime performs lookup whether an object responds to a particular selector by checking the class dispatch table, resorting to the forwarding mechanism. The Objective-C compiler does a very basic job by translating method calls to libobjc function calls; all the queries and decisions which function pointer to execute as the method's implementation are deferred and performed by the Objective-C runtime. Because of the dynamic nature of the language this information is not available at build time. As for public vs. private, methods and classes are private only by convention, the runtime has no way to distinguish them. Using private methods is poor practice but you don't get any penalty like implicit function declaration in C.
Bug#892153: Objective-C libraries (was: Bug#892153: marked as done (RFS: addresses-for-gnustep/0.4.8-3 [RC]))
On Mon, Mar 12, 2018 at 2:02 AM, Yavor Doganov wrote: > If -initWithAddressBook:readOnly: is removed in a new version of the > library, that's an API/ABI break but again, it won't be reflected in > the symbols table. In a C/C++ library you'll see a symbol > disappearing but it won't happen here. So even the secondary reason > for using symbols files (detecting ABI breaks, although that's really > a weak test) is not applicable. Is there some public indicator of the actual symbols changes? It sounds like Debian's core dependencies infrastructure needs to be extended to understand Objective C ABIs. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#892153: Objective-C libraries (was: Bug#892153: marked as done (RFS: addresses-for-gnustep/0.4.8-3 [RC]))
Adam Borowski wrote:
> On Tue, Mar 06, 2018 at 08:28:17AM +0200, Yavor Doganov wrote:
> > * Package name: addresses-for-gnustep
> >Version : 0.4.8-3
> I don't understand ObjC library stuff well enough to adequately
> check these parts, but it's unlikely we'd get someone else who can
> review this... and you know what you're doing.
I'd be happy to explain the changes that raise questions.
I guess you refer to dropping the symbols files? If so, please take a
look at lintian #749202. If it's still unclear, let me give an
example with the smallest class in the Addresses framework:
@interface ADPublicAddressBook: ADAddressBook
{
BOOL _readOnly;
ADAddressBook *_book;
}
- initWithAddressBook: (ADAddressBook*) book
readOnly: (BOOL) ro;
@end
The symbol is just __objc_class_name_ADPublicAddressBook@Base. Now,
imagine if a new upstream version 0.4.9 adds another instance method
-doSomething which is an API addition. This API addition will not be
reflected in the symbols file and apps using the new -doSomething
method will still pick up the lax dependency on 0.4.6. And as a
result will get an NSInvalidArgument exception (abort) if run with an
older version of the library. This totally defeats the purpose of
using symbols files, which as I understand it is an enhancement of the
shlibs system to provide fine-grained dependencies. Not only that
they are not fine-grained, they are simply wrong in this case.
If -initWithAddressBook:readOnly: is removed in a new version of the
library, that's an API/ABI break but again, it won't be reflected in
the symbols table. In a C/C++ library you'll see a symbol
disappearing but it won't happen here. So even the secondary reason
for using symbols files (detecting ABI breaks, although that's really
a weak test) is not applicable.
There's also the case that private classes and class categories also
get their own symbols (as there is no concept for "private" in
Objective-C, everything is exposed to the ObjC runtime). These will
trigger spurious additions/removals of symbols when no public API is
involved at all.
> Uploaded.
Many thanks for sponsoring.
