Re: Issues on compiling nmap 5.59BETA1 on Solaris

[David Fifield <david () bamsoftware com>]

On Thu, Aug 25, 2011 at 05:48:20PM +0200, Dagobert Michelsen wrote:
> I am currently working on a Solaris compile of nmap 5.59BETA1 and found
> the following issues:

Thank you for taking the time to send these to us and not just keep them
in your OpenCSW repository. That's very helpful.

> * Two python files use inconsistent spacing:
>     zenmapCore/ScriptMetadata.py: inconsistent use of tabs and spaces in indentation
>     zenmapGUI/FileChoosers.py: inconsistent use of tabs and spaces in indentation

I fixed this.

> * ncat/ncat.c needs an inclusion of limits.h for INT_MAX
>   My trivial patch is not portable, a autoconf-check may be better:
>     http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/nmap/trunk/files/0001-Add-definition-for-INT_MAX.patch

I applied this.

> * Solaris needs definitions for CMSG_ALIGN, CMSG_SPACE and CMSG_LEN
>   This patch adds the definitions if any of them is missing:
>     
> http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/nmap/trunk/files/0002-Add-definitions-for-CMSG_ALIGN-CMSG_SPACE-and-CMSG_L.patch

I applied the slightly different patch from
http://wiki.opencsw.org/porting-faq#toc10.

> * The Sun Studio compiler does not honour __attribute__
>   In libpcal a proper check is used and a definition of _U_ is done during configure
>   time to either __attribute__ or nothing if the compiler does not support it.
>   This detection could either be propagated to main configure and according definitions.
>   My non-portable patch disables it for the relevant files with
>     http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/nmap/trunk/files/0003-Do-not-use-__attribute__.patch

How about this, which is already in ncat/ncat.h?

#ifndef __GNUC__
#ifndef __attribute__
#define __attribute__(x)
#endif
#endif

But we already have HAVE___ATTRIBUTE__ in nbase/nbase_config.h. Will
that work instead?

__attribute__((format)) and __attribute__((noreturn)) are fine to
ignore, but there might be bugs with ignoring __attribute__((packed)).
For Windows we use

#ifdef WIN32
#pragma pack(1)
#endif
/* ... struct ... */
#ifdef WIN32
#pragma pack()
#endif

Is there something similar to __attribute__((packed)) for Solaris?

> * The defintion of lt_sockaddr_storage::operator is missing a const or compilation fails.
>   The patch should resolve the issue for all platforms:
>     
> http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/nmap/trunk/files/0004-Make-lt_sockaddr_storage-operator-const-or-compiler-.patch

This had already been fixed in r25296.

> * A similar issue occurs in libnetutil.cc for route_dst which is fixed for all platforms by this patch:
>     
> http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/nmap/trunk/files/0005-Fix-const-definition-of-route_dst-or-c-linkage-fails.patch

-int route_dst(const struct sockaddr_storage *dst, struct route_nfo *rnfo,
+int route_dst(const struct sockaddr_storage *const dst, struct route_nfo *rnfo,

This looks wrong to me, can you share the linker error?

> * The following flags must be set when compiling with the Sun Studio 12 compiler on Solaris 9:
>     CPPFLAGS += -features=extensions -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED=1 -D__EXTENSIONS__
>     CXXFLAGS += -features=extensions -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED=1 -D__EXTENSIONS__ -library=stlport4
>   On build time this additional variable helps building a sane binary (just use VAR_STATIC as
>   it was at the right place, I have not found a usable variable with a better name):
>     VAR_STATIC = -library=stlport4 -norunpath
>   The full mGAR build recipe is available here:
>     http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/nmap/trunk/Makefile

What do these options do? Maybe there was a feature added to Nmap such
that they are now required, when they were not before. Can you make this
into a portable patch, or at least document the conditions that require
them? You can see that we already have some checks for Solaris in
configure.ac, but maybe it would be better to test against the compiler
in this case.

> As you see I had quite some issues building it and would think that this statement is
> an exaggeration:
>   http://nmap.org/book/inst-solaris.html
> I would be glad to offer an account on our solaris packaging projects buildfarm for an
> nmap maintainer to do regular testing or even continuous integration:
>   http://www.opencsw.org/extend-it/signup/to-upstream-maintainers/

Thank you for the very nice offer. As you can tell, Solaris does not get
as much use and testing as other platforms. I hope that we can resolve
the remaining problems from your report and that you will tell us of
build failures that happen in the future.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/