Description of problem: When compiling code that requires the boost program options library, clang fails to link the library even when specified explicitly on the command line. Version-Release number of selected component (if applicable): clang 3.7.0 How reproducible: Always Steps to Reproduce: 1. cd /tmp 2. cp /usr/share/doc/boost-examples/libs/program_options/example/first.cpp . 3. clang++ -v -lboost_program_options -o first first.cpp Actual results: Fails to link with error: undefined reference to `boost::program_options::arg' Expected results: Obtain executable. GCC works fine: g++ -lboost_program_options -o first first.cpp Additional info: $ clang++ -v -lboost_program_options -o first first.cpp clang version 3.7.0 (tags/RELEASE_370/final) Target: x86_64-redhat-linux-gnu Thread model: posix Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/5.1.1 Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/5.1.1 Selected GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/5.1.1 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 "/usr/bin/clang" -cc1 -triple x86_64-redhat-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name first.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -target-linker-version 2.25 -v -dwarf-column-info -resource-dir /usr/bin/../lib/clang/3.7.0 -internal-isystem /usr/bin/../lib/gcc/x86_64-redhat-linux/5.1.1/../../../../include/c++/5.1.1 -internal-isystem /usr/bin/../lib/gcc/x86_64-redhat-linux/5.1.1/../../../../include/c++/5.1.1/x86_64-redhat-linux -internal-isystem /usr/bin/../lib/gcc/x86_64-redhat-linux/5.1.1/../../../../include/c++/5.1.1/backward -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.7.0/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdeprecated-macro -fdebug-compilation-dir /home/amota/Misc -ferror-limit 19 -fmessage-length 80 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/first-be49d8.o -x c++ first.cpp clang -cc1 version 3.7.0 based upon LLVM 3.7.0 default target x86_64-redhat-linux-gnu ignoring nonexistent directory "/include" #include "..." search starts here: #include <...> search starts here: /usr/bin/../lib/gcc/x86_64-redhat-linux/5.1.1/../../../../include/c++/5.1.1 /usr/bin/../lib/gcc/x86_64-redhat-linux/5.1.1/../../../../include/c++/5.1.1/x86_64-redhat-linux /usr/bin/../lib/gcc/x86_64-redhat-linux/5.1.1/../../../../include/c++/5.1.1/backward /usr/local/include /usr/bin/../lib/clang/3.7.0/include /usr/include End of search list. "/usr/bin/ld" --hash-style=gnu --no-add-needed --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o first /usr/bin/../lib/gcc/x86_64-redhat-linux/5.1.1/../../../../lib64/crt1.o /usr/bin/../lib/gcc/x86_64-redhat-linux/5.1.1/../../../../lib64/crti.o /usr/bin/../lib/gcc/x86_64-redhat-linux/5.1.1/crtbegin.o -L/usr/bin/../lib/gcc/x86_64-redhat-linux/5.1.1 -L/usr/bin/../lib/gcc/x86_64-redhat-linux/5.1.1/../../../../lib64 -L/usr/bin/../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/bin/../lib/gcc/x86_64-redhat-linux/5.1.1/../../.. -L/usr/bin/../lib -L/lib -L/usr/lib -lboost_program_options /tmp/first-be49d8.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/bin/../lib/gcc/x86_64-redhat-linux/5.1.1/crtend.o /usr/bin/../lib/gcc/x86_64-redhat-linux/5.1.1/../../../../lib64/crtn.o /tmp/first-be49d8.o: In function `boost::program_options::typed_value<double, char>::name() const': first.cpp:(.text._ZNK5boost15program_options11typed_valueIdcE4nameEv[_ZNK5boost15program_options11typed_valueIdcE4nameEv]+0x49): undefined reference to `boost::program_options::arg' /tmp/first-be49d8.o: In function `boost::program_options::validation_error::validation_error(boost::program_options::validation_error::kind_t, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int)': first.cpp:(.text._ZN5boost15program_options16validation_errorC2ENS1_6kind_tERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESA_i[_ZN5boost15program_options16validation_errorC2ENS1_6kind_tERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESA_i]+0x39): undefined reference to `boost::program_options::validation_error::get_template(boost::program_options::validation_error::kind_t)' clang: error: linker command failed with exit code 1 (use -v to see invocation)
For boost I'm using the version that comes with Fedora 23: boost-program-options-1.58.0-8.fc23.x86_64
This seems to be a problem with clang++ not supporting the new g++ ABI. See this email thread in the Debian bug list: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797917
(In reply to Alejandro Mota from comment #2) > This seems to be a problem with clang++ not supporting the new g++ ABI. See > this email thread in the Debian bug list: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797917 Yes, the problem is that Clang does not understand the abi_tag attribute, and libstdc++ in Fedora 23 now has _GLIBCXX_USE_CXX11_ABI enabled, requiring support for that attribute. (By the way, what works for me with a local build of recent Clang trunk on Fedora 23 is to add the patch <http://reviews.llvm.org/D12834?id=34645> "add gcc abi_tag support," plus a little patch > --- lib/Sema/SemaDeclAttr.cpp-ORIG 2015-11-03 21:25:50.024944255 +0100 > +++ lib/Sema/SemaDeclAttr.cpp 2015-11-03 21:25:58.785898507 +0100 > @@ -4272,9 +4272,6 @@ > > static void handleAbiTagAttr(Sema &S, Decl *D, > const AttributeList &Attr) { > - if (!checkAttributeAtLeastNumArgs(S, Attr, 1)) > - return; > - > SmallVector<std::string, 4> Tags; > > for (unsigned I = 0, E = Attr.getNumArgs(); I != E; ++I) { to work around Clang failing for an empty abi_tag attribute, which finds a bug in libstdc++ that is only fixed with <https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=226022> "Fix abi_tag in special modes" not included in the Fedora 23 libstdc++, also cf. <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68257> "Reject empty abi_tag attribute on inline namespace.")
That patch has at least one input case that results in a compiler crash (seems to be caused by a runaway recursion). I tried poking its author but he did not respond to either my email or the comments in the patch review upstream. We have applied the same patch in Arch Linux, a decision which I'm regretting a bit now; sticking to the old C++ ABI until Clang's incompatibility was properly fixed upstream might have been a better choice... ================================ $ clang++ -std=c++14 -xc++ - <<<'auto foo() { return []{}; }' clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.7.0 (tags/RELEASE_370/final) Target: x86_64-redhat-linux-gnu Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: Error generating preprocessed source(s) - ignoring input from stdin. clang: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs. ================================
This is a ping: Arch have updated to 3.8.0 with a newer patch. I think it's OK to have Fedora apply that too. This problem is quite serious. Links: http://reviews.llvm.org/D17567 http://reviews.llvm.org/D18035
(In reply to Tatsuyuki Ishi from comment #5) > This is a ping: Arch have updated to 3.8.0 with a newer patch. I think it's > OK to have Fedora apply that too. This problem is quite serious. Starting with clang-3.7.0-3.fc23, an older version of the abi_tag patch is included in Fedora. Does that already solve the problems reported in this bug? There are still open issues reported against upstream <http://reviews.llvm.org/D18035>, so it might make sense to wait until they are resolved.
The patch itself seems good, and the last report was just a miss in test. I think it's safe to apply the patch for 3.8.0 in rawhide. Just for a reference, it's working well on Arch and currently nobody had complained about it. The benefit of the patch will be much more than the possibly of the bug.
*** Bug 1282513 has been marked as a duplicate of this bug. ***
*** Bug 1349979 has been marked as a duplicate of this bug. ***
clang-3.8.0-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-d2313c8f75
clang-3.8.0-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d2313c8f75
clang-3.8.0-2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
What about Fedora 23? It has the same problem.
(In reply to Vitaliy Gribko from comment #13) > What about Fedora 23? It has the same problem. See comment 6. I was assuming that clang-3.7.0-3.fc23 is adequate enough.