nmap fails to compile, missing "#include <sys/types.h>"

[aseering@…]

I'm running Mac OS X 10.4.11. When compiling, I get the following error:

:info:build make[1]: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_net_nmap/nmap/work
/nmap-6.25/liblua'
(...)
:info:build /usr/bin/gcc-4.0 -O2 -Wall  -no-cpp-precomp -pipe -O2 -arch ppc -Wall -fno-strict-aliasing   -DLUA_USE_MACOSX   -c -o liolib.o liolib.c
:info:build liolib.c: In function <E2><80><98>f_seek<E2><80><99>:
:info:build liolib.c:543: error: <E2><80><98>off_t<E2><80><99> undeclared (first use in this function)
:info:build liolib.c:543: error: (Each undeclared identifier is reported only once
:info:build liolib.c:543: error: for each function it appears in.)
:info:build liolib.c:543: error: parse error before <E2><80><98>offset<E2><80><99>
:info:build liolib.c:544: error: <E2><80><98>offset<E2><80><99> undeclared (first use in this function)
:info:build make[1]: *** [liolib.o] Error 1

(Full main.log is attached.)

If I add

#include <sys/types.h>

to the top of liolib.c, the build succeeds.

I realize that OS X 10.4 is probably not your top priority... But this feels to me like a change for the better; this file does use stuff in sys/types.h, so #include'ing it doesn't strike me as unreasonable. Would you consider patching the port accordingly?

[aseering@…]

main.log from a failed build, illustrating the error

[danielluke (Daniel J. Luke)]

I don't have a 10.4 system to test on, but one thing you might want to do is report this upstream.

If you do, please note it here (including whatever fix that ends up being merged upstream). If you can attach a patchfile with your change and a portfile diff (which applies the patch only on 10.4), I'm likely to get to updating the port sooner than if I have to generate it myself (and try to test it somehow).

[mf2k (Frank Schima)]

In the future, please fill in the Port field and Cc the port maintainer(s).

[geoffd2]

Replying to dluke@…:

I don't have a 10.4 system to test on, but one thing you might want to do is report this upstream.

If you do, please note it here (including whatever fix that ends up being merged upstream). If you can attach a patchfile with your change and a portfile diff (which applies the patch only on 10.4), I'm likely to get to updating the port sooner than if I have to generate it myself (and try to test it somehow).

I just came across this same bug. Type off_t is apparently not native to apple_gcc 4.2, but the code assumes it is. Changing

89  #if defined(LUA_USE_POSIX)      /* { */
    90
    91  #define l_fseek(f,o,w)          fseeko(f,o,w)
    92  #define l_ftell(f)              ftello(f)
    93  #define l_seeknum               off_t

in liolib.c to

89  #if defined(LUA_USE_POSIX)      /* { */
    90
    91  #define l_fseek(f,o,w)          fseeko(f,o,w)
    92  #define l_ftell(f)              ftello(f)
    93  #define l_seeknum               __darwin_off_t

works - that's the definition in /usr/include/sys/types.h - but that's not elegant nor 10.4 specific. I suppose you should check whether 'off_t' is declared at the top of the file (how? does ifndef work for types?) and if not, include sys/types.h . Where is this 'upstream' I should be reporting this to? I doubt I'll be able to write a Portfile, but I'm open to testing.

[danielluke (Daniel J. Luke)]

Upstream == the nmap developers.

I'm going to close this as wontfix for now (since 10.4 is /old/ and no one should be running it) - but I'm willing to include a build fix if you can get it fixed upstream.