This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: make libobjc/encoding.c include machmode.h
- From: Jim Wilson <wilson at tuliptree dot org>
- To: Joern Rennecke <joern dot rennecke at superh dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 26 Jun 2003 02:13:34 -0700
- Subject: Re: RFA: make libobjc/encoding.c include machmode.h
- References: <3EF05756.266B9624@superh.com>
Joern Rennecke wrote:
* encoding.c: Include machmode.h.
I don't think this is wise. It merely masks the compiler build failure.
It doesn't solve anything, because now you have a library file that
will give link errors when the user tries to use it. I think that is
worse. We get link errors because stuff like mode_bitsize will be used
but not defined anywhere. Even if it linked, it still wouldn't work.
libobjc has its own type encoding info, the C_* macros. You need to map
any accidental macros brought in from tm.h into the libobjc equivalent.
The inclusion of tm.h in the file was a mistake in the first place. I
don't think we should compound it by adding even more header files.
You mentioned that this is for ROUND_TYPE_ALIGN, but sh.h doesn't define
ROUND_TYPE_ALIGN. Maybe you have some unfinished development work in
your tree? That is OK, but it means I can't reproduce the problem
myself, and hence that makes it difficult for me to look at the details
of this particular problem.
As an alternative, I would suggest disabling libobjc for the sh target.
That should be easy to do, you can put it in noconfigdirs in the
toplevel configure.in. It might be better to disable the entire objc
language, but I don't think we have a mechanism for that.
Curiously, I see that darwin doesn't build libobjc. Darwin being the
major user of the Objective-C language, that probably explains why
libobjc never got fixed. That is unfortunate, since it means
Objective-C is broken for everyone that isn't using Darwin, and may
never be fixed.
Jim