Re: Error building nmap on amd64

[David Fifield <david () bamsoftware com>]

On Tue, Aug 26, 2008 at 07:21:23AM +0200, Sven Klemm wrote:
> | After thinking about this some more and discussing it with Fyodor, I
> | have this proposal: remove support for shared modules from NSE.
> |
> | Currently there is only one shared module, bit.so, and it's tiny. We
> | used to have another one, pcre.so, but it was changed to be linked
> | statically into the nmap executable when we ran into a similar problem
> | last year:
>
> I have two more modules in my branches. And there are probably more to
> come. Whenever you need a feature in NSE that a C library provides you
> can just write a wrapper and use the functionality without recompiling
> nmap.

How hard is it to create a shared NSE module versus a static module?
I've never done it so I don't know. The hash and binlib modules added
this summer were made into static modules, so I assumed it was easier.

> | This change change would remove support for shared NSE modules and
> | change bit into a statically linked module like bin, hash, and pcre.
> | This is a moderately substantial change so please speak up if you have a
> | reason why shared modules should be retained.
>
> But this will stop common lua modules from working with NSE and it
> will increase the effort needed to write lua bindings for NSE.

You're right, stopping other common Lua modules from working is
undesirable. NSE would still have the ability to load shared Lua
modules, but it wouldn't provide any itself. In any case the shared
modules wouldn't work with a static build of Nmap.

David Fifield

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