Nmap Development mailing list archives

Libtool, static libraries, and NSE modules


From: David Fifield <david () bamsoftware com>
Date: Thu, 18 Oct 2007 19:46:14 -0600

I tried sending this message earlier, but it didn't post, perhaps
because a large patch was attached. Here it is again without the patch.

I've been working on fixing the build issue reported by Vijay on
OpenBSD. It looks like this:

  Compiling nse-standard-library
  gmake[1]: Entering directory `/home/vsankar/Downloads/nmap-4.22SOC7/nselib'
  ./libtool --tag=CC --silent --mode=compile 
  gcc -I../libpcre -I../liblua/ -Iliblua -I/usr/local/include -Ilibpcre -g -O2 -Wall  -fno-strict-aliasing 
-I/usr/include -I/usr/include -Inbase -Insock/include   -DHAVE_CONFIG_H -DNMAP_NAME=\"Nmap\" 
-DNMAP_URL=\"http://insecure.org\"; -DNMAP_PLATFORM=\"i386-unknown-openbsd4.1\" -DNMAPDATADIR=\"/usr/local/share/nmap\" 
-DNMAPLIBEXECDIR=\"/usr/local/libexec/nmap\" -c pcre.c
  ./libtool --tag=CC --silent --mode=link gcc -L../libpcre -lpcre -avoid-version -module -rpath /usr/local/lib -o 
pcre.la pcre.lo
  
  *** Warning: linker path does not have real file for library -lpcre.
  *** I have the capability to make that library automatically link in when
  *** you link to this library.  But I can only do this if you have a
  *** shared version of the library, which you do not appear to have
  *** because I did check the linker path looking for a file starting
  *** with libpcre and none of the candidates passed a file format test
  *** using a regex pattern. Last file 
  checked: /home/vsankar/Downloads/nmap-4.22SOC7/libpcre/libpcre.vcproj
  
  *** Warning: libtool could not satisfy all declared inter-library
  *** dependencies of module pcre.  Therefore, libtool will create
  *** a static module, that should work as long as the dlopening
  *** application is linked with the -dlopen flag.
  mv .libs/pcre.so pcre.so
  mv: .libs/pcre.so: No such file or directory
  gmake[1]: *** [pcre.so] Error 1
  gmake[1]: Leaving directory `/home/vsankar/Downloads/nmap-4.22SOC7/nselib'
  gmake: *** [nsestdlib] Error 2

This is caused because Libtool doesn't think it's safe to link a static
library (libpcre/libpcre.a) with a shared module (nselib/pcre.so).
Apparently this behavior isn't portable ("we can't support linking
archives into shared libs because it isn't portable"):
  http://osdir.com/ml/gnu.libtool.general/2003-02/msg00150.html
But apparently it works on some systems such as GNU/Linux, which is why
I haven't seen the error before.

Does anyone know Libtool well enough to suggest an obvious solution?
Here's what I've tried so far.

Linking directly with libpcre.a (instead of using -lpcre), like this:
  ./libtool --tag=CC --silent --mode=link gcc ../libpcre/libpcre.a -avoid-version -module -rpath /usr/local/lib -o 
pcre.la pcre.lo
works on OpenBSD, with this warning:
  *** Warning: Trying to link with static lib archive ../libpcre/libpcre.a.
  *** I have the capability to make that library automatically link in when
  *** you link to this library.  But I can only do this if you have a
  *** shared version of the library, which you do not appear to have
  *** because the file extensions .a of this argument makes me believe
  *** that it is just a static archive that I should not used here.
and works on Linux, with this warning:
  *** Warning: Linking the shared library pcre.la against the
  *** static library ../libpcre/libpcre.a is not portable!
So that seems to work, despite the ugly warnings.

Another option is to use Libtool to build libpcre. When Libtool builds
the static library itself, it considers it safe to link it against
shared libraries. Libtool is used in the main PCRE distribution, but
that has been stripped out of Nmap's version. Changing this to use
LIbtool, pcre.so builds without warning on OpenBSD and Linux. But then,
linking nmap fails because libpcre.a is in libcpre/.libs/ instead of
libcpre/. Also, libpcre/NMAP_MODIFICATIONS suggests that Libtool was
causing problems on Mac OS X, which I'm unable to test.

The NSE modules pcre.so is used by only one script: ircServerInfo.nse.
We could disable pcre.so and and that script for the time being until
this is figured out.

The NSE pcre stuff used to be linked in statically in a file called
nse_pcrelib.cc. This was changed to a shared module in r5485. Reverting
r5485 seems to work on OpenBSD and Linux. I've attached a patch
(nse_pcrelib.diff) that does this.

So here's what I'm recommending: Revert r5485 for now, and get input
from some nselib developers on what should be done to handle this
situation in general. It looks like as long as we're using Libtool to
build NSE modules, all the libraries they depend on have to use Libtool
also.

David Fifield

Attachment: nse_pcrelib.diff
Description:


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

Current thread: