[Top][All Lists]

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

Re: Makefile packages do not work oon OSX due to use of -traditional-cpp

From: Lars Sonchocky-Helldorf
Subject: Re: Makefile packages do not work oon OSX due to use of -traditional-cpp
Date: Tue, 15 Jul 2003 20:03:43 +0200

On 15.07.2003 19:06:51 Enrico Sersale wrote:
>On 2003-07-15 18:56:12 +0300 Lars Sonchocky-Helldorf 
><address@hidden> wrote:
>> ...
>> your  incorrectly set library-combo is visible here:
>> ...
>Can you tell me how to configure gcc 3.3 (fsf) on osx, please. I'm using:
>       --prefix=/usr/local \
>       --enable-languages=c,objc \
>       --enable-threads \
>       --enable-nls \
>       --with-gnu-as \
>       --with-gnu-ld \
>       --without-included-gettext \
>       --with-system-zlib \
>       --enable-version-specific-runtime-libs

well, the last time I've build a gcc it was Apples gcc3 (a gcc3.1 derivate 
at this time) The configuration was rather simple, just:


and then I made it like this:

make CC='cc -no-cpp-precomp' bootstrap

I never tried the FSF gcc (and GNU runtime) so far since I always felt a 
little unsettled concerning compiler builds (I had the feeling that I can 
havoc my system if I do something wrong), but other seem to have succeeded 
with this:


However consider this (and follow ups):


I don't know if this did it make into cvs.

>but, when I try to compile base using it, I get: "gcc: cannot specify -o 
>-c or -S and multiple compilations"
>Anyway, all this stuff comes from the fact that I want to assign the 
>copyryght to the FSF. This because it is an official GNUstep application 
>now it is included in usr-apps.

Go for it!

>And, assigning the copyright to the fsf, I'll have to remove all the .nib 
>that are actually included. (well, I'll distribute them in a separate 

Why so? Is it because those nibs can't contain the GPL copyright notice or 
because they are considered binary files?

>So, I was wondering if it would be better to leave gworkspace using the 
>libs and write an osx back-end.

Interesting idea. But I am not sure if this will work. Won't those 
different NSWorkspaces get in conflict somehow, each not knowing what the 
other does? I think there is a reason for having the method 

+ (NSWorkspace *)sharedWorkspace

to get the singleton(?) instance of NSWorkspace: Avoid multiple 
NSWorkspaces to conflict. On the other hand: you basically would need a 
gnu-gnu-gnu to apple-apple-apple brigde or the like to let the GNUstep-GUI 
NSWorkspace communicate with the Apple-AppKit UI backend. I doubt this is 

>You have tried, for the first time, to build gw on osx; I've worked at 
>too. Actually I've not abandoned the project (and I remember a recent 
your mail 
>in which you expressed the intention of working on this again), but there 
>many problems, first of them beeing the apple implementation of 
NSWorkspace, if 
>you remember. 

I asume you're talking about this stupid

- (BOOL)getInfoForFile:(NSString *)fullPath application:(NSString 
**)appName type:(NSString **)type

bug. Is this silly bug still in Mac OS X 10.2 (I fear so since I read 
"Darwin6" in your compile output so you seem to use Mac OS X 10.2)? Apple 
should fix this since it is documented not like it is but like it should 
be in:


Can you send me your test program to reproduce this bug (So I can file it 
too, making it more important (Yes, I know it was already a duplicate but 
why not exert a little presure...))?

>I've a class (GWLib/OSXCompatibility.[hm]) that owerrides many 
>NSWorkspace methods and implements something like the gnustep 
>tool, but all the stuff has started to begin a little complex and ugly.
>What do you think?

Dunno, maybe wait and see if they fix it in 10.3?


greetings, Lars

reply via email to

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