Use the --help option to configure to get the
latest list.
Linking gives loads of errors such as
pnpdump.o: In function `dumpdata':
pnpdump.o(.text+0x11b0): undefined reference to `__outbc'
pnpdump.o(.text+0x11c4): undefined reference to `__outb'
pnpdump.o(.text+0x11db): undefined reference to `__outbc'
pnpdump.o(.text+0x11ef): undefined reference to `__outb'
pnpdump.o(.text+0x1374): undefined reference to `__outbc'
pnpdump.o(.text+0x1388): undefined reference to `__outb'
Chances are the -O2 compiler option is missing.
Your make program is not recent enough. I've seen make 3.74 do this.
Type
make -v
to find out what version you have. Make 3.76.1 seems ok.
If you get messages such as:
bash: ./sbin/pnpdump: No such file or directory
or
bash: ./isapnp: No such file or directory.
when attempting to run the precompiled binaries, then chances are you haven't got the required C libraries.
To check this, change to the sbin directory and type
ldd pnpdump
ldd isapnp
You should get something like
libc.so.5 => /lib/libc.so.5
for each one. If you get "not found" then you will have to
recompile. Note that the precompiled binaries in my binary distributions
are compiled for libc5. If you want binaries for glibc systems,
Redhat 5.2 on, Suse 6.0 on etc, you'll have to go elsewhere (probably
to your distribution's web site).
The best thing to do is to delete the binaries in the distribution and try to compile your own anyway.
If you get a complaint along the lines of cannot find DPMI, then you need to get hold of a DPMI host software. See the FAQ on the DJGPP site for details (follow the path through Running --- Distributing). This is most likely to occur on a pure DOS machine. Win95 for example includes a DPMI host.
The free DPMI server (cwsdpmi) is normally part of the djgpp distribution. For example, my ISP mirrors it in the ftp://ftp.demon.co.uk/pub/mirrors/coast/vendors/djgpp/v2misc/ and ftp://ftp.demon.co.uk/pub/mirrors/simtelnet/gnu/djgpp/v2misc/ directories.
You need to edit the makefile so that -DNEEDSNPRINTF is included in PNPFLAGS.
In isapnptools-1.23 on, using configure, this #define has been changed to HAVE_SNPRINTF and has the opposite sense. The configure script should detect the setting automatically when cross compiling.
You need to set the GNUTARGET environment variable then rebuild:
export GNUTARGET=coff-i386
make clean
make CC=gcc-dos
See also How can I make a non-native binary ?.
The latest kernels (2.1.7x ish) have problems with the header files.
If you are playing with these kernels, you really ought to know how
to fix this yourself. I've been told that adding a -D__KERNEL__
to the Makefile fixes it.
If you've change from libc5 to glibc, or want to use EGCS, you could look at http://huizen.dds.nl/~frodol/glibc/problems.html for some help.
See also the The program crashes with a "Segmentation fault" section.
There have been reported some problems getting isapnptools 1.18 to compile with kernel 2.2.11. I quote Juergen Rose:
I still played a little bit with your and with the linux sources. If I
change in pnpdump.c and isapnp.y the order of
# include <linux/sched.h>
# include <sys/time.h>
to
# include <sys/time.h>
# include <linux/sched.h>
isapnptools-1.18 compiles, but with warnings. The warnings are due to the
facts, that:
- /usr/include/asm/processor.h is included in /usr/include/linux/sched.h
at line 74 and needs "struct task_struct"
- "struct task_struct" is defined in /usr/include/linux/sched.h at line
218
So I moved the line in /usr/include/linux/sched.h
#include /usr/include/asm/processor.h
below the definition of "struct task_struct". And could compile
isapnptools-1.18 even without warnings.
No, or at least not easily. Issues that require addressing include
Check the web site to see if the bug has already been reported.
Check the FAQ to see if the problem is operator error.
Check all the READMEs and INSTALL file to see if the answer is there.
If the program doesn't seem to obey the documentation, please look at the source to identify the cause of the discrepancy, and report the problem.
If nothing shows in the above, please report the problem, including the following information as appropriate:
prog args.. > prog.stdout 2> prog.stderr
Note that if you provide a useful contribution to isapnptools as a result of you report, you will automatically get added to the announcements mailing list (see Is there a mailing list for isapnptools ?), unless you request otherwise. Also your name may get added to the README list of credits.
A statically linked binary should work on many different linux systems with the same processor type. This is because all the standard library functions required have been extracted and included in the binary executable. The disadvantage is that the binaries are a lot bigger.
Add the -static flag to LDFLAGS in the makefile. This could be done for instance by adding the following line to the Makefile:
LDFLAGS += -static
or my setting it when running make:
make LDFLAGS+="-static"
Isapnptools-1.23 and later use autoconf for configuring the programs for building. This makes it very easy to build programs for machines other than the one you are building on.
For example, on my machine I have got a djgpp cross-compiler set up so that I can make DOS executables. In this case, I use the following commands:
CC="gcc -b i386-go32-msdos" configure --disable-realtime --disable-proc --disable-pci
make GNUTARGET=coff-i386
I also have an old machine which still runs a.out binaries. In that case I use:
CC="gcc -b i486-linuxaout" configure --disable-pci --prefix=/
make