Re: CRT-libs on MSVC

[David Fifield <david () bamsoftware com>]

On Sat, Jan 26, 2013 at 04:54:24PM +0100, Gisle Vanem wrote:
> "David Fifield" <david () bamsoftware com> wrote:
>
> > It looks like it was r8507 in 2008. nmap.vcxproj uses /MD
> > (Multi-threaded DLL) in Release configuration and /MTd (Multi-threaded
> > debug) in Debug configuration. (Right-click the project, Properties,
> > C/C++, Code Generation, Runtime Library.)
>
> Ok. I assumed both release/debug used the same base "model". A
> bit strange to use '/MD' and '/MTd' for release/debug. But as you
> say ..
>
> > In Release mode we do use /MD, I think specifically because of OpenSSL.
>
> I think the reason for this is long forgotten and not an issue
> anymore. According to OpenSSL FAQ on the "applink" + '/MD' issue
> things changed in ver. 0.9.8. Which is some time ago. Also see:
>  http://openssl.6102.n7.nabble.com/applink-c-OPENSSL-Applink-small-C-snippet-td38890.html
>
> > I don't remember what the purpose of applink is, you'll have to search
> > the commit logs.
>
> I've briefly read the applink.c/uplink.c sources in OpenSSL. It's
> just a hack not needed anymore for the conditions nmap requires.
> I.e. since MingW doesn't seems to supported in nmap, is it not safe
> to assume all components
> are built with the compiler (MSVC)?
>
> A short test here w/o applink.c in ncat_ssl.c shows no errors:
>
> shell-1: ncat --ssl --exec="cmd /c dir" -kvl localhost 80
> shell-2: curl -vk  https://localhost:80/
>
> gives correct output.

Is there a reason that the applink is causing you trouble? I'm reluctant
to change anything that is working and was hard to debug in the first
place. If you have a patch and if it simplifies the build process or has
other benefits, we may include it. You have to explain the benefits
though.

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