Packaging NMap 4.0 - Almost there
NMap 4.0 was recently released. Figured I'd check it out. I wanted to package it up for myself with all the "bells-and whistles." So far, I have everything figured out except two things. I'll start by posting the files I am using to package, then get to the issues to see if anyone has an idea how to resolve them. These files should be pretty straight-forward, so...
nmap.SlackBuild This is the main script I use. Nothing amazing, but you will want to note: 1) I add my initials to the build. Feel free to change. 2) I added the configure option "--enable-ipv6". I didn't see this documented, but when compiling I noted there was a check for it. Hopefully, it does what I think it does and enables both ipv4 and ipv6. :) 3) I use $ARCH and $PARCH. Hopefully these make sense. I use them both because I am compiling for athlon-4 (not so good for the package name). I've left other archs in the script, so you can change $ARCH to i686 and $PARCH to $ARCH if you want/need. Ishould probably change $PARCH to be ath4 if $ARCH is athlon-4, else $PARCH=$ARCH , but this works for now. 4) I am using gcc 3.4.5, so I use -mtune instead of -mcpu Feel free to comment on any changes you think shoukd be made. Code:
#!/bin/sh Description taken straight from the spec file in source. Code:
# HOW TO EDIT THIS FILE: There is a .desktop file included for nmapfe. This updates the desktop database so the menu entry will appear correctly. Code:
if [ -x usr/bin/update-desktop-database -a -x usr/bin/chroot ]; then 1 First issue is a small one. I see in docs/README a reference to nmap-manpage.html. This file does not exist in source. I do see a file docs/nmap-man.xml, but it does not packaged when I compile per above. I'm guessing that docs/nmap-man.xml is supposed to be converted to nmap-manpage.html and installed in /usr/doc/nmap-4.00. I'd also guess that this is easy (maybe a simple make command?). Just don't know. 2 Second issue is a little bigger. When compiling, I get the message: Code:
checking linux/netfilter_ipv4/ipchains_core.h usability... no Possibly important, I am running kernel 2.6.15 for this. Also, in the 2.6.15 kernel source, I don't see an ipchains_core.h. Maybe this message is just saying, "Hey, ipchains_core.h isn't used with the kernel you are running"? Note that the program still compiles without error. Haven't bothered to actually install the package, since I am more interested in getting it packaged/built correctly than I am in actually using it. |
ad 2) Check if there is not left contents of 2.4.x kernel-headers package in your system by a chance. Configuration script looks for kernel headers in /usr/include/linux so it may ignore these from source tree.
If this is the reason, build and install own kernel-headers package by tweaking original SlackBuild script or if too complicated for you upgrading to the one from testing/ subdir should be enough. |
I am confused as to what you are suggesting. I have the 2.4 kernel headers package installed. So is what you are sugeesting that I install 2.6 headers, install the package, and revert to the proper 2.4 headers?
I am thinking that since ipchains_core.h is a part of the 2.4 headers (/usr/include/linux/netfilter_ipv4/ipchains_core.h), but is not a part of the 2.6 headers, it is not needed. Installing 2.6 headers may remove the warning, but it would remove the warning because: Code:
checking linux/netfilter_ipv4/ipchains_core.h usability... no Code:
checking linux/netfilter_ipv4/ipchains_core.h usability... no |
The application (Nmap in this case) may compile and run without problems even without my suggestions. But on the other side it's not too wise to confuse some (not so smart written) configuration/compliation scipts by running different kernel version then the installed kernel headers are. F.E. I wouldn't be able to compile my wifi kernel modules with different headers version without a hack.
|
Quote:
My point here is this, changing to 2.6 headers seems to be USELESS in this case. All that it would do is supress a warning, it seems. The warning would be supressed because instead of an un-usable header, I would have a non-existant header. Either way, the header (ipchains_core.h) is not used. Can anyone offer a clear explaination on this? |
All software directly using kernel interface API may have troubles when including different headers version. The header can be in the same place, the types, macros or structures can keep the same name but in definitions they may differ. In the worst case a program may be successfuly compiled but it will run with unexpectable results. In the better and more common case it will just fail to compile - I've experienced some cases when autoconf scipt or Makefile just digs kernel version by `uname -r` and everything else in following compilation conforms to this value. You may imagine what will happen when parts of sources for one kernel version are built with headers included from incompatible version. More smart builds just look for headers in /lib/modules/`uname -r`/source.
|
All times are GMT -5. The time now is 04:08 PM. |