Re: [swarm-hackers] A radical suggestion

[Marcus G. Daniels]

Bill Northcott wrote:

> > The compiler has a different expectation of the runtime when you change
> > to -fgnu-runtime.
> >    
> >
> > I am sorry to be so dense, but I don't really understand that.
> >    
When you make a new class that inherits from something outside your 
library, the reference is encoded in a different way depending on 
whether you are using the Apple/NeXT runtime or the GNU runtime.   In 
the example,  a couple differences are shown in the 
objc_sym_{apple,gnu}.c files.   They are C files just to show that 
although the conventions are different, it's still a C ABI.  In the 
Apple case, a class reference is resolved by making a symbol of the form 
".objc_class_name_Object", and in the GNU case, the symbol looks like 
"__objc_class_name_Object". 

In defobj (insert historical caveats here, blah blah blah) there are a 
number of dependencies on the GNU runtime data structures and compiler 
conventions and then the additional dependency on the mframe code and 
some bug fixes that were added to the Swarm copy of the GNU libobjc 
implementation.  Thus, it is best to either think about 1) treating the 
GNU libobjc runtime and defobj as a black box (and perhaps combining 
them in the physical distribution as we did), or 2) rewriting defobj to 
not have those dependencies.

> > I am thinking libtool may be part of the problem.  As you say, you did not 
> > use it to link your example.  Am I right in thinking that the Swarm 
> > libtool is built by the configure process?
The libtool in Swarm could certainly be relevant, in the sense that it 
is not getting you Swarm's libobjc for some reason (like that GNU 
libtool isn't yet quite right for Mac OS X).  libtool can be fussy, 
since it depends on shell machinery that can have subtly different 
behavior across platforms, and, of course, since weird platforms like 
Darwin have their own weird way of doing things.  If you don't have the 
latest GNU libtool code, it's worth a try re-libtoolize things with the 
latest version.  Then get ready to debug, inspecting all the link 
commands to make sure they are picking up the directories they should, 
and then inspecting the resulting dynamic libraries with, say, `otool' 
to make sure paths were encoded in the right way.

> > When I rename the libobjc.dylib 
> > in the gnu folder I get:
> >
> > [qs-3051:Swarm/MGD2ndexample/gnu] billn% ./example
> > dyld: ./example Undefined symbols:
> > ./example undefined reference to ___objc_class_name_Object expected to be 
> > defined in /usr/lib/libobjc.dylib
> > Trace/BPT trap
I am simply saying that if you link against your own libobjc, the system 
libobjc won't step in front of you -- neither at runtime or at link time.

> > Which bit of code thought of looking for the symbol in 
> > /usr/lib/libobjc.dylib - ld at link time or dyld at load time?
> >    
Dynamic libraries know where they are supposed to be installed.  This 
can happen either by explicit use of -dylib_install_name in the linker, 
the use of -install_name in (Apple's) libtool, or the simple use of -o 
/somepath/somefile.dylib in a gcc invocation.  Attached is an example 
like the last, but the Makefiles are changed a bit so that this 
happens.  You can see the encoded path by using "otool -L example-gnu".  
The system libobjc will only get picked up if the installed version is 
absent since /usr/lib is in the global search path for the dynamic linker.

> > If I replace the libobjc.dylib in the gnu directory with the one from the 
> > Swarm build so far, I get:
> >
> > [qs-3051:Swarm/MGD2ndexample/gnu] billn% ./example
> > dyld: ./example Undefined symbols:
> > _xcalloc
> > _xfree
> > _xmalloc
> > _xmalloc_atomic
> > _xrealloc
> > Trace/BPT trap
> >    
This is a modification to the libobjc distributed with Swarm.  See the 
end of libobjc/misc.c in stock GCC vs. Swarm.  It is occasionally useful 
when debugging Swarm to know that all memory allocations go through one 
place defined in Swarm.  These are defined in src/misc/xmalloc.c.  It is 
also useful for optimizing performance in some cases like GCJ-compiled 
Swarm Java apps (to exclude certain references from the concern of the 
garbage Java collector).

> > It looks like the Swarm libobjc is at least partly functional because it 
> > provided ___objc_class_name_Object, but where did the need for the other 
> > symbols come from?
__objc_class_name_Object is defined when libobjc's Object.m is compiled 
with -fgnu-runtime.

example.tar.gz
Description: application/gzip