Re: MacOS X first results

[Bill Northcott]

> 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)

Of course by using Fink you learn nothing.  We need to know which of the 
MacOS X utilities give problems, by using Fink you override many of them.

> (BTW: I looked at compiling BLT against the Aqua Tcl/Tk... Let's say it
> won't be a drop-in.)

Don't waste your time.  You would have to do a lot of work a la Aqua Tk 
and with Apple now backing X11, there is no point.  Tcl/Tk8.4.1 and 
BLT2.4z with the patches works perfectly well.

> 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.

I know it is supposed to be the default, but the documantation says you 
should include it.  Also if it is not included I suspect it builds just 
enough of the C compiler to do the bootstrap and support what ever 
languages you list.  It may not build all the C libraries you need.  I 
simply following the documentation. I find more things work like that.<g>

Also, why build a 3.2.x compiler?  Apple never touched the 3.2 code.  It 
may contain stuff that does not work on MacOS X.  They made it very clear 
that their next compiler after 3.1 would be 3.3 or 3.4.  The current HEAD 
of the Apple cvs is 3.3

> 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

You don't need --with-pngdir.  The project config target will run the 
appropriate script from macosx/swarmx.

> and make.

This is the PB target swarmlibmake.

> 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.

This error is almost certainly because you did not specify c in the list 
of compiler languages.  The compiler did not need the shared library.  So 
it did not build it.  I put c in the list of languages and have never seen 
this error!

> So I suspect I will have to redo the gcc with --enable-shared and
> possibly --enable-version-specific-runtime-libs

Just do --enable-languages=c,objc,c++

> make succeeds for me on the libdefobj.a, which Bill reported as a
> stopper. (Maybe it's because he solved it in the CVS?)

This was a sed problem, which Alex diagnosed.

> 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

I got this far, after I changed the name of libobjc to get it to link.

> 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.

Let's fix the problems not kluge around them.  There seem to be problems 
with the libtool in Swarm on MacOS X.  When I have rebuilt everything 
against Apple's X11, I will try updating it to the current 1.4.3 verson.

> 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...)

Do you use Project Builder?  It really is very helpful.  When you had 
found _i_Object_s__drop (self, M(drop)) in DefObject.m, all you had to was 
select the text, go to 'Find>Batch Find Selected Text' in the menu bar. In 
a few seconds, because all the code is indexed, you would have seen this - 
macro.h:18
#define DROP(obj) _i_Object_s__drop (obj, M(drop)) .

This macro is conditional on #ifdef METHOD_FUNCTIONS.  Clearly l:348 in 
DefObject.m should be
DROP(self);
and probably macros.h l:18 should be deleted and l:26 (#define DROP(obj) 
[obj drop]) should be unconditional.  I will check with the others and fix 
the cvs.

Then the problem is fixed not kluged.

If Paul is reading this, do we get the error on x86 builds with 
METHOD_FUNCTIONS.

> That solves my problem and I now have a compiled, installed swarm. Will
> test soon. ;-)

Well done.

Bll

                  ==================================
   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.