This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Your patch: don't configure libobjc on Darwin


> > Sorry for not writing any sooner, but since I don't read
> > gcc-patches often, I didn't see your mail and patch earlier.
> > 
> > It's absolutely wrong that the gnu-objc-runtime isn't working properly on OSX!
> > 
> > I'm using it to compile (and run) gnustep-base library to do DO messaging
> > with linux, solaris, irix and windows machines. I have two compilers
> > (actually more) on my system, (Apples) /usr/bin/gcc and gnu
> > /usr/local/bin/gcc, both work, and both have their objc-runtime (one
> > statically, one dynamically linked - so what?).
> > 
> > The gnu runtime runs absolutely nice:
> > You just have to link ln -s libobjc.a libobjc.dylib to
> > force the linker to use the statically linked gnu objc runtime lib.
> > 
> > PLEASE revert your patch, it doesn't make anything easier, but only
> > destroys a working feature!
> 
> Are you sure it really works?  You aren't passing any special flags to
> the compiler (like, say -fgnu-runtime)?

<fuming with rage after seeing one of our GNUstep users seriously (and
rightfully so) angry>

He might be using -fgnu-runtime.  So what ?  The whole purpose of
-fgnu-runtime and -fnext-runtime is to change the compiler behaviour *at
runtime* (as opposed to configure time) between the two runtimes!

It seems to me that you have applied a radical patch causing a major
regression (since the GNU Objective-C runtime was available on Darwin in
all previous releases of GCC, and is no longer available now) just because
you don't want to spend twenty minutes figuring out how to install both
runtimes together on darwin and switch safely between the two.  I'm afraid
you'll have to fix your laziness, or revert your damaging patch.

For your information, this is the FSF GNU Compiler, and it is supposed to
install the FSF GNU Objective-C runtime.  I can concede you to make the
native non-free Objective-C runtime the default (even that's debatable,
since the FSF GNU Compiler should encourage usage of free software as a
replacement of non-free software), but I *can't* definitely let you get
away with not even installing the free GNU alternative for users who
want/need to use it.  Also given it was installed before, and I don't
believe you don't have the technical expertise required to figure out a
way to install the two of them and switch safely.

 
> I think that by default, the compiler should work.  You should not
> need to pass special flags to the compiler just to make it work on
> some system.

He was using the GNU runtime in the previous release, and it was working
perfectly well.  He must be able to do the same in the next release.


> Have you tried building gnustep-base under the NEXT runtime?

<fuming with rage even more at this insulting question>

Are you trying to force a GNU user who's been happily using the free GNU
Objective-C runtime to switch to use the non-free NEXT runtime, after
making him unable to use the free GNU runtime by applying a patch which
drops the free GNU Objective-C runtime from the official FSF GNU GCC
itself ?

<after taking a small stroll in the office and calming down>

For your information, nobody has been able to use gnustep-base under the
NEXT runtime yet - it seems it's not a trivial task: at the moment the
NEXT runtime (non-free software btw) can only be used with the Apple
FoundationKit (proprietary software).  Which is not too surprising, given
that this is exactly how it is supposed to be used.  It would be nice to
finish the port of gnustep-base though.

Technically, it would be interesting to perform remote messaging between
machines using gnustep-base running on top of two different runtimes :-)  
but what he is asking you is simply to be able to do what he was doing
with previous releases of GCC: install GCC and the GNU Objective-C runtime
(and gnustep-base on top of that) on Apple, to use it to integrate an
Apple machine in a gnustep-base distributed objects network.  Frankly, it
sounds very reasonable.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]