Problems compiling on NetBSD/m68k
gback at cs.utah.edu
Wed Feb 17 23:53:16 PST 1999
Alexandre will personally look at your problem and give an answer.
Personally, I pretty much agree that automake is an example for what I would
call a purely self-serving tool, ars gratia artis. But that's just me.
Meanwhile, let me answer what I know:
> Other notes:
> - I am tracking the current version of the sources by doing the following:
> /usr/local/bin/make distclean
> cvs update -d
> I have found in the past that omitting any of these steps exposes one to
> problems. Is the above sufficient?
Since libtool was introduced, I personally do a /bin/rm -rf * in my
build tree (I have a different build tree, i.e., I don't do ./configure
but ../kaffe/configure) But that's probably just my
paranoia and despite the setup that now spits out three times as many
lines of garbage during a build, it still builds in 2-3 minutes on the
machine I'm testing. It takes much longer now on a slower machine, partly
because automake recurses in every directory, and partly because of the
libtool wrapper that invokes gcc, and other things. It's a chore to build
on a P 133, let alone an m68k, so you may want to look into something else.
You could do a "cvs -n update -d" and manually delete all files that
shouldn't be there (Look for question marks ?).
> - I need to use GNU make. The BSD make simply exits with "***Error code 1."
> I thought the point of autoconf/automake/libtool was portability. It's
> not portable if you are forced to use a particular flavor of make.
> (Before automake, the BSD make worked fine.)
The official story is like so: there's a developer version (which is in
CVS) and a "distribution". The latter is created from the former using
some command, (make dist, I think) and does *not* require gmake. The
developer version does.
It sucks, I know. One disadvantage of that scheme is that
if people who are not familiar with automake change a Makefile.in (which are
different in the "distribution" and in the "developer" tree) instead of
changing Makefile.am, we'll possibly have a hard time figuring out what they
did. So people will have to learn automake in addition to autoconf and make
so that they can change Makefile.am.
Let's be frank: make is something that takes a while to learn. Knowing
make is kind of like knowing character pointers. It's like when you TA an
undergraduate CS class and students are like: "Hey, I do char * pointers.
Wanna team up with me?" (Excuse the "like" in this sentence)
Then you learn GNU make, and then you learn autoconf, but you quickly realize
that that's something you rather not know. Who cares about all the AC_
macros and this and that when all you want is to build the damn thing so
that the real work can start.
Of course, you may argue that's needed for portability.
My take on this is that other people will care about other platforms,
they'll build it there, merge in their changes and that's how portability
works in practice and should work in practice.
Now you have to top it off by learning automake *in addition* to make and
autoconf, since automake is for all practical purposes unusable if you
don't understand Makefile.in's and Makefiles.
Simplicity, manageability and maintainability is where the challenge in
software engineering lies these days, IMO.
> - Here is the contents of kaffe/kaffevm/.libs at the time of failure
> (on the Mentor 425):
> > ls -la .libs
> total 1710
> drwxr-xr-x 2 dej 512 Feb 17 23:34 ./
> drwxr-xr-x 10 dej 3072 Feb 17 23:34 ../
> -rwxr-xr-x 1 dej 1728981 Feb 17 23:34 libkaffevm-1.0b3.so.0.0*
> lrwxr-xr-x 1 dej 16 Feb 17 23:34 libkaffevm.la -> ../libkaffevm.la
> -rw-r--r-- 1 dej 569 Feb 17 23:34 libkaffevm.lai
> And on the Pentium:
> > ls -la kaffe/kaffevm/.libs
> total 1791
> drwxr-xr-x 2 dej 512 Feb 18 00:04 ./
> drwxr-xr-x 10 dej 3072 Feb 18 00:04 ../
> -rwxr-xr-x 1 dej 1818607 Feb 18 00:04 libkaffevm-1.0b3.so.0.0*
> lrwxr-xr-x 1 dej 16 Feb 18 00:04 libkaffevm.la -> ../libkaffevm.la
> -rw-r--r-- 1 dej 587 Feb 18 00:04 libkaffevm.lai
> lrwxr-xr-x 1 dej 23 Feb 18 00:04 libkaffevm.so.0.0 -> libkaffevm-1.0b3.so.0.0
I can't really say what's wrong, but here's another tip: the .la files
are ASCII files you can cat.
I don't know what that libkaffevm.lai file is, but every time I'm building
Kaffe I'm about to get stomach cramps when I see with what suffixes
libtool/automake comes up: .la .alx .al .ax .nm .nmT .lai, just to name a few.
Kind of makes you long for the times where all you had to put up with
were .in, .o, .so and .a files.
But I'm sure there's good reasons for all of this. I'm sure Alexandre
can help you more. And that's just my personal gripe anyway. ;-)
Hope that helps,
More information about the kaffe