[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compiling on Darwin
Re: Compiling on Darwin
Mon, 03 Nov 2003 10:29:21 +0100
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
John Davidorff Pell wrote:
I'm now compiling apple's gcc with the patch in the machine-specific
instructions (change #define to #undef), but I am unwilling to trash
my NeXT runtime, how do i install the GNU runtime (and why isn't it
built by default? Even if disabled!?) without clobbering other stuff,
and what does -fgnu-runtime/-fnext-runtime *actually* do?
You could have a look at the following bug report against gcc:
They way I understand the situation is that -fgnu-runtime/-fnext-runtime
are only /indicators/ for the compiler for which runtime to emit code.
It has no control over which runtime the code will actually be linked
against or which runtime the dynamic loader will find at runtime.
It depends on what you mean by "clobbering". If you don't specify any
special prefix when installing libobjc manually, I /believe/ it will be
installed in /usr/local instead of /usr therefore not overwriting the
apple runtime but (most likely) hiding it in the sense that /usr/local
may (or should) be preferred in searches. That could be the case for
linker, loader and the header search for gcc itself. (i.e. which
runtime is meant by #include <objc/objc.h>)
Now there are ways to configure gcc to prefer it's *own* header files
(if libobjc is build together with gcc which isn't possible with all
versions of gcc on Darwin anymore). Some people believe that
-fgnu/runtime/-fnext-runtime should include some more magic for linker
and loader also (well I guess it would only be needed for the Darwin
implementations of them).
Personally I think that trying to obfuscate the complexity of having two
runtimes with the same name on one system is a questionable approach. I
attached a patch to the bug report that would give the gnu runtime a
different name for the linker/loader and rely on the existing gcc header
search mechanics to find it's *own* libobjc (which would be the gnu
version), but the patch hasn't been greeted with a lot of acceptance
:-). I /believe/ the main reason being that there is an expectation for
Apple to solve this by tweaking their linker/loader.
Hopefully that helps you understand the situation a bit better.