Bug 11572 - [3.4 regression]: GNU libobjc no longer compiled on Darwin
Summary: [3.4 regression]: GNU libobjc no longer compiled on Darwin
Alias: None
Product: gcc
Classification: Unclassified
Component: libobjc (show other bugs)
Version: 3.4.0
: P1 normal
Target Milestone: 4.0.3
Assignee: Not yet assigned to anyone
Keywords: build
Depends on:
Reported: 2003-07-18 10:38 UTC by Nicola Pero
Modified: 2005-10-07 03:10 UTC (History)
5 users (show)

See Also:
Target: *-*-darwin*
Known to work: 4.0.0
Known to fail: 3.4.0
Last reconfirmed: 2005-09-10 05:58:51

Proof of concept Patch (-fgnu-runtime/-fnext-runtime) (1.04 KB, patch)
2003-08-18 17:03 UTC, David Ayers
Details | Diff
Patch which I am submitting for the include (2.40 KB, patch)
2004-06-12 06:03 UTC, Andrew Pinski
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nicola Pero 2003-07-18 10:38:46 UTC
The GNU libobjc is no longer available to Darwin users.

This is a regression (since GNU libobjc was available in previous releases),
forcing users who had been using the free GNU runtime to switch to use 
the non-free NEXT runtime (a switch which moreover is not always possible).

The patch is the following - 


see also -

Comment 1 Andrew Pinski 2003-07-18 10:56:00 UTC
There were plans to merge the two runtimes but it was far off.
Comment 2 Dara Hazeghi 2003-07-18 18:03:03 UTC
Confirmed. Seems like a patch should be pretty straightforward?
Comment 3 Andrew Pinski 2003-08-14 00:56:45 UTC
Well the lincese on the Next's Runtime has changed to be ASPL 2.0 which is considered 
free software by the FSF now so the non-free agrunment no longer applies.
Comment 4 David Ayers 2003-08-14 09:34:43 UTC
Quote from:

The Apple Public Source License (APSL), version 2.
    This is a free software license, incompatible with the GNU GPL. We recommend
that you not use this license for new software that you write, but it is ok to
use and improve the software released under this license.

Which references:

So technically, yes it seems to be categorized as "free software" by the FSF but
as it is incompatible with the GPL it is useless for pretty much all GNU
projects (such as GCC and GNUstep) which are licensed under the GPL or LGPL. 
Also the fact that it is the only runtime GCC supports that I know of, that is
not (and cannot) be distributed with GCC itself.

I can only reiterate that I have a hard time accepting that it could be in the
interest of the FSF GCC to default to this runtime in favor of the GNU runtime.
 It seems even more absurd that GCC delivers without a working GNU runtime on
this platform.  I have no quarrel with Apple changing that default to their
runtime on the products that they deliver.  That is their prerogative.
Comment 5 Andrew Pinski 2003-08-14 12:15:55 UTC
Even though it does not come with GCC, it comes with the OS which it is default for the non-issue 
for GCC not to come with.
The other runtimes that GCC does not come with is a C runtime so think the NeXT Objective-C 
runtime as just as a C library would be.
Comment 6 David Ayers 2003-08-18 17:03:53 UTC
Created attachment 4616 [details]
Proof of concept Patch (-fgnu-runtime/-fnext-runtime)

This patch shows how it could be done.	The fact that Apple's runtime is
installed in /usr(/include) gives us no choice but to tweak the GNU runtime
:-/. It may also lead to #include <objc/AppleOnlyObjCFile.h> to be taken from
Apple's runtime instead of reporting that the header couldn't be found despite
-fgnu-runtime.	Also any ObjC runtime headers installed in /usr/local will
always be used despite *any* -f*-runtime flag.

The hardest part is creating a test case or actually tweaking the testsuite
structure.  Currently it can only be run for one runtime.  Eventhough some test
use -f*-runtime, they *all* use the GNU runtime headers from the source even on
Darwin, if I interpret this correctly:

see testsuite/lib/objc.exp:
 set objc_include_dir "${srcdir}/../../libobjc"
 lappend options "additional_flags=-I${objc_include_dir}"

I'm new to DejaGNU so don't expect a fix to the testsuite too soon, but next to
fixing that issue, we should make an effort to run the objc tests for both
runtimes on Darwin (as soon as configuration of the GNU runtime is reenabled).

This patch is not Darwin specific, and I'm not sure it should be.  I've
currently been unsuccessful in installing OpenDarwin's ObjC Runtime on my
GNU/Linux box as it seems to preclude an existing Apple Runtime.  But any
pointers on how this could be done are appreciated.

This approach may have implications on ObjC compile time because it adds an
extra search path. The patch currently does this implication for all languages,
but I'm not really sure what happens when other languages may include objc
headers.  But I see no way around that and I have no idea whether the impact is
really that substantial.

I'd be thankful for feedback.
Comment 7 Andrew Pinski 2003-08-18 19:12:19 UTC
I think a better way to do this patch is to use specs instead of tweaking the source files because it 
is more flexible.
See CPP_SPEC and config/darwin.h.
I would only have this done for *-darwin*.
Comment 8 David Ayers 2003-08-18 19:53:34 UTC
Thanks for the feedback.  I'll have a look at CPP_SPEC.

But I'm not sure why we want this only on Darwin.  Should Darwin be tho only
platform on which the Apple runtime can be used?  Is there something inherently
Darwin specific about the runtime?
Comment 9 Andrew Pinski 2003-08-18 19:57:25 UTC
The NeXT runtime is written in asm so maybe not.
Note I have no power over getting any thing approved so when you feel the patch is ready I would 
send it on and have the powers to be to comment on it.  
Comment 10 David Ayers 2003-08-19 15:06:05 UTC
If I undestand you correctly, you're suggesting somthing like:
Could someone please give me pointer with what I could sensibly replace:
with (or where(how) I could implement this).
I've been scanning throught he gcc(int) manual for quite some time but seem to
keep missing the correct link to the section I need.

BTW: This is very neat indeed, as it also solves the /usr/local issue.  Thanks
for the pointer!
Comment 11 Andrew Pinski 2003-11-19 07:04:19 UTC
This is still true but I really would like the two runtime merged or at least have them both 
support each other's API's.
Comment 12 David Ayers 2003-11-19 11:31:21 UTC
Yes I agree!  It would be great if we could:

a) merge the runtimes
b) merge the API of the runtimes or
c) add support for the alternate runtime within the runtimes

In GNUstep we already attempt c) by redefining some trivial mappings and provide
functions that offer an abstraction layer for the parts of the API, whos mapping
is non-trivial.  This is far from complete but features are added as the need

One thing we must avoid, is to create a third API without committing to it.  It
has been stated that Apple requires binary compatibility and (implied)
non-portable optimizations.  Personally, I think the most important requirement
for the GNU runtime is portability and maintainability.  I am uncertain in what
time frame a) and b) could be achieved with these requirements (and those
potentially raised by others), but I think providing at least c) (or an
alternative way to build the GNU runtime on Darwin) should be targeted in the
near future (which includes 3.4 and 3.3).

I still think there remains a license issue which still warrents building the
GNU runtime on Darwin but for practical reasons I'd personally concede to c) as
a first step.

PS: It seems that this alternative patch was only sent to gcc-patches and never
tracked here.  I think it's quite a hack, but it may be an alternative until we
reach one of the above options.  Let me know whether it can be considered
conceptually valid enough to update it and attach it to the PR.

Comment 13 Andrew Pinski 2004-01-23 01:59:42 UTC
This one is mine, I will take care of it.  This is a regression but almost everyone who uses 
Objective-C on Darwin uses the NeXT runtime so keeping target at 3.5.0, this also might need 
more than a simple fix.
Comment 14 Andrew Pinski 2004-01-29 17:15:44 UTC
Note I was not saying the whole truth in the pervious comment.  Most Darwin users of 
FSF's gcc do not nessarly use the NeXT runtime.   A lot of people use the FSF's gcc to get 
the GNU runtime but when they find that they cannot use it, they are upset.
Comment 15 Carl Eugen Hoyos 2004-03-19 13:14:52 UTC
Why was the target for Bug 11572 changed?

I originally reported it, but since I wasn't CC'd (my fault!), I didn't see its
target change to 3.5. I really can't understand why this bug was targeted for 3.5!

It's quite simple to fix the bug, just undo the patch
http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01296.html - it does nothing useful

I think the best idea to fix the bug would be to port Apples configuration
option --enable-libobjc, which would (if I understood correctly) enable the gnu
objc runtime and make the gnu-runtime standard for the precompiler. Since the
option would be disabled by default on darwin, nothing would change for Apple,
but whoever wants could use the gnu runtime without fiddling around with the
configure scripts could do so!

It would be nice if the bug could be fixed for 3.4.0 or, at least, 3.4.1.

Thank you, Carl Eugen
Comment 16 Wolfgang Bangerth 2004-03-19 13:57:24 UTC
Interesting. Geoff, from the follow-ups to the cited patch of yours, 
it is not clear that any consensus had been reached at all whether the 
patch is a good idea or not. Could you comment on this PR? 
Comment 17 Andrew Pinski 2004-03-19 14:47:41 UTC
Here is my stab at the explanation why the patch to undo the change is not the right one.
On Darwin there is an already a libobjc.dyld so now with this GNU runtime in place you 
cannot use the one that comes with Darwin and that would be a regression in itself as 
before 3.4 because the GNU runtime was built as a static library (most likely still is if we 
revert the patch without some more fixes).  The runtime would not be found as Darwin's 
linker looks for .dyld (shared libraries) first and if it finds one in the search path it stops 
(some can consider this a bug but others consider this a feature, I have no view on this) 
so it would not find the GNU runtime unless you (the user and I want to say not the 
Makefile) make a symbolic link to libobjc.dyld.   The include files is a different story as 
you now (with the patch reverted) two different include files named the same thing and 
sometimes one gets picked up and you do not want that one to be picked.

But anyways the right fix is to have -fgnu-runtime to link against the correct libobjc and 
make sure that it includes the right headers which is semi what the proof of concept patch 
does but only for the include files.  I will try to get the right fix in for 3.4.1 but it might be 
hard as I am also trying to clean up the configure stuff and maybe start using libtool and 
automake also for 3.5.0 so the patch which fixes it for 3.5.0 is going to be different than 
the patch to fix 3.4.x unless the general cleanup is accepted for 3.4.x also.
Comment 18 Nicola Pero 2004-03-20 00:40:09 UTC
Subject: Re:  [3.3/3.4/3.5 regression]: GNU libobjc no longer compiled on Darwin

> But anyways the right fix is to have -fgnu-runtime to link against the 
> correct libobjc and
> make sure that it includes the right headers which is semi what the 
> proof of concept patch
> does but only for the include files.  I will try to get the right fix 
> in for 3.4.1 but it might be
> hard as I am also trying to clean up the configure stuff and maybe 
> start using libtool and
> automake also for 3.5.0

I thought that libtool was already used ... is it not ?  I think I 
wrote that libtool code a few years ago.

Is there any advantage in using automake ?  Just asking, it looks like 
more complexity :-)

Comment 19 Carl Eugen Hoyos 2004-03-23 18:48:32 UTC
(In reply to comment #17)
Thank you, Andrew, for your answer.
It's true that it's not easy to use one compiler for both runtimes. (Not
thinking of copyrights, would "merging" of the headers with #ifdef wrappers make
it easier?) But that's not that important anyway: Apple ships (shipped?) its
systems with two compilers (gcc and gcc3), so why not adding a third one? As
long as it's not configured with --prefix=/usr that shouldn't make problems, and
I would never do this on any system! (This prefix definitely screwed up OSX
development environments up to the released version of 3.3.3, does it work with

And since the gnu runtime comes as a static library, the runtime will never be
the problem after adding the symbolic link libobjc.dyld to libobjc.a. It's true
that this didn't work out of the box, but adding a symbolic link is far easier
than fiddling around with the configure scripts! (One often has to add a symblic
link to /usr/local/bin after installation anyway.)

That's why I still can't see why this patch was such a good idea. It did
introduce a regression! Why not having a configuration option
--enable-gnu-runtime (which adds the symbolic link after installation and makes
the gnu-runtime standard for the preprocessor)? The standard on darwin would
then be to configure without this option.

I really hope that the difficult and obviously longlasting (and impossible?)
task to merge the runtimes won't be the reason that compiling for the
gnu-runtime on darwin will be far more difficult in future!

Thanks, Carl Eugen Hoyos
Comment 20 Carl Eugen Hoyos 2004-05-23 21:50:28 UTC
The GNU objc runtime works on darwin for gcc-3.3.3 (tested today). No change in
the configure script is necessary.

Please change the fields Known to work and Known to fail accordingly.

Thank you, Carl Eugen Hoyos, ce AT hoyos DOT ws
Comment 21 Andrew Pinski 2004-05-23 22:31:57 UTC
It works but not truelly works as if you link with -lobjc you get the NeXT libobjc as the Darwin's linker 
searches for dynamic libraries first (and no this is not a bug).
Comment 22 Carl Eugen Hoyos 2004-05-23 23:37:07 UTC
> Darwin's linker 
> searches for dynamic libraries first (and no this is not a bug)

I never said this is a bug, actually you are the only one who ever wrote it
might be a bug (comment 17).

I just think that it's very easy to type
ln -s libobjc.a libobjc.dylib
especially because I usually install a compiler and have to type
ln -s /configuration/prefix/bin/gcc .
to be able to use it (easily).

The point is: It works up to 3.3.3 (and 3.3.4) without fiddling around in
configure, and if you want to use gnustep on darwin, this is the only possibiliy
(and I use gnustep on darwin for distributed objects with other hardware and
operating systems - works well!). I think a multithreaded pure objc application
would be the next example: IIRC, there is no objc_thread_add in the NeXT-runtime.

Of course, everything could be really simple if there would be a configure
switch to choose the default runtime for the preprocessor and the library: If
someone activates the gnu runtime on darwin, than the above link can be made by
the Makefile!

Please correct Known to work and Known to fail, Carl Eugen Hoyos
Comment 23 Lars Sonchocky-Helldorf 2004-05-25 00:50:34 UTC
It would be great if building the GNU objc runtime could make it at least into gcc3.5. According to 
Mark Mitchell in http://gcc.gnu.org/ml/gcc/2004-05/msg01158.html entering stage 2 is planned 
already for JULY 1st. This would make it more difficult to get the libobjc-branch merged back if 
possible at all.

Please understand that this issue is somewhat urgent for Darwin users since the option of using the 
GNU objc runtime was/is one of the main reasons to use the FSF GCC instead of Apples GCC (For 
instance when people wanted to make use of GNUstep or swarm on Darwin they have no other 
choice than to use the GNU objc runtime)

regards, Lars
Comment 24 CVS Commits 2004-05-25 22:39:13 UTC
Subject: Bug 11572

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	pinskia@gcc.gnu.org	2004-05-25 22:39:02

Modified files:
	libobjc        : ChangeLog Makefile.in configure configure.ac 

Log message:
	2004-05-25  Andrew Pinski  <pinskia@physics.uc.edu>
	PR target/11572
	* configure.ac (includedir): Set to "include"
	except for Darwin.
	(libext) Set to empty except for Darwin.
	* configure: Regenerate
	* Makefile.in: s/libobjc.la/libobjc$(libext).la/g.


Comment 25 Andrew Pinski 2004-05-26 12:42:56 UTC
I should note that GNU libobjc is installed as libobjc-gnu and the headers are at include-gnu-runtime, 
The only thing which I have left to figure out is  how to get -lobjc to changed to -lobjc-gnu in the 
driver when -fgnu-runtime is supplied.  I have a patch for the include files already which I will submit 
Comment 26 Andrew Pinski 2004-05-28 21:46:57 UTC
There is no way I can get this done in time for 3.4.1.
Comment 27 Andrew Pinski 2004-06-12 06:03:26 UTC
Created attachment 6523 [details]
Patch which I am submitting for the include

This only does the include part of the problem.  I will fix up the library
problem when I get to California.
Comment 28 Andrew Pinski 2004-06-12 06:14:29 UTC
Oh, here is the changelog (yes I know that there are spellings errors in the changelog but it is late):
* c-incpath.h (target_c_incpath_s): Add extra_pre_includes.
Add two paramaters to extra_includes.
* c-incpath.c (register_include_chains): Call extra_pre_includes before adding the standard include 
Update call to extra_includes.
(!defined TARGET_EXTRA_INCLUDES): Update target_c_incpath.
* fixinclude.c (defined TARGET_EXTRA_INCLUDES): Update target_c_incpath.
* config/darwin.h: (darwin_register_frameworks): Update for the two new paramaters.
(darwin_register_objc_includes): Prototype.
* config/darwin-c.c (darwin_register_objc_includes): New function.
(darwin_register_frameworks): Update for the two new paramaters.
* config/t-darwin (darwin-c.o): Add $(PREPROCESSOR_DEFINES) to the compile line.
* doc/tm.texi (TARGET_EXTRA_INCLUDES): Document the two new parameters.

PS. Yes I know that I need to add to the docs to say that these two macros need to be defined and I 
think I need to add something about target_c_incpath as I see there is no mention of it at all in tm.texi.

PSS. One thing tested on powerpc-apple-darwin and a simple objective-C file which includes objc/
Object.h and use the option -H to print out the headers which are included.
Comment 29 Andrew Pinski 2004-06-13 22:58:09 UTC
I submitted my patch for the include directory here: <http://gcc.gnu.org/ml/gcc-patches/2004-06/
msg00942.html> which is the same patch attached, just the changelog has changed a little.
Comment 30 Andrew Pinski 2004-06-14 05:23:38 UTC
The patch for the linking: <http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00965.html>.  In fact 
now with this patch and previous one for the header files, you should be able to build GNUStep on 
darwin with one modification to the gcc's toplevel configure file without having to make sure that you 
pick up the right headers/library.
Comment 31 Andrew Pinski 2004-06-14 05:31:27 UTC
Patch to reenable libobjc on darwin: <http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00966.html>.
Comment 32 Mark Mitchell 2004-08-29 19:09:43 UTC
Postponed until GCC 3.4.3.
Comment 33 CVS Commits 2004-09-16 06:50:08 UTC
Subject: Bug 11572

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	pinskia@gcc.gnu.org	2004-09-16 06:50:00

Modified files:
	gcc            : ChangeLog c-incpath.c c-incpath.h fix-header.c 
	gcc/config     : darwin-c.c darwin.h t-darwin 
	gcc/doc        : invoke.texi tm.texi 

Log message:
	2004-09-15  Andrew Pinski  <pinskia@physics.uc.edu>
	PR target/11572
	* c-incpath.h (target_c_incpath_s): Add extra_pre_includes.
	Add two parameters to extra_includes.
	(C_INCPATH_INIT): Remove.
	* c-incpath.c (register_include_chains): Call extra_pre_includes
	before adding the standard include directory.
	Update call to extra_includes.
	(!defined TARGET_EXTRA_INCLUDES): Update
	hook_void_charptr_charptr_int and add !define
	(!define TARGET_EXTRA_INCLUDES): Define as
	(!define TARGET_EXTRA_PRE_INCLUDES): Likewise.
	(target_c_incpath): Always declare.
	* fixinclude.c (defined TARGET_EXTRA_INCLUDES): Declare a
	empty function.
	(define TARGET_EXTRA_PRE_INCLUDES): Likewise.
	* config/darwin.h: (darwin_register_frameworks): Update for
	the two new parameters.
	(darwin_register_objc_includes): Add prototype.
	* config/darwin-c.c (darwin_register_objc_includes): New function.
	(darwin_register_frameworks): Update for the two new parameters.
	(target_c_incpath): Remove.
	* config/t-darwin (darwin-c.o): Add $(PREPROCESSOR_DEFINES) to
	the compile line.
	* doc/tm.texi (TARGET_EXTRA_INCLUDES): Document the two new
	* gcc.c (spec_function): Add replace-outfile.
	(replace_outfile_spec_function): New function.
	* config/darwin.h (LINK_SPEC): Add replace
	-lobjc with -lobjc-gnu if -fgnu-runtime is
	* invoke.texi (replace-outfile): Document.


Comment 34 CVS Commits 2004-09-16 06:57:30 UTC
Subject: Bug 11572

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	pinskia@gcc.gnu.org	2004-09-16 06:57:28

Modified files:
	.              : ChangeLog configure configure.in 

Log message:
	2004-09-15  Andrew Pinski  <pinskia@physics.uc.edu>
	PR target/11572
	* configure.in (*-*-darwin*): Renable libobjc.
	* configure: Regenerate.


Comment 35 Andrew Pinski 2004-09-16 06:58:42 UTC
Fixed on the mainline, I will back port the patches when I get home next week.
Comment 36 Lars Sonchocky-Helldorf 2004-09-16 10:51:50 UTC
Well, I am more concerned to see that fix in the apple-ppc-branch than that I care of 3.4. But then 
again that might be out of your scope.
Comment 37 Andrew Pinski 2004-09-24 04:11:27 UTC
The patch was only for 4.0, I have to do the backport for 3.4.x.
Comment 38 Mark Mitchell 2004-10-30 19:33:14 UTC
Postponed until GCC 3.4.4.
Comment 39 Andrew Pinski 2005-04-19 14:53:26 UTC
I am no longer working on this.
Comment 40 Gabriel Dos Reis 2005-10-07 03:10:52 UTC
Fixed in 4.0.x.
WONTFIX for 3.4.x