[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
MacOS X first results
From: |
Marc-Antoine Parent |
Subject: |
MacOS X first results |
Date: |
Mon, 13 Jan 2003 17:22:31 -0500 |
Hello, folks. I tried to duplicate your results, to see whether I would
get anything different. It seems I have.
Here is what I did:
I am using 10.2.3 with dec dev tools, the X11 from Apple, and Tcl/Tk,
gperf, sed, HDF5 and BLT fresh from fink.
(I allow unstable packages in my setup)
(Bill, I know you don't like Fink, and indeed the autoconf/automake in
fink kills the autogen phase. But that's a minor hindrance for me; I
like the fact that everything else is push-button)
(BTW: I looked at compiling BLT against the Aqua Tcl/Tk... Let's say it
won't be a drop-in.)
I also built the FSF gcc-3.2.1 compiler from scratch, with only a
prefix and --enable-languages=objc to save time (Note in response to a
comment from Bill: C is always included by default) I am using this
only to compile swarm.
Then I build the (fresh from CVS) swarm, as indicated in the
instructions in INSTALL.MacOSX.
As I mentioned, the autogen does not like fink tools; so I take fink
from the path to do the autogen phase. Then I add back fink and the FSF
gcc.
Then I can simply
../../../configure " 'CC=cc -no-cpp-precomp' --prefix=/swarm
--without-jdkdir --with-bltdir=/sw --with-pngdir=/sw --with-hdf5dir=/sw
and make.
I got this interesting comment during make:
*** Warning: This library needs some functionality provided by -lgcc.
*** I have the capability to make that library automatically link in
when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
So I suspect I will have to redo the gcc with --enable-shared and
possibly --enable-version-specific-runtime-libs
Another story... (Note I did reconfig and make with those flags; but
the make was quite short, and did not start from scratch. Just in case
this still changes someone's results.)
make succeeds for me on the libdefobj.a, which Bill reported as a
stopper. (Maybe it's because he solved it in the CVS?)
I suspect using the up-to-date (fink) sed during the build process
helps.
The last link in tools failed strangely, as he said:
cc -no-cpp-precomp -g -O2 -Wall -Wno-import -Wno-protocol -Wno-protocol
-Wno-long-double -o .libs/findImp findImp.o
<...>
-lobjc -lgcc -lBLT.2.4 -ltk8.4 -ltcl8.4 -lXpm -lpng -lhdf5 -lz -lX11
-lm -ldl
complains about a lot of missing things, including all of libobjc calls.
If I add ../libobjc/.libs/libobjc.dylib by hand to the link command,
all that's left undefined is
__i_Object_s__drop
___builtin_avcall
So for me, avcall is missing rather than overdefined.
Again, I may add ../avcall/.libs/libavcall.al by hand to the link
command: All that's missing then is __i_Object_s__drop.
The story of that one is annoying: The __i_Object_s__drop is used
directly in DefObject.m, at line 348:
_i_Object_s__drop (self, M(drop));
but the name mangling scheme changed, and that code is now obsolete.
I think the following may work as a replacement:
void (*dropper)(id, SEL) = (void (*) (id, SEL)) [Object
methodForSelector:@selector(drop)];
dropper(self, M(drop));
(But my grasp on ObjC is shaky, correct me if this is a blunder...)
That solves my problem and I now have a compiled, installed swarm. Will
test soon. ;-)
Thanks to all who have been working on this so far.
Marc-Antoine
==================================
Swarm-Support is for discussion of the technical details of the day
to day usage of Swarm. For list administration needs (esp.
[un]subscribing), please send a message to <address@hidden>
with "help" in the body of the message.
- Re: MacOS X last lap, (continued)
- Re: MacOS X last lap, Perrone Alessandro, 2003/01/04
- Re: MacOS X last lap, Bill Northcott, 2003/01/04
- Re: MacOS X last lap, Bill Northcott, 2003/01/04
- Re: MacOS X last lap, Perrone Alessandro, 2003/01/04
- Re: MacOS X last lap, Bill Northcott, 2003/01/04
- Re: MacOS X last lap, Bill Northcott, 2003/01/04
- Re: MacOS X last lap, Perrone Alessandro, 2003/01/05
- Re: MacOS X last lap, Bill Northcott, 2003/01/05
Re: MacOS X last lap, Paul Johnson, 2003/01/07
Re: MacOS X last lap, Bill Northcott, 2003/01/08