autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: converting netkit to autoconf?


From: Dan Kegel
Subject: Re: converting netkit to autoconf?
Date: Thu, 01 Aug 2002 11:38:43 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020615 Debian/1.0.0-3

David A. Holland wrote on 1 Aug 2002:
>  Dan Kegel wrote on 18 Dec 2001:
 > Currently, netkit
 > (ftp://ftp.uk.linux.org/pub/linux/Networking/netkit/netkit-combo-0.17.tar.gz)
 > uses a configure script (good!) but it's not autoconf-generated.

Correct.

 > This is a problem when cross-compiling; it aborts if you
> specify a cross-compiler, and does a bunch of feature tests > by running compiled code. e.g. netkit-base runs programs to check for > bsd signal semantics and to verify snprintf works.

Yes. These tests are (for the most part) required. If you can suggest
how to check some of these issues without running the test programs,
I'm all ears.

Here's what I ended up doing to cross-compile netkit-base and netkit-telnet:

I untar the netkit source tarball into a separate directory for
each target processor type (bleh!).

I then use my own autoconf system to produce a custom MCONFIG,
then copy that in to the source directory, and run make.
I don't even bother with the configure that comes with netkit.

Oh, and I also nuke the #include <termcap.h> from telnet.c, which
isn't used, and doesn't exist on my platforms.

This works for me presumably because I'm compiling on linux, and
my target is some other Linux.

 > Has anyone converted netkit to use autoconf?

No, and certainly not for this issue: autoconf would not help, as the
problem has nothing to do with the configuration framework.

There are reasons autoconf wasn't used in the first place, too.

Can you give a few of them?  Also, has autoconf progressed now
to a point where it'd be more appropriate than when you first
considered it?

Patches that remove the need for the signal semantics test (by
changing the code to use sigaction(2)) would probably be accepted.

However, I can't think of any way around the snprintf issue. Broken
snprintf implementations are not the problem they were a few years
ago, but they're still around and as people often seem to compile
netkit on strange platforms I'd prefer to keep that test.

I don't think you'd need to avoid that issue.  autoconf can express
every one of the tests you currently do in your hand-generated configure
script.

 > Would the maintainers be interested in a netkit that was
> cross-compile-friendly?
To some extent, but not at the cost of functionality or security
risks.

Of course.  Are you worried about particular functionality or security
problems with autoconf, or are you just expressing a preference for
a good autoconf.in rather than a hacky one?
- Dan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]