Re: things that fail to build with gcc and libobjc2

[Sebastian Reitenbach]

On Wednesday, April 06, 2011 11:22:08 am David Chisnall wrote:
> 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.
IIRC, helge used to compile it on apple, so I'll probably find some #ifdefs in 
there that check for the runtime. Is there an easy way to distinguish between 
the traditional and new libobjc2 runtime? is there a #defined version I could 
check?

> 
> > 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.
I'll need to dig into this a bit deeper it seem. reading up the link nicola 
sent too.

Sebastian


> 
> David
> 
> 
> -- Sent from my PDP-11