[Top][All Lists]

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

Re: [PATCH] Framework support with GNUstep on Mac OS X

From: Quentin Mathé
Subject: Re: [PATCH] Framework support with GNUstep on Mac OS X
Date: Thu, 13 May 2004 15:36:20 +0200

Le 10 mai 04, à 13:08, David Ayers a écrit :


Quentin Mathé wrote:

Here are two patches to have GNUstep frameworks automatically discovered on Mac OS X in every possible cases. Currently the GNUstep frameworks locations are only supported for the apple-apple-apple combo, but it should be supported also for the gnu-gnu-gnu combo which now works on Mac OS X to discard the need to set each time the framework location for an application like GNUMail which uses Addresses framework. I have just removed the combo test case in the scripts because when apple-gnu-gnu and apple-apple-gnu combos will be supported, some frameworks could also be located in a GNUstep related location.

Wow, how did you get gnu-gnu-gnu and apple-apple-apple work in parallel?

First. I'm not sure to understand what you said.
... but what I can said is : I haven't the both library combos gnu-gnu-gnu and apple-apple-apple working in parallel, I just have a GNUstep installation on Mac OS X which uses the gnu-gnu-gnu library combo and the traditionnal Apple supplied build system (aka xCode). When I said "Currently the GNUstep frameworks locations are only supported for the apple-apple-apple combo", I haven't tested it, I just know it because I have read it in the ld_library_path scripts.

Otherwise, I think it should be possible to have two GNUstep installations on a Mac OS X system, one with the library combo gnu-gnu-gnu and configured with FSF GCC, and the other one with the library combo apple-apple-apple and configured with Apple GCC. Probably you have already tried that ? Last word, I think it is not possible to switch library combo on the fly for a GNUstep installation (I mean already compiled and installed), right ?

The -fgnu-runtime/-fnext-runtime flag only controls how gcc generates objc code. Not what headers are included or which libobjc get linked when you supply -lobjc. But if you have this working I'd like to know where your 'libobjc's and 'objc/objc.h's are installed? Which gcc are you using? Apple's or FSF and in which version?

The last time I checked Andrew Pinski was working to add some magic to FSF gcc so that -fgnu-runtime/-fnext-runtime /will/ have an effect on where the compiler/linker/loader would find -lobjc and #include <objc/objc.h>.

If you merely install the FSF gcc with libobjc enabled into /usr/local they you're likely to always include the GNU runtime headers with #include <objc/objc.h> even with -fnext-runtime and link against the gnu runtime with -lobjc.

See the first part of my response.

Anyway, when I proposed the original patch wrt to DYLD_FRAMEWORK_PATH I had a long discussion (which continued offline) with Nicola about adding "true" framework support for Darwin platforms wrt to these search paths. I conceded that we should make this feature Darwin dependent instead of library combo dependent only if/once someone maintains "true" framework support for Darwin and not add a little Darwin dependent support here and a have a little library combo support there.

I know really few things on the framework support.
What must be done to have "true" framework support for Darwin ?
Would it be possible to support frameworks on Linux, or other OS ?

If I understood him correctly, -make only generates "true" Darwin frameworks for the apple-apple-apple library combo anyway. For any gnu-gnu-gnu combo the frameworks are "simulated" for Darwin as for any other platform. Therefore, even if you can get gnu-gnu-gnu to work reliably on OS X, you /should/ be able to link against the library in the "standard" way (i.e. like normal libraries). Yet if the patch worked for you, then either -make actually does create "true" frameworks for gnu-gnu-gnu on Darwin or it just happens to work anyway with the "simulated" frameworks.

Now as I don't have OS X, I only have limited experience with the state of -make's framework support on that platform, I may be missing some important details.

According to Nicola, there is probably a problem with Mac OS X linker which is refusing to link against a normal library when a framework (which packages the same library) is available; I hope he will find a solution for this issue (I'm currently waiting a response from him to my last mail).


Quentin Mathé

Quentin Mathé
AIM : clickodrome

reply via email to

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