Re: My swarm compile for OSX

[Bill Northcott]

Hi Marc-Antoine

I find your comments most helpful.  They make me think long and hard about 
some of the issues and read more and test more, which is very good.

> I was making the claim about client code.
> A piece of code that used to #include "tk.h" now has to #include
> "Tk/tk.h", provided gcc is told nothing more than -framework Tk as it
> should. (Same if you work within project builder.)
> I did circumvent this in another porting project by explicitly adding
> the Header directory of the framework to the PB search path. YUK. Or
> change all the include directives in all source files to read:
> #if _DARWIN_
> #include "Tk/tk.h"
> #else
> #include "tk.h"
> #endif

Not necessary at all.  Apple encourages you to use the #include "Tk/tk.h" 
form with -F and the framework name at compile time for the good reason 
you mentioned that if helps with name space problems.
However, there is also legacy way of building: leave the source code 
unchanged but put '-I /fullpathtoframeworkheaderdirectory' into the 
compile flags.  This has made your problem back into a build issue not a 
source issue.  Look at tkConfig.sh in the Aqua build.

> cringe whenever I have to deal with frameworks. If frameworks were as
> convenient to use as they are (admittedly) useful, why is not Apple's
> X11 a framework? (To name one...)

I would expect them to make much of it into frameworks if it gets any 
degree of acceptance.  The current release is a quick beta hack which 
concentrated on the Aqua server and the quartz-wm window manager to prove 
out the acceleration advantages.

> Well... I see your point, but the fact is that some of the Darwin
> utilities are problematic/outdated, (sed being a case in point) 

which ones do you have in mind?  In Swarm we only needed to change sed and 
drop in gperf which compiled without modification.  The sed issue was BSD 
vs GNU rather than being out of date.  Older GNU versions worked.

> without fink I see many people build and install those utilities over
> the darwin ones to get the functionality they need, and you have even
> less of a clue of what is there or not! 

The foolish virgins!

> But it's also true that they
> have local/bin to do that, so why /sw... I tell you, I curse when I get
> apps compiled to the prefix /usr/local, as they are even harder to
> disable at will than the fink ones! (as opposed to
> prefix=/usr/local/appName, which is cool.) 

Now you right back into the standard UNIX mess which MacOS X is designed 
to get away from.  I quite agree that /usr/local/appname is the way to go 
on UNIX with maybe a symlink for the default.

> I see your point, I hope you see mine. I certainly enjoy having a handy
> package system, tell you the truth. Helps me focus on the apps I care
> about.

Certainly do when you point at UNIX sillinesses.

> > You would need different CFLAGS: and OBJCFLAGS: -no-cpp-precomp
> > -no-long-double (instead of -no-long-long).  Have a look at the
> > configure.in files in the CVS code.  Your Makefile.common will also be
> > all
> > wrong!  Re-running configure specifying the Apple compiler might
> > rebuild
> > it.

> Makes sense.... Though  -no-cpp-precomp  is only a way to speed things
> up. -no-long-double is worth investigating.

It appears to be synonymous with -no-long-double.  The compiler docs make 
it clear that long-long is not Darwin and long-double is.

> > What errors did you get? (with the Apple compiler)

> gcc crash.

Can you give me more information.  Were there errors before the crash? 
Which program in which app?  It might make a simpler test case for the 
Apple compiler people to find the crash problem.

> Well, the original sed was not doing well either, was it? I got things
> working with this one.

Swarm is the first thing I tried that broke it which was because it uses 
the GNU libtool.  The libtool people know they have a problem, because 
they used a feature unique to GNU sed.  Hence the configurable sed in the 
next version of libtool.  I cannot think of anything else that tries to 
configure sed. So I think this problem is down to the libtool developers 
deciding to use a feature which bsd and other UNIXen had not taken on 
board.

I fully expect that when I have a grovel, I will discover that we need to 
update autoconf to cope with autoconfiguring sed.

> > autogen.sh runs autoconf and automake.  These create configure files
> > from
> > configure.in files and Makefile.in fles from Makefile.am files.  So a
> > change to configure.in potentally changes every Makefle in the 
project.

> That's precisely why I'm usually afraid to touch it!

It is I quite agree worryingly powerful, but I have learned that with this 
GNU stuff, the further up the hierarchy you fix problems, the easier it 
is.  One small tweak to a configure.in and a squillion errors 
automagically vanish.  It really is worth reading the manuals.  I put it 
off for ages and now I regard that as a mistake.  Some GNU stuff is really 
clever.  I have sort come to the conclusion that if the source code is 
well tested and you find yourself fixing it, you are probably going up a 
blind alley.

I wasted a lot of time trying to build Swarm before.  The big breakthrough 
in the last couple of months is that the autoconf/automake stuff is all in 
Jaguar and it understands Darwin/MacOS X.

> > It is particularly important that we get this to work without hacks.
> > The
> > build mechanism in the tools directory seems to be the same as that
> > used
> > for building Swarm applications.  So it affects all users, not just 
the
> > library builders.

> Yes, I suppose that's true; though once the libobjc is in SWARMHOME it
> gets picked up by the application makefiles just fine.

I don't have this clear in my head.  The thing in the tools library is an 
app.  What is it for? Do we need to build it?

> >>> avcall is assembler code, so the problem may be that your FSF gcc is
> >>> using
> >>> the GNU assembler rather than the Apple one.
> >
> >> OK. This is really puzzling. The avcall that works is the one Alex
> >> built using gcc 3.2.1 (If I'm not mistaken.)
> >> Alex, had you built the gnu as, ld tools at the same occasion?
> >> My avcall (using gnu 3.3) fails its own tests; should we report this
> >> to
> >> avcall, gcc or both, you think?
> >> And building avcall with the Apple compiler passes its own tests but
> >> does not work with the rest of the swarm code.
> >> AFAIK, the same assembler is used throughout, no? I mean unless the
> >> gcc
> >> build also builds the assembler at the same time?
> >
> > If you are using Fink, who knows!

> Now, you are being superstitious! No, I do not have as or ld in my
> /sw/bin. There!

Point taken.  I think I was rambling by that stage.  I thought about this 
some more and sent a long rabble to the list about libraries on MacOS X.

> I know that much. Only true of dynamic libraries, of course.

See that latest message.

> I was being rhetorical. Rephrase:
> Even now, no library but libavcall.la contains ___builtin_avcall in any
> shape or form.
> Unless you are saying that otool sees symbols nm does not? It sees
> other things, but not more things, AFAIK.
> Or tell me how to do so, and I will reascertain my previous claim with
> otool.

Rambling again, but thanks to your comments I now think this is a build 
issue.  We need to change the build process so that __builtin_avcall is 
added to libdefobj and also all the dependendent libraries are added into 
libswarm.  We only want one library in the install.  This may be mauch 
easier to with jam (the apple build tool) than make

> Look in blt2.4z/library, you'll find a file called graph.tcl
> It gets put somewhere or other in the install, in my case /sw/lib/blt
> since I use fink.
> That file was named bltGraph.tcl in earlier versions of BLT (when? I do
> not know BLT)
> and Swarm looks for it under that name. 

That is naff on the part of BLT.  Given that BLT has to be fixed anyway 
for MacOS X.  I feel better about adding a symlink in BLT for a moment.  I 
guess that is six of one and half a dozen of the other.  I'll think about 
it more.

> The linker complains about duplication:

> /usr/bin/ld: warning suggest use of -bind_at_load, as lazy binding may
> result in errors or different symbols being used
> symbol _nil_method used from dynamic library
> /usr/local/lib/swarm/libdefobj.dylib(internal.lo) not from earlier
> dynamic library /usr/local/lib/swarm/libobjc.0.dylib(nil_method.lo)

Excellent point.  That looks like a hangover.  Given that Swarm will not 
compile with gcc2.8, it seems to me at first glance that the internal.m 
version should be moved to the runtime.  I will check this with the 
others.

Bill Northcott

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