#58837 closed defect (wontfix)
nmap compilation fails
Reported by: | lemzwerg (Werner Lemberg) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | lion | Cc: | kencu (Ken) |
Port: | nmap |
Description
[macOS 10.7.5 11G63]
[Xcode 4.6.3 4H1503]
[macports-ports commit f939548d4]
[cxx_stdlib libc++]
Compilation/linking of nmap fails on my Mac with undefined symbols, see attached log file.
Attachments (1)
Change History (11)
Changed 5 years ago by lemzwerg (Werner Lemberg)
Attachment: | nmap.main.log.xz added |
---|
comment:1 Changed 5 years ago by danielluke (Daniel J. Luke)
Resolution: | → wontfix |
---|---|
Status: | new → closed |
I don't have a 10.7 system to test on, and am no inclined to spend time trying to make builds work on OS releases that are no longer receiving security patches from the OS vendor.
Having said that, I'm happy to review and include any patches to the port that you can generate to fix the build on your system. Feel free to re-open this ticket with a patch (or open a Pull Request).
comment:2 Changed 5 years ago by kencu (Ken)
Cc: | kencu added |
---|
comment:3 Changed 5 years ago by kencu (Ken)
Here is the issue:
:info:build /usr/bin/clang++ -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 -L/opt/local/lib -Lnbase -Lnsock/src/ -o nmap charpool.o FingerPrintResults.o FPEngine.o FPModel.o idle_scan.o MACLookup.o nmap_dns.o nmap_error.o nmap.o nmap_ftp.o NmapOps.o NmapOutputTable.o nmap_tty.o osscan2.o osscan.o output.o payload.o portlist.o portreasons.o protocols.o scan_engine.o scan_engine_connect.o scan_engine_raw.o scan_lists.o service_scan.o services.o NewTargets.o TargetGroup.o Target.o targets.o tcpip.o timing.o traceroute.o utils.o xml.o nse_main.o nse_utility.o nse_nsock.o nse_dnet.o nse_fs.o nse_nmaplib.o nse_debug.o nse_pcrelib.o nse_lpeg.o nse_openssl.o nse_ssl_cert.o nse_libssh2.o nse_zlib.o main.o -lnsock -lnbase -lpcre -lpcap libssh2/lib/libssh2.a -lssl -lcrypto -lz libnetutil/libnetutil.a ./libdnet-stripped/src/.libs/libdnet.a ./liblua/liblua.a ./liblinear/liblinear.a -lm :info:build Undefined symbols for architecture x86_64: :info:build "std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::find_first_of(char const*, unsigned long, unsigned long) const", referenced from: :info:build __ZL15filename_to_urlPKc in NmapOps.o
when nmap
builds and links, it does not specify a stdlib
setting on the build line. By default, clang
on systems < 10.9 examines the build and link lines for a -stdlib
setting, and if none is found, clang
defaults to adding -stdlib=libstdc++
. That causes the build to fail because it does not find all the proper symbols that it is looking for, as noted by the std::__1:*
errors.
The proper fix is to force the stdlib
onto the build and link lines. However, this is a bit of a PITA.
Another fix is to make clang
default to adding -stdlib=libc++
on your libc++
system which is configured that way. This matches the behaviour of all the newer systems, 10.9 and newer.
I changed clang-5.0
and newer to do exactly that on systems configured to used libc++
in their macports.conf, like yours. It can be seen by the default variants for clang-5.0, which, on your system, should be clang-5.0 +analyzer +defaultlibcxx +libstdcxx
.
The +defaultlibcxx
variant makes clang-5.0
add -stdlib=libc++
if none is specified, rather than -stdlib=libstdc++
, which is what you want it to do on your system.
SHORT story. If your clang-5.0
is installed correctly, with the +defaultlibcxx
variant on your system, building nmap
with clang-5.0
should work correctly, ie do this:
sudo port clean nmap sudo port -v install nmap configure.compiler=macports-clang-5.0
To add the -stdlib
to the build line instead, you would need to dig in a bit to the build. botan
does a fix for this, with a patch and then a reinplace:
# respect MacPorts configure values patchfiles-append patch-compiler_flags.diff \ patch-fix-install-with-destdir.diff \ patch-python_exe.diff \ patch-map_anon.diff post-patch { reinplace -W ${worksrcpath}/src/build-data/cc \ "s|__MACPORTS_CXX_STDLIB__|${configure.cxx_stdlib}|g" \ clang.txt }
alternatively, sometimes you can just add it to the build line by adding a configure.cxxflags-append
-- caution though, -stdlib=XYZ
is only supported by clang
, so you have to test to make sure that the build compiler is clang if you do this.
comment:4 Changed 5 years ago by lemzwerg (Werner Lemberg)
Ken, thanks a lot for this very helpful answer! Using
sudo port -v install nmap configure.compiler=macports-clang-5.0
worked like a charm. Would it be possible to add this to the Portfile in a clean way?
comment:5 Changed 5 years ago by kencu (Ken)
This is where we are running into some resistance/differences of opinion on MacPorts. There are those who will want only the ideal "build fix" solution used, and no other fix is acceptable -- then this ticket sits for months or years, as nobody will usually bother to spend the time to fix it like that on an old, unsupported system.
You could blacklist all compilers prior to clang-5.0
on systems < 10.9 that are configured to use libcxx
. That would work, and the logic flows smoothly enough. It is also kinda ugly in the Portfile. You see what I mean. When I do propose these kinds of fixes, the PRs tend to sit in the PR queue for weeks and go nowhere until I just close them out of frustration.
Sooner or later we'll default to libcxx
on all Intel systems 10.5+ -- then this will be easier to fix cleanly for everyone in base, because we'll just build with clang-5.0
and newer by default always.
In the meantime, I have set my "default compiler" in macports.conf
to be clang-5.0
, and that just fixes all these builds with ease. I suggest you consider doing that too.
comment:6 Changed 5 years ago by lemzwerg (Werner Lemberg)
Thanks for the advice. However, how do I set up the default compiler in macports.conf
? The documentation at https://guide.macports.org/chunked/internals.configuration-files.html doesn't give a hint, as far as I can see.
Log file of failing nmap build