nmap doesn't like libc++ ?

[Ken Cunningham]

Indeed it's a c++ thing

<http://en.cppreference.com/w/cpp/error/logic_error>

and looking through the nmap build that just completed on my 10.6 system, some, but not all, the c++ build lines have the -stdlib=libc++ on them. So that would be why you see this error, indeed, as Ryan says.

You could do this in the portfile:

configure.cxxflags-append -stdlib=libc++
configure.ldflags-append -stdlib=libc++

and your build should proceed through. Should. Usually works.

If that works, it can be wrapped in a proper guard block and inserted into the portfile for everyone.


====== Technical explanation =========

clang looks for -stdlib=SOMETHING on the build line. 

If none is found, then on < 10.9 it adds -stdlib=libsdtc++, and on 10.9+ it adds -stdlib=libc++. Usually this is the right thing, but in your case, with your modification to libc++ on 10.6, it is not.

So you either have to always make sure -stdlib=libc++ is on the build line 

OR

change the default. 

=====================


I eventually did the latter, so I got this just now:

$ port -v installed nmap
The following ports are currently installed:
  nmap @7.50_0+subversion (active) platform='darwin 10' archs='x86_64' date='2017-07-12T12:12:57-0700'



IF you would like to explore the idea of building clang with an altered default setting, you can look here:

<https://github.com/kencu/SnowLeopardPorts/blob/master/lang/llvm-3.9/files/999-patch-clang-3.9-Toolchains-default-always-libcxx.diff>

The portfile to build / install it is here:

<https://github.com/kencu/SnowLeopardPorts/tree/master/lang/llvm-3.9>

with this variant defaulted    +forcelibcxx

That would at present at least be considered advanced MacPorting, and you'd have to know what you were doing and why, should you decide to try that.

Otherwise you can get fixes into the portfile, such as the one above, and that will usually work.

All the best,


Ken










On 2017-07-12, at 9:43 AM, Ryan Schmidt wrote:

> 
> On Jul 12, 2017, at 11:10, Richard L. Hamilton wrote:
> 
>> After switching my Snow Leopard over to the toolchain that supports C++11 and favors libc++ instead of libstdc++, I could no longer build nmap; it kept getting undefined symbols like std::logic_error::logic_error  (which as used, may be peculiar to libstdc++ instead).
>> 
>> On a hunch, I tried the plain old Apple compiler (configure.compiler=gcc), and it worked.
>> 
>> Not sure what's up with this, because I've never run into it before, either on Snow Leopard or on anything newer (El Capitan, Sierra).
>> 
>> Is nmap doing something that doesn't play equally nicely with both flavors of library, or what?  If so, should the Portfile be more specific about what it needs (compiler or library or whatever), so as to be less dependent on a particular macports.conf configuration or toolchain installation?
>> 
>> Here's what I've got configured:
>> 
>> sh-3.2# egrep 'default_compilers|cxx_stdlib' macports.conf
>> cxx_stdlib         libc++
>> default_compilers  macports-clang-3.9 macports-clang-3.7 macports-clang-3.4 gcc-4.2 apple-gcc-4.2 gcc-4.0
> 
> I don't have a libc++-on-older-systems installation to test on, but the ability to use a nonstandard C++ library depends on the build system respecting the CXXFLAGS MacPorts sets, specifically the `-stdlib=...` flag. Ports that don't use standard configure scripts need to take care of that manually. You may encounter ports that aren't doing that, and need to be fixed to do that.
> 
> Looking at the nmap portfile, it doesn't look like that's the case. It uses a standard configure script, and passes MacPorts CXXFLAGS to the compiler *most* of the time, but not when building in the liblinear subdirectory. If we look at the Makefile in that directory, we see that in the case of the "lib" target, no flags variables are used with the C++ compiler, and in the case of the other C++ targets, the CFLAGS variable is used instead of the CXXFLAGS variable. This looks to me like a bug in the nmap build system which should be reported to the developers. In the mean time, we should be able to patch that.
> 
> 
>