This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: (bib) libobjc build failure
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 :-) )
Stan