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

[Quentin Mathé]

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

Hi...

> Quentin Mathé wrote:
>
> > Hi,
> > 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).

bye,
Quentin.

--
Quentin Mathé
qmathe@club-internet.fr

--
Quentin Mathé
qmathe@club-internet.fr
AIM : clickodrome