Re: things that fail to build with gcc and libobjc2

[David Chisnall]

On 6 Apr 2011, at 08:46, Sebastian Reitenbach wrote:

> Hi,
> 
> I recompiled everything yesterday with gcc 4.2.1 and without libobjc2. For 
> some of the stuff in the list I sent in the other thread, I have taken it 
> from 
> svn/cvs since the last releases available releases did not compiled. 
> Everything compiled with it with the new gnustep core from svn.
> 
> Now I tried again to build everything with gcc again, but with libobjc2. The 
> success rate is unfortunately not at 100%.
> 
> SOPE 1.3.4 (1.3.6 will be released probably this week, so still have to test 
> newer version, but I guess there is not much changed in this file) fails to 
> compile this way:

These all look like failures due to trying to inspect the runtime data 
structures directly.  This is not supported with libobjc2 (or with the recent 
Apple runtimes).  I they have code paths for Apple's runtime, then they should 
also work with libobjc2.

> STObjCRuntime.m:67: warning: 'objc_next_class' is deprecated (declared at 
> /usr/local/include/objc/runtime-deprecated.h:41)

As I recall, StepTalk was ported to OS X, so it should already have a code path 
using objc_copyClassList(), which is the replacement that works in libobjc2 and 
on OS X.  The same with all of the later errors: these should use the public 
functions.

Note that most of these structures have the same layout (dictated by the ABI) 
in libobjc2, and many of the unsupported functions are actually provided for 
backwards compatibility, just not exposed in headers, so these may both work if 
you compile using the GCC headers.

> EODebug.m: In function 'DumpIVar':
> EODebug.m:329: error: dereferencing pointer to incomplete type

Sounds like it's trying to walk the ivar list itself, rather than using the 
ivar_* functions.

> EODebug.m:401: error: 'struct objc_object' has no member named 'class_pointer'

Yes, it's called ->isa in libobjc2 (and on every version of the NeXT or 
StepStone runtimes ever.  No idea why the GCC runtime decided to call it 
class_pointer).

All of these things really need fixing upstream, but they should be relatively 
simple to patch in the OpenBSD port otherwise.

David


-- Sent from my PDP-11