Re: My swarm compile for OSX

[Bill Northcott]

> > source issue.  Look at tkConfig.sh in the Aqua build.

> I agree that is possible, but the -I
> /fullpathtoframeworkheaderdirectory' forces us to have the framework in
> a fixed location (i.e. usually /Library/Frameworks) when according to
> the design, it could in theory be in ~/Library/Frameworks or (shudder)
> /System/Library/Frameworks. I feel using -I, -L flags defeats the
> frameworks purpose. A hack again, though a minor one.

It only has fixed path at the compile time of the old style library into a 
framework.  If you are writing new code to use the library you can use the 
Apple conventions.  Basically if you want to use legacy UNIX style 
includes you have to use a legacy UNIX style build for that bit of code, 
but not for its subsquent use.  It strikes me there may be some issues 
with includes in headers?

> Also, I once used such a path in ProjectBuilder; as it wants to resolve
> symlinks, my -I/Library/Frameworks/Tk.framework/Headers became
> -I/Library/Frameworks/Tk.framework/Versions/8.4/Headers! Now that
> defeats the purpose even more... Really, I feel -F should do the work
> for us without changing clients. Hey, care to start a petition on this
> with me? ;-)

I am not sold yet.  There was some powerful reason for doing it the way 
they did, until I understand that, I would rather keep quiet.

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

> Heh! Someone should build a package manager and package database for
> Darwin frameworks ;-)

I think the GNU-Darwin project did this.

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

> OK. Will try to remember where this happened and come back.

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

> Ah, but configure.in is source code too, is it not?
> (Just kidding. I agree in general)

I am making a distinction between files which contain code in C, 
ObjectiveC etc which are compiled and end up as object code in the 
libraries and executables on the one hand, and build system files, which 
are mostly part of autoconf and automake and libtool and which orchestrate 
the build but leave no trace in the finished product.

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

> I am not sure what it's used for. It seems to look for a selector in a
> class, and report where it's implemented.
> I suspect that the relevant distinction is that it's built before the
> install. After the install, apps are built OK. Or maybe it just uses a
> different makefile than the apps. Either way, the problems we have with
> it do not affect the apps.

I'll keep mulling it over.

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

> I heartily agree

This is definitely right.  I had a look at the Tru64 build I did awhile 
back and there is __builtin_avcall in libdefobj.a.

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

> Is this necessary? There may be a reason why these libraries are
> separate. It is clear to me that they are not all always needed, and so
> not rolling them in allows for smaller memory footprint at runtime for
> some applications.

Should make no difference on the Mac with its late binding.  It would 
clearly be an issue with static builds.

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

> I agree. The internal version is more interesting than the other one,
> but not everybody will want their app to be spouting debug messages!
> There should be a #if debug flag or something...

> I am enjoying the discussion in general at this point; we are looking
> at options and that is good.

I have to call off for a few days because I have some teching next week.

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.