[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Compiling on Darwin

From: David Ayers
Subject: Re: Compiling on Darwin
Date: Mon, 03 Nov 2003 10:29:21 +0100
User-agent: 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]