(bib) libobjc build failure

Stan Shebs shebs@apple.com
Mon Dec 2 16:25:00 GMT 2002

Zack Weinberg wrote:

>Stan Shebs <shebs@apple.com> writes:
>>Zack Weinberg wrote:
>>>The immediate fix is probably going to be to add #includes of
>>>coretypes.h and tm.h to most of libobjc.  The _correct_ fix is to make
>>>libobjc find this stuff out some other way, but I'm not up for that
>>>right now.
>>I believe the root cause is that ObjC requires some reflection-type
>>facilities, and that these were implemented for libobjc by using
>>target macros from tm.h, rather than compiler builtins.
>That is what it looks like to me too.
>>Fixing this doesn't get very high up on anybody's agenda
>>unfortunately; Apple's motivation is limited for instance because OS
>>X doesn't use libobjc.
>Yeah.  I may wind up fixing this as a side effect of getting libgcc
>not to need tm.h either.  Hopefully all of what they want to know
>can be successfully communicated using predefined __macros__.
The ugliest thing is the dynamic synthesis of a method call using
the encoded signature.  Probably a little hard to do with macros
alone!  Everybody would be happy to have it fixed though; libobjc
is frequently broken by tm.h changes, although most of the time
it's runtime breakage for cases not exercised by the testsuite
(passing a small struct followed by a long double to a method,
etc) so it generally goes unnoticed.

>Does Apple's runtime not need to know this stuff, or does it find it
>out differently, or what?  (Not that I'm volunteering to do anything
>with it, mind.)
Apple's does more-or-less the same work, but in assembly code
handwritten for each of the few targets supported.  (Sources
are in the "objc4" project in Darwin, if curiosity overwhelms :-) )


More information about the Gcc mailing list