discuss-gnustep
[Top][All Lists]
Advanced

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

Re: porting to GNUstep from OSX


From: tech
Subject: Re: porting to GNUstep from OSX
Date: Wed, 9 Jul 2003 22:49:50 -0600
User-agent: Mutt/1.5.4i

On Thu, Jul 10, 2003 at 02:15:46AM +0200, Marcus M?ller wrote:
> On Thursday, July 10, 2003, at 12:20 AM, David Bishop wrote:
> >On Wednesday 09 July 2003 03:53 pm, Marcus M?ller wrote:
> >>Hi David,
> >>I recently ported OCUnit to GNUstep. Marco forwarded me your email
> >>regarding incompatibility with gcc 3.3. So far, I have only be able to
> >>test with Apple's gcc 3.3 on Panther - no problems at all. The missing
> >>header forces a warning, but that's not fatal.
> >
> >The build goes fine, the link fails (for me).  I'm thinking the OSX 
> >runtime
> >defines those while GNUstep doesn't.
> 
> That's probably true. I'm not using gcc 3.3 on FreeBSD, yet, so I 
> cannot reproduce these problems currently.

Would an account on my machine help?  I offer ssh access and the pure,
unadultrated power of a 750Mhz Duron...

> >Regarding your port, could I get ahold of it somehow?  I'm more than 
> >willing
> >to test stuff out, and I have access to both Jaguar and GNUstep.  I'm
> >ecstatic that someone else did it already, I have no pride bound up in
> >this...
> 
> Marco released it recently, it's available from Sen:te's website at 
> http://www.sente.ch/software/ocunit/.

Ah, well, that's the version I'm running :-)  I just tried it again on a
different computer (same setup, though: gcc 3.3, gnustep/* 1.6.0/0.8.5)
and got the same result:

 Linking tool otest ...
 
/usr/local/lib/GNUstep/Local/Libraries/ix86/linux-gnu/gnu-gnu-gnu/libSenFoundation.so:
 undefined reference to `class_getClassMethod'

I can't imagine this is actually a gcc 3.3 issue.  I think I mentioned
previously that the various headers didn't ship in 3.2 either.  I dunno,
I'm probably missing something obvious, I wish I had a better
understanding of this whole mess...  Speaking of which, I notice you've
been using *step since '94.  Hold on while I bookmark your email address
to send annoying emails like "What's an id?" and the perinnial favorite
"If GNUstep is compatible with OSX, why can't I run Photoshop on my
x86/Linux box?".

> >>I don't know how the header problem could be solved elegantly besides
> >>using autoconf, but that wouldn't be acceptable on OSX anyways - it
> >>just doesn't fit into the picture using PBX (or Xcode).
> >
> >Not knowing a ton* about the build process of PBX/Xcode, does it allow 
> >for
> >tests at all?  At least in PyObjC you run setup.py, which has some 
> >(very,
> 
> Yes, Sen:te did this for PBX. It doesn't work with Xcode out of the 
> box, though.

I'll worry about Xcode when it ships to us cheap-seats ADC members :-)

> >very, basic) tests to see what version of OSX you are using, and if 
> >you are
> >on GNUstep or not.  Pretty much everything that needs to be done can 
> >be based
> >off of that (at least so far).  Maybe just some #ifndef's, combined 
> >with -D's
> >in the GNUMakefile would be enough? (I.e., #ifndef GNUSTEP #include
> ><objc/runtime.h> #endif)
> 
> PBX/Xcode are not really aware of autoconf and thus autoconf doesn't 
> fit into PBX/Xcode well. But that point is pretty obvious - Apple has 
> its own cross-platform strategy and solutions. In my opinion it 
> wouldn't be wise to force autoconf into the PBX/Xcode build process, 
> but rather provide two different approaches - one for GNUstep, the 
> other for Apple. Of course setup.py is similar to autoconf, so that 
> applies to setup.py as well.

I was kinda just thinking aloud here... I'm pretty sure just some
#ifndefs and -D's in the Makefile (only used in GNUstep, right?) would
do the trick.  See the flurry of other responses B-)  At no point was I
considering using the awfulness of autoconf on my poor little iBook...

> >And last and definetly least, did he forward my message about making 
> >all the
> >headers in ocunit #include-safe?  How useful is that exactly?  I 
> >didn't know
> >if that was something that only the gcc-guys cared about, or if 
> >GNUstep'ers
> >were also anti-import...  (If he didn't forward that message, at
> >http://bishop.dhs.org/~david/senheaders.tgz is a copy of all the ocunit
> >headers, fixed to work without -Wno-imports flag)
> 
> No, I didn't receive this mail. In our major projects (EDC/EDM/XMLRPC) 
> I made sure that all headers are safeguarded and I replaced all 
> occurences of #import with #include with the notable exception of 
> <Foundation/Foundation.h> and <AppKit/AppKit.h>. I sincerely hope that 
> Apple will safeguard these headers soon so we can change them as well.

Well, I have no idea how much "pull" you have with the ocunit guys
(regarding getting them put into their HEAD), but the cleaned up 
versions are there if you want 'em.

As for my two projects, I'll see about trying out all the various
suggestions tomorrow, when I've had enough sleep so that I can actually
make sense, and type coherently.

David




reply via email to

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