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
