[cfe-users] Linking issues with Clang 3.6.2

Mon Jul 20 02:50:06 PDT 2015

John,

Thanks for the feedback. I've executed the compiling as well as the linking with -v, but I can't find anything particular with it (I removed all project include directories, i.e. -I <Project-include directories>, & library usage, i.e. -l< workspace-libraries>, from both commands, this saves quite a bit of screen real-estate):

"/usr/local/bin/clang-3.6" -cc1 -triple i386-pc-linux-gnu -emit-obj -disable-free -disable-llvm-verifier -main-file-name TmcExe.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array
-target-cpu pentium4 -momit-leaf-frame-pointer -v -dwarf-column-info -coverage-file/home/rohill/Projects/60ChannelSIP/obj/Clang/<Executable>/TmcExe.o -resource-dir /usr/local/bin/../lib/clang/3.6.2 -dependency-file
/home/rohill/Projects/60ChannelSIP/obj/Clang/<Executable>/TmcExe.d -MT /home/rohill/Projects/60ChannelSIP/obj/Clang/<Executable>/TmcExe.o -D BOOST_NO_CXX11_EXPLICIT_CONVERSION_OPERATORS -D SYSTEM_USE_DEFAULT_DISPATCHER=0 -D WEBS -D UEMF
-D GOAHEAD_LINUX -D USER_MANAGEMENT_SUPPORT -D DIGEST_ACCESS_SUPPORT -D _NO_LOGGING -D HEADER_DES_LOCL_H -D _USE_OPENSSL -I <Project-include directories> -internal-isystem /usr/local/bin/../lib/gcc/i686-pc-linux-gnu/5.1.0/../../../../include/c++/5.1.0
-internal-isystem /usr/local/bin/../lib/gcc/i686-pc-linux-gnu/5.1.0/../../../../include/c++/5.1.0/i686-pc-linux-gnu -internal-isystem /usr/local/bin/../lib/gcc/i686-pc-linux-gnu/5.1.0/../../../../include/c++/5.1.0/backward -internal-isystem /usr/local/include -internal-isystem
/usr/local/bin/../lib/clang/3.6.2/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -O2 -Wall -Werror -Wnon-virtual-dtor -Wno-overloaded-virtual -Wno-missing-braces -Wno-uninitialized -std=c++1y -fdeprecated-macro -fdebug-compilation-dir
/home/rohill/Projects/60ChannelSIP/Tmc -ferror-limit 19 -fmessage-length 0 -pthread -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -vectorize-loops -vectorize-slp
-o /home/rohill/Projects/60ChannelSIP/obj/Clang/<Executable>/TmcExe.o -x c++ /home/rohill/Projects/60ChannelSIP/Tmc/Source/TmcExe.cpp

"/usr/bin/ld" -export-dynamic -z relro --hash-style=gnu --hash-style=both --build-id --enable-new-dtags --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o /home/rohill/Projects/60ChannelSIP/bin/Clang/opt/swmi/bin/TetraNode /usr/lib/crt1.o /usr/lib/crti.o
/usr/local/bin/../lib/gcc/i686-pc-linux-gnu/5.1.0/crtbegin.o -L/home/rohill/Projects/60ChannelSIP/bin/Clang/opt/swmi/lib -L/usr/local/bin/../lib/gcc/i686-pc-linux-gnu/5.1.0 -L/usr/local/bin/../lib/gcc/i686-pc-linux-gnu/5.1.0/../../.. -L/usr/local/bin/../lib -L/lib -L/usr/lib -ltcmalloc_minimal
-rpath ../lib -rpath /opt/swmi/lib <project-builld-objects> -l<workspace-libraries> -lboost_signals -lboost_system -lboost_filesystem -lboost_regex -lboost_thread -lboost_iostreams -lboost_program_options -lboost_chrono -lagent++ -lsnmp++ -lmysqlpp -lmysqlclient -lrt -lncurses -lcrypt -lxml2
-lcurl -lz -lbz2 -lssl -lcrypto -ldl -luuid -ljansson -lstdc++ -lm -lgcc_s -lgcc -lpthread -lc -lgcc_s -lgcc /usr/local/bin/../lib/gcc/i686-pc-linux-gnu/5.1.0/crtend.o /usr/lib/crtn.o

ldconfig shows that it looks to /usr/local/lib for libstdc++
# ldconfig -p | grep libstdc++
libstdc++.so.6 (libc6) => /usr/local/lib/libstdc++.so.6
libstdc++.so.6 (libc6) => /usr/lib/libstdc++.so.6
libstdc++.so (libc6) => /usr/local/lib/libstdc++.so

So from what I can tell is it's looking for include files regarding gcc in the gcc 5.1 directories, and it's trying to link with stdc++ (marked in bold), which should be the one from /usr/local/lib.
The directories it should search in specify -L/usr/local/bin/../lib before -L/lib & -L/usr/lib (though I can't tell which takes precedence over which).

As for your other suggestion, I don't see what benefit the boost predef library has. Can you explain a bit more about this?

Kind regards,
Roy Kleefman

[cid:image001.jpg at 01D0C2D4.53BC77A0]
Rohill * Edisonstraat 12 * 7903 AN Hoogeveen * The Netherlands
Phone: +31-528-263355 * Fax: +31-528-271844 * www.rohill.com<http://www.rohill.com/>
Chamber of Commerce Meppel registration no. 09084362
This email, including any attached files, is confidential, may be legally privileged, and is solely for the intended recipient(s).
If you have received this email in error, please destroy it and notify Rohill immediately. Any unauthorized use, dissemination,
disclosure, copying or printing is strictly prohibited. Thank you.

From: Fletcher, John P [mailto:j.p.fletcher at aston.ac.uk]
Sent: zaterdag 18 juli 2015 12:30
To: Roy Kleefman
Subject: RE: Linking issues with Clang 3.6.2

Roy

I have been working with a combination of clang and gcc on in my case Ubuntu 12.04 for a number of years.

My general understanding is like this.

When you install a new version of gcc it will know to use the version of libstdc++ which came with it.

Your installation of gcc 5.1 should do this.  I have not used 5.1 but my copy of gcc 5.0 does do it.

Clang is different.  The default action of clang will be to use the libstdc++ from the default version on your system.  That may be the cause of your problems.  It is possible to persuade clang to behave otherwise.  There are two choices, either to use a different version of libstdc++ from e.g. gcc 5.1, or else to use libc++ which comes with clang.  One way to understand what is going on is to compile a test file with option -v and see what include files and libraries are being searched.

I have done both these things.  I have to comment that the instructions given with clang are not complete and I have had to work out a lot of things for myself.

It is possible, but not trivial, to get a boost library called boost predef to identify which compiler and library is being used, which I have found a great help to understand this.  One oddity is that all the versions of clang I have seen declare themselves to be gcc 4.2.1!!

Here is an example makefile for clang 3.5 with include and libraries for gcc 4.8.2.  It uses a lot of defines which are given below.

boost_predef_ex_clang35d_482: boost_predef_ex.cpp Makefile
    $(CLANG35D) -v -I$(CLANG35DINCLUDE) -I$(BOOST) -I$(GCC482_INCLUDE) -I$(GCC482_INCLUDE)/x86_64-unknown-linux-gnu  -I$(GCC482_INCLUDE)/backward -O2 boost_predef_ex.cpp -oboost_predef_ex_clang35d_482 $(GCC482_LIBDIR) -L$(CLANG35DLIBDIR) $(CLANGLIBS)

CLANGLIBS=-lclangBasic -lLLVMSupport -lpthread -ldl

BOOST is my current boost installation.

######################################################################
# September 2014 clang and llvm 3.5 from distribution
LLVM35D=/home/fletcher/LLVM/llvm-3.5.distrib/local
CLANG35D=$(LLVM35D)/bin/clang++
CLANG35DINCLUDE=$(LLVM35D)/include
CLANG35DLIBDIR=$(LLVM35D)/lib
######################################################################

######################################################################
#
# gcc 4.8.2
#
GCC-4.8.2HOME=/opt/gcc-4.8.2
GPP482=$(GCC-4.8.2HOME)/bin/g++
GCC482=$(GCC-4.8.2HOME)/bin/gcc
GCC482_INCLUDE=$(GCC-4.8.2HOME)/include/c++/4.8.2
GCC482_LIBDIR=-Xlinker -R$(GCC-4.8.2HOME)/lib64 -L$(GCC-4.8.2HOME)/lib64
GCC482_INCLUDE_FOR_CLANG=-I$(GCC482_INCLUDE) -I$(GCC482_INCLUDE)/x86_64-unknown-linux-gnu -I$(GCC482_INCLUDE)/backward
#
######################################################################

I am pushed for time today, but please ask me for more information.  I would be happy to send you a copy of my file boost_predef_ex.cpp but it needs tidying up.

Best wishes

John

________________________________
From: cfe-users-bounces at cs.uiuc.edu<mailto:cfe-users-bounces at cs.uiuc.edu> [cfe-users-bounces at cs.uiuc.edu] on behalf of Roy Kleefman [roy.kleefman at rohill.nl]
Sent: 17 July 2015 09:26
To: cfe-users at cs.uiuc.edu<mailto:cfe-users at cs.uiuc.edu>
Subject: [cfe-users] Linking issues with Clang 3.6.2
Hello,

I have a C++ project (quite extensive, lots of sub-projects that produce libraries used in the final executable) which I can compile just fine with gcc 5.1.0.
As an alternative, some preparations have been previously done to compile the project with clang (in this case 3.6.2), which we'd as a company like to transition to at some point.
However when compiling with clang, I get several undefined references when linking the final executable on some libraries in the project which I don't get when compiling with gcc.

First let me explain my build environment, which is custom:
I have an openSUSE 11.3 OS due to backwards compatibility reasons
Originally, gcc 4.5 is installed (located in /usr/bin)
I compiled gcc 5.1 myself (using gcc 4.5, located in /usr/local/bin, $PATH has been modified to search here first)
I compiled clang 3.6.2 myself (using gcc 5.1, located in /usr/local/bin)
Several other libraries (including mysql++ & boost) are compiled with gcc  (located in /usr/local/lib, headers in /usr/local/include)
Codelite 8.0, compiled with gcc 5.1

Now when doing a clean clang build of my project I get 4 undefind reference linking errors:
/home/rohill/Projects/60ChannelSIP/bin/Clang/opt/swmi/lib/libSystem.so: undefined reference to `boost::program_options::arg'
/home/rohill/Projects/60ChannelSIP/bin/Clang/opt/swmi/lib/libMysql.so: undefined reference to `mysqlpp::Query::str(mysqlpp::SQLQueryParms&)'
/home/rohill/Projects/60ChannelSIP/bin/Clang/opt/swmi/lib/libTfc.so: undefined reference to `std::ios_base::failure::failure(char const*, std::error_code const&)'
/home/rohill/Projects/60ChannelSIP/bin/Clang/opt/swmi/lib/libTfc.so: undefined reference to `boost::gregorian::greg_month::get_month_map_ptr()'

I am able to resolve the issues with boost & mysqlpp by recompiling these with clang, but after that, I get 2 more undefined references to std::ios_base::failure::failure:
/home/rohill/Projects/60ChannelSIP/bin/Clang/opt/swmi/lib/libboost_iostreams.so: undefined reference to `std::ios_base::failure::failure(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/home/rohill/Projects/60ChannelSIP/bin/Clang/opt/swmi/lib/libboost_iostreams.so: undefined reference to `std::ios_base::failure::failure(char const*, std::error_code const&)'
/home/rohill/Projects/60ChannelSIP/bin/Clang/opt/swmi/lib/libTfc.so: undefined reference to `std::ios_base::failure::failure(char const*, std::error_code const&)'
But I don't know if I want to do this, because I am no longer able to compile the project with gcc after this.

Furthermore, I find it rather strange that clang produces these linking issues in the first place, as it can compile and link those specific libraries just fine earlier in the build.
All external libraries used to compile & link the projects libraries are also configured for the linking of the final executable.

I am at a loss for an answer, but I suspect it having to do something with gcc 4.5 in some way, so I hope to get an answer via this.

Kind regards,

Roy Kleefman

[cid:image001.jpg at 01D0C2D4.53BC77A0]
Rohill * Edisonstraat 12 * 7903 AN Hoogeveen * The Netherlands
Phone: +31-528-263355 * Fax: +31-528-271844 * www.rohill.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rohill.com_&d=AwMFAg&c=8hUWFZcy2Z-Za5rBPlktOQ&r=HkOpO_AvqLiQRhM4TkA0OAkVFWLZciHjAvQWQb25mkU&m=KNf6Nh9dzGmgCNcakN5VWiP7bWIHiohOPl63pa97iGU&s=npCJnL02eauIju7KVYGlz6AauQTMf87CvLjCTOAakiA&e=>
Chamber of Commerce Meppel registration no. 09084362
This email, including any attached files, is confidential, may be legally privileged, and is solely for the intended recipient(s).
If you have received this email in error, please destroy it and notify Rohill immediately. Any unauthorized use, dissemination,
disclosure, copying or printing is strictly prohibited. Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20150720/96aaf497/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2979 bytes
Desc: image001.jpg
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20150720/96aaf497/attachment.jpg>