Problems compiling on NetBSD/m68k

[Alexandre Oliva]

On Feb 18, 1999, Godmar Back <gback at cs.utah.edu> wrote:

>> 
>> > 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.

No, I'm talking about porting a random package to FreeBSD, in this
case, libtool.  In fact, it was already ported, but it didn't work
because of the ld bug.

> 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.

Multiple -lm flags were not and will never be a problem.  I could
reproduce the bug with a single -lm flag and a ridiculously simple
one-line C program.

> That's something nobody in his right mind would do, no wonder
> FreeBSD's linker freaked out.

That's no excuse for a bug.  Nevertheless, libtool arranged to work
around the bug, that hadn't hit Kaffe before because of luck.

> 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.

Nope.  automake generates makefiles, so you don't have to run it on
every single platform.  Furthermore, it's just a perl script, and perl
is probably the most portable existing language.  (No, I'm not a perl
fan, if you want to know :-)

libtool is supposed to work even on platforms for which it has not
been ported yet, but then it will only create static libraries.
dlopening (emulated by libtool or not) may be limited or inexistent in
this case, but that's a different problem.

> 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.

Did you?  Last time I heard about OSKit, it was working again.

> 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?

Of course.  autoconf's config.guess and config.sub, for example, are
constantly updated for new platforms and releases; for example, it
doesn't support GNU/Linux/arm yet; nevertheless, GNU make and libtool
will build and work on it...

>> > 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 
>> automake.

> This is where we differ.  Let everybody decide for themselves whether 
> that's true or not.

There's no point in trying to decipher the Makefile.in generated by
automake (or the one Kaffe used before) if you can look at a simple
Makefile.am, that just states: I want to build this program or library 
out of these sources.  Is there?

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil