[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: My swarm compile for OSX
|
From: |
Marc-Antoine Parent |
|
Subject: |
Re: My swarm compile for OSX |
|
Date: |
Fri, 17 Jan 2003 08:50:30 -0500 |
Le Vendredi, 17 janv 2003, à 03:29 Canada/Eastern, Bill Northcott a
écrit :
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.
Thank you. As I said, we'll get there ;-)
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.
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.
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? ;-)
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.
My other point about frameworks: Building frameworks is not as easy as
it should be. But that's a minor 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.
True enough.
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!
Yah... Still a fact.
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.
Heh! Someone should build a package manager and package database for
Darwin frameworks ;-)
...
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.
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.
I hear you. Well, I had m4 problems in my other port project (The
Mozart-Oz system, BTW.) They are solved in jaguar, granted, but I can
tell you fink was a godsend.
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.
Yes, I'll have to buckle down someday ;-)
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 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.
No question that Jaguar is a big step forward.
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?
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.
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.
Which list? I'm curious. This does need for us to follow up.
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
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.
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.
Heh. Libraries evolve.... It's a drag to keep up.
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.
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.