Problems compiling on NetBSD/m68k

[Godmar Back]

 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
>   ./configure
>   /usr/local/bin/make
> 
>   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,

	- Godmar