Project

General

Profile

Actions

Bug #2209

closed

waf configure fails with clang on linux because of -stdlib=libc++

Added by Davide Pesavento over 9 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Normal
Category:
Build
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:

Description

On Ubuntu 14.10

davide@ndnbox:~/NFD$ clang++ --version
Ubuntu clang version 3.5.0-4ubuntu2 (tags/RELEASE_350/final) (based on LLVM 3.5.0)
Target: x86_64-pc-linux-gnu
Thread model: posix

davide@ndnbox:~/NFD$ CXX=clang++ ./waf configure --debug --with-tests
[...]
Checking for 'g++' (C++ compiler)        : clang++ 
Checking supported CXXFLAGS              : -std=c++0x -std=c++11 -stdlib=libc++ -pedantic -Wall -O0 -g3 -fcolor-diagnostics -fdiagnostics-color -Werror -Wno-error=unneeded-internal-declaration 
Checking supported LINKFLAGS             :  
[...]
Checking boost includes                    : 1.55.0 
Checking boost libs                        : ok 
Checking for boost linkage                 : Could not link against boost libraries using supplied options 
The configuration failed
(complete log in /home/davide/NFD/build/config.log)

davide@ndnbox:~/NFD$ tail -n33 build/config.log 
------------------------------------------
Checking for boost linkage
==>

#include <boost/system/error_code.hpp>
int main() { boost::system::error_code c; }

<==
[1/2] Compiling build/.conf_check_1e35a10396c7e46959c846e051d6b159/test.cpp

['clang++', '-std=c++0x', '-std=c++11', '-stdlib=libc++', '-pedantic', '-Wall', '-O0', '-g3', '-fcolor-diagnostics', '-fdiagnostics-color', '-Werror', '-Wno-error=unneeded-internal-declaration', '-I/usr/include', '-D_DEBUG=1', '-DHAVE_LIBRT=1', '-DHAVE_LIBRESOLV=1', '-DWITH_TESTS=1', '../test.cpp', '-c', '-o', '/home/davide/NFD/build/.conf_check_1e35a10396c7e46959c846e051d6b159/testbuild/test.cpp.1.o']
err: In file included from ../test.cpp:2:
In file included from /usr/include/boost/system/error_code.hpp:14:
In file included from /usr/include/boost/system/config.hpp:13:
In file included from /usr/include/boost/config.hpp:40:
/usr/include/boost/config/select_stdlib_config.hpp:18:12: fatal error: 'cstddef' file not found
#  include <cstddef>
           ^
1 error generated.

from /home/davide/NFD: Test does not build: Traceback (most recent call last):
  File "/home/davide/NFD/.waf-1.8.2-a01aa13963437a19e5d8748cf2afd71b/waflib/Configure.py", line 337, in run_build
    bld.compile()
  File "/home/davide/NFD/.waf-1.8.2-a01aa13963437a19e5d8748cf2afd71b/waflib/Build.py", line 184, in compile
    raise Errors.BuildError(self.producer.error)
BuildError: Build failed
 -> task in 'testprog' failed (exit status 1): 
    {task 140174880514768: cxx test.cpp -> test.cpp.1.o}
['clang++', '-std=c++0x', '-std=c++11', '-stdlib=libc++', '-pedantic', '-Wall', '-O0', '-g3', '-fcolor-diagnostics', '-fdiagnostics-color', '-Werror', '-Wno-error=unneeded-internal-declaration', '-I/usr/include', '-D_DEBUG=1', '-DHAVE_LIBRT=1', '-DHAVE_LIBRESOLV=1', '-DWITH_TESTS=1', '../test.cpp', '-c', '-o', '/home/davide/NFD/build/.conf_check_1e35a10396c7e46959c846e051d6b159/testbuild/test.cpp.1.o']
Actions #1

Updated by Davide Pesavento over 9 years ago

Removing -stdlib=libc++ makes it build.

Actions #2

Updated by Alex Afanasyev over 9 years ago

Which stdlib is then used on Linux? Does it mean libc++ in clang 3.5 is no standard-complying?

I would be happy to remove that, as it is really needed as a default on on OSX 10.8. If we can make such differentiation in wscript...

Actions #3

Updated by Davide Pesavento over 9 years ago

Alex Afanasyev wrote:

Which stdlib is then used on Linux?

The "usual" gcc's libstdc++.

Does it mean libc++ in clang 3.5 is no standard-complying?

It's still a WIP on Linux, definitely not production ready. The main targets of clang/llvm/libc++ have been OS X and FreeBSD so far. See also http://stackoverflow.com/questions/14972425/should-i-use-libc-or-libstdc

I would be happy to remove that, as it is really needed as a default on on OSX 10.8. If we can make such differentiation in wscript...

Yeah just use libc++ on OS X, that was the original intention anyway.

Actions #4

Updated by Davide Pesavento about 9 years ago

  • Subject changed from waf configure fails with clang 3.5 because of -stdlib=libc++ to waf configure fails with clang on linux because of -stdlib=libc++
  • Start date deleted (11/21/2014)
Actions #5

Updated by Alex Afanasyev about 9 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 50

An update similar to ndn-cxx:commit:01515791 needs to be done in NFD codebase

Actions #6

Updated by Alex Afanasyev about 9 years ago

  • Status changed from In Progress to Code review
  • % Done changed from 50 to 80

After http://gerrit.named-data.net/#/c/1676/ verified and approved, I will submit the same patch for all other managed projects.

Actions #7

Updated by Junxiao Shi about 9 years ago

  • Status changed from Code review to Resolved

@Davide, please verify that the Bug is resolved.

Actions #8

Updated by Davide Pesavento about 9 years ago

  • Status changed from Resolved to In Progress

Even worse, now I get:

Checking for 'g++' (C++ compiler)        : clang++ 
The version of gcc you are using (3.5.0) is too old.
The minimum supported gcc version is 4.6.0.
Actions #9

Updated by Alex Afanasyev about 9 years ago

There is a different command to enable clang compiler (we can put it in some docs):

./waf configure --check-cxx-compiler=clang++ ...

or, if you want to specify exact binary too

CXX=<path-to-clang++> ./waf configure --check-cxx-compiler=clang++ ...

Even though I agree that waf shouldn't have assumed that it successfully detected gcc when clang specified, I don't really want to work on this any time soon. We probably should create an issue with waf tracker for this to be resolved at some point.

Actions #10

Updated by Davide Pesavento about 9 years ago

It works with --check-cxx-compiler=clang++ but I don't like it at all.

Actions #11

Updated by Junxiao Shi about 9 years ago

As suggested in note-9, documentation is needed for --check-cxx-compiler configure option, and then this issue can close.

Actions #12

Updated by Davide Pesavento about 9 years ago

I disagree. Setting CXX on the command line is the standard procedure, and it must be made to work. At this point, I'd rather rollback the build system changes that separated the flags handling between gcc and clang, which uses the utterly broken CXX_NAME.

Actions #13

Updated by Alex Afanasyev about 9 years ago

  • Status changed from In Progress to Code review
  • % Done changed from 80 to 100

The latest version of waf solves the issue. I'm updating waf in ndn-cxx and NFD to https://github.com/cawka/waf (based on current HEAD + 3 small custom patches)

Actions #14

Updated by Davide Pesavento about 9 years ago

  • Status changed from Code review to Closed
Actions

Also available in: Atom PDF