Problems compiling on NetBSD/m68k
gback at cs.utah.edu
Thu Feb 18 10:20:53 PST 1999
> > My take on this is that other people will care about other platforms,
> Easy to say that when it's been ported to the platform you work on.
> But who was the guy whining when libtool failed to work on FreeBSD
> because of a bug in FreeBSD's linker? Well, it was easy to work
> around this problem, but think of yourself trying to port a package as
> complex as Kaffe to some platform if it had not been developed with
> portability in mind.
You're turning things upside-down: FreeBSD worked before libtool, and
failed after libtool was introduced. The reason was that libtool decided
that all libraries would depend on -lm, so it would throw dozens of
gratuitous -lm switches in the link lines it created. That's something
nobody in his right mind would do, no wonder FreeBSD's linker freaked out.
But on a more serious note, this points to another reason why
libtool/automake actually reduces portability. libtool/automake work
only if the set of platforms/architectures on which it is supported is
a superset of the platforms/architectures on which Kaffe compiles and
builds. Now I don't want to make a statement about whether that's true
in general or not, but so far we've lost the capability to compile
Kaffe on the OSKit. Sure, that may be temporary, but it requires
resources to fix I'd rather spend on Kaffe. What about the Amiga?
Is there a port for automake 1.4?
More importantly, all the platforms have to follow the libtool/automake
development cycle. Kaffe uses features only available in versions of
automake as recent as Jan 1999; this means that all platforms will require
that someone takes the time and effort to port and upgrade automake/libtool
for them. For all practical purposes, that means you need people who care
about libtool/automake so much that they port it to their platform. This
may be true for you, but a lot of people would rather spend their time
porting Kaffe to their platform.
But that's not all. People developing OS and libraries are also constrained
in what they are doing. For instance, FreeBSD 4.0 broke libtool temporarily,
not because of new developments in libtool, but because of changes the
FreeBSD developers did to their system. Would such incompatible changes
have happened to make or even autoconf?
> > autoconf, since automake is for all practical purposes unusable if you
> > don't understand Makefile.in's and Makefiles.
> You don't even have to look at Makefile.ins and Makefiles when you use
This is where we differ. Let everybody decide for themselves whether
that's true or not.
More information about the kaffe