Kaffe don't link on HP/UX 10.20

Petter Reinholdtsen pere at cc.uit.no
Sat Aug 15 15:25:18 PDT 1998

[Godmar Back]
> So let me ask a few questions:
> * Who will need to have these tools installed?
>     - Will Kaffe users who compile Kaffe out of the box need them?
>     - Will Kaffe developers who make changes to Kaffe's .c/.h files need?
>     - Will Kaffe developers who make changes to Kaffe's .in files need them?
>     - Will those who'll "need" them also have to "learn" them?

It depens on how much is stored in the CVS repository.  I suggest
requiring all developers to install these tools.  The end users
fetching a distribution will not need automake or libtool.

automake generates Makefile.in from Makefile.am.  If the makefiles are
used to generate libraries, libtool is used to get correct linking.
Both are generated before compiling or collecting the distribution.
> * In general, I believe there is virtue in assuming as little as
>   possible about what users or developers have available to them.
>   Look at the gcc dependencies we already have; look at how fragile
>   the Makefiles are.  Trailing slashes, include directives, are you
>   using gmake, FreeBSD make, Sun make, Solaris make?  What is
>   happening when it says "don't know how to make XXX", etc.  Don't
>   get me wrong: none of these are insurmountable problems, but they
>   all require time and consideration.  I feel we shouldn't invite
>   them unless we have to.

My feeling is that automake removes most of these problems.

> * What will the benefit of libtool be?  To find the proper
>   link-order and switches for a given architecture?  How often will
>   those change?

The question is rather: would you like to ignore the problem.  libtool
takes on the responsibility of making shared libraries.  If libtool
support the platform, shared libraries are supported for your

> * How intuitive are these tools?  Rank them against autoconf (a tool
>   I personally find extremely unintuitive.)  I assume automake
>   generates Makefiles, or Makefile.ins?  How readable and debuggable
>   are those?  Will we be spending our time debugging problems in the
>   various input specifications used by those tools?

Automake is very intuitive.  Look at this example Makefile.am to make
a small shared library:

  INCLUDES +=             -I$(top_srcdir)/config
  INCLUDES +=             -I$(top_srcdir)/include
  INCLUDES +=             -I./intrp
  INCLUDES +=             -I./jit

  lib_LTLIBRARIES=        libkaffevm.la

  libkaffevm_la_SOURCES=  baseClasses.c \
                          classMethod.c \
                          thread.c \

This is the complete kaffe/kaffevm/Makefile.am (except the list of
sourcefiles).  Compare that to the monster Makefile.in's you maintain
today. :-)

libtool is handled by automake, and I have no idea if it is intuitive
or not.

> * How big is the version dependency of these tools?  The background
>   of this question is: will all developers have to always have the
>   latest version of the tool installed on their machine?  Take CVS
>   as an example: it is amazing how many features change between such
>   versions as 1.5, 1.8, 1.9.10, or 1.9.26.  (Tim wasn't able to find
>   out how to set CVS-readonly access to his CVS server in the
>   version he originally had, even with the help of people who gave
>   him detailed instructions.  Upgrading his server fixed this.)

I don't know.  libtool is v1.2 and automake is 1.3.  I assume they
will stabilize.  As of now, all developers will need the latest
version +- release.  The changes up til now has been new macros,
meaning they are not forward compatible.

The only current problem with libtool that I'm aware of is that it
don't handle inter-library dependecies very well.  The workaround is
to spesify these dependencies manually (i.e. make sure to link with
all needed libraries).
##>  Petter Reinholdtsen <##    | pere at td.org.uit.no
 O-  <SCRIPT Language="Javascript">window.close()</SCRIPT>
http://www.hungry.com/~pere/    | Go Mozilla, go! Go!

More information about the kaffe mailing list