Solaris ld: fatal: unrecognized option '--' - gcc

I am trying to compile Apache Qpid on a Solaris machine, but it failes during linking:
Scanning dependencies of target qpidtypes
[ 0%] Building CXX object src/CMakeFiles/qpidtypes.dir/qpid/types/Exception.cpp.o
[ 0%] Building CXX object src/CMakeFiles/qpidtypes.dir/qpid/types/Uuid.cpp.o
[ 0%] Building CXX object src/CMakeFiles/qpidtypes.dir/qpid/types/Variant.cpp.o
Linking CXX shared library libqpidtypes.so
ld: fatal: unrecognized option '--'
ld: fatal: use the -z help option for usage information
*** Error code 1
The following command caused the error:
cd /export/home/user/qpid-cpp-0.34/build/src && /opt/csw/bin/cmake -E cmake_link_script CMakeFiles/qpidtypes.dir/link.txt --verbose=
make: Fatal error: Command failed for target `src/libqpidtypes.so.1.0.0'
Current working directory /export/home/user/qpid-cpp-0.34/build
*** Error code 1
The command file which is invoked by the -E option is CMakeFiles/qpidtypes.dir/link.txt and it contains:
/usr/bin/gcc -fPIC -fno-visibility-inlines-hidden -fvisibility=hidden -Wl,--version-script=/export/home/user/qpid-cpp-0.34/src/qpid.linkmap -m64 -pthread -shared -Wl,-hlibqpidtypes.so.1 -o libqpidtypes.so.1.0.0 CMakeFiles/qpidtypes.dir/qpid/types/Exception.cpp.o CMakeFiles/qpidtypes.dir/qpid/types/Uuid.cpp.o CMakeFiles/qpidtypes.dir/qpid/types/Variant.cpp.o -L/usr/local/lib -L/usr/lib/mps -luuid -Wl,-R/usr/local/lib:/usr/lib/mps:
The problem seems to be the -Wl,--version-script=/export/home/user/qpid-cpp-0.34/src/qpid.linkmap
This question got around using the option with two dashes, but I don't see how I could do that.
Question: how can I get ld to accept the --version-script information?
Some info on the ld version:
$ gcc -print-prog-name=ld
/usr/ccs/bin/ld
$ /usr/ccs/bin/ld -V
ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.1514
Some info on the gcc version:
Target: sparc-sun-solaris2.10
Configured with: /home/dam/mgar/pkg/gcc4/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-4.9.2/configure --prefix=/opt/csw --exec_prefix=/opt/csw --bindir=/opt/csw/bin --sbindir=/opt/csw/sbin --libexecdir=/opt/csw/libexec --datadir=/opt/csw/share --sysconfdir=/etc/opt/csw --sharedstatedir=/opt/csw/share --localstatedir=/var/opt/csw --libdir=/opt/csw/lib --infodir=/opt/csw/share/info --includedir=/opt/csw/include --mandir=/opt/csw/share/man --enable-cloog-backend=isl --enable-java-awt=xlib --enable-languages=ada,c,c++,fortran,go,java,objc --enable-libada --enable-libssp --enable-nls --enable-objc-gc --enable-threads=posix --program-suffix=-4.9 --with-cloog=/opt/csw --with-gmp=/opt/csw --with-included-gettext --with-ld=/usr/ccs/bin/ld --without-gnu-ld --with-libiconv-prefix=/opt/csw --with-mpfr=/opt/csw --with-ppl=/opt/csw --with-system-zlib=/opt/csw --with-as=/usr/ccs/bin/as --without-gnu-as
Thread model: posix
gcc version 4.9.2 (GCC)

I had the same error message when building openldap version 2.4.39 on solaris 10.
Indeed, double dashes "--", as said in previous answer, is not supported by the linker provided by solaris. But you have to find the option parameter which is used with two dashes whereas is not explicitly mentionned in the error message.
To find the corresponding option, you must look in the link command displayed in the console and look into configure files or in your project configuration files where it is defined.
Particularly for openldap, I used configure files delivered within the library. But the problem was that the linker option rpath was used with two dashes to set the following variable like this:
hardcode_libdir_flag_spec='${wl}--rpath ${wl}$libdir'
The problem has been fixed in some aclocal.m4 files (in different folders) and in the libtool script by removing the extra dash.
The library has also been built on linux without modifying any other file.

The problem is that the Solaris linker does not recognize many of the options starting with two dashes.
Solaris ld: fatal: unrecognized option '--'
Can be solved by using
ld -z help
and finding the correct replacement.
In my particular case I found a solution in the qpid mailing list, which is not to use --version-script at all:
On SunOs (at least on my machine) this does not work:
/usr/bin/gcc -fPIC -fno-visibility-inlines-hidden -fvisibility=hidden
-Wl,--version-script=/export/home/noname/install/qpid-0.28_tmptest/cpp/src/qpid.linkmap
-shared -Wl,-hlibqpidtypes.so.1 -o libqpidtypes.so.1.0.0 CMakeFiles/qpidtypes.dir/qpid/types/Exception.cpp.o
CMakeFiles/qpidtypes.dir/qpid/types/Uuid.cpp.o
CMakeFiles/qpidtypes.dir/qpid/types/Variant.cpp.o -L/usr/local/lib
-L/usr/lib/mps -luuid -Wl,-R/usr/local/lib:/usr/lib/mps
The problem is:
"-Wl,--version-script=/export/home/noname/install/qpid-0.28_tmptest/cpp/src/qpid.linkmap"
So the following needs to be inserted into cpp/src/CMakeLists.txt:
184 if (GCC_VERSION VERSION_EQUAL 4.1.2) 185 message
(STATUS "Cannot restrict library symbol export on gcc
4.1.2") 186 set (HIDE_SYMBOL_FLAGS "-fno-visibility-inlines-hidden") 187 else (GCC_VERSION
VERSION_EQUAL 4.1.2) 188 set (HIDE_SYMBOL_FLAGS
"-fno-visibility-inlines-hidden
-fvisibility=hidden") 189 set (QPID_LINKMAP ${CMAKE_CURRENT_SOURCE_DIR}/qpid.linkmap) 190 191 #
--------------------- the following three lines need to be inserted for Solaris 192 if (NOT CMAKE_SYSTEM_NAME STREQUAL SunOS) 193
set (LINK_VERSION_SCRIPT_FLAG "-Wl,--version-script=${QPID_LINKMAP}")
194 endif (NOT CMAKE_SYSTEM_NAME STREQUAL SunOS) 195 196
endif (GCC_VERSION VERSION_EQUAL 4.1.2)

Related

Sysroot is incorrect in Ninja when trying to build library

I'm trying to build Google's Skia library on Mac, but when I try running
ninja -C out/Static/
in order to build the library, it gives me this error (after many, many similar errors):
[14/1073] compile ../../src/gpu/GrBackendTextureImageGenerator.cpp
FAILED: obj/src/gpu/gpu.GrBackendTextureImageGenerator.o
c++ -MD -MF obj/src/gpu/gpu.GrBackendTextureImageGenerator.o.d -DNDEBUG -DSK_ASSUME_GL=1 -DSK_ENABLE_API_AVAILABLE -DSK_GAMMA_APPLY_TO_A8 -DSKIA_IMPLEMENTATION=1 -DSK_GL -I../.. -Wno-attributes -fstrict-aliasing -fPIC -fvisibility=hidden -isysroot b\'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk\\n\' -O3 -Wno-sign-conversion -Wno-unused-parameter -std=c++17 -fvisibility-inlines-hidden -fno-exceptions -fno-rtti -c ../../src/gpu/GrBackendTextureImageGenerator.cpp -o obj/src/gpu/gpu.GrBackendTextureImageGenerator.o
clang: warning: no such sysroot directory: 'b'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk\n'' [-Wmissing-sysroot]
In file included from ../../src/gpu/GrBackendTextureImageGenerator.cpp:8:
In file included from ../../include/gpu/GrContext.h:11:
In file included from ../../include/core/SkMatrix.h:11:
In file included from ../../include/core/SkRect.h:11:
In file included from ../../include/core/SkPoint.h:11:
In file included from ../../include/core/SkMath.h:11:
../../include/core/SkTypes.h:26:18: fatal error: 'TargetConditionals.h' file not found
#include "TargetConditionals.h"
^~~~~~~~~~~~~~~~~~~~~~
1 error generated.
ninja: build stopped: subcommand failed.
It seems like the sysroot directory b'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk\n' is wrong, however "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk" does exist and "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/" has the file TargetConditionals.h.
I haven't used ninja before, but I tried looking in toolchain.ninja but could find no way to change the sysroot variable. I also reinstalled Xcode and Xcode command line tools, to no avail. Any help would be greatly appreciated!
I too struggled a lot. The solutions that I tried:
xcode-select --install for installing command line tools. But it used to say that command line tools are already installed.
Tried re-installing xcode to fix some linkage issue.
Tried a could of other solutions found on web.
Finally, what worked for me is by switching to python2. I had python2 and python3 installed. My path environment variable in .zshrc was giving precedence to python3. So, all internal scripts generated by ninja had python3 in precedence.
I temporarily removed python3, you can keep both but its precedence should be changed. Then regenerate build directory using gn. Then use ninja to build.
Note:
clang: warning: no such sysroot directory: 'b'/Applications/ : Here 'b' use to represent that string literal should be treated as byte literal in python3. So that could be the cause.

Caffe compilation fails due to unsupported gcc compiler version

I struggle with Caffe compilation. Unfortunately I failed to compile it.
Steps I followed:
git clone https://github.com/BVLC/caffe.git
cd caffe
mkdir build
cd build
cmake ..
make all
Running make all fails with the following error message:
[ 2%] Building NVCC (Device) object src/caffe/CMakeFiles/cuda_compile.dir/util/cuda_compile_generated_im2col.cu.o
In file included from /usr/include/cuda_runtime.h:59:0,
from <command-line>:0:
/usr/include/host_config.h:82:2: error: #error -- unsupported GNU version! gcc 4.9 and up are not supported!
#error -- unsupported GNU version! gcc 4.9 and up are not supported!
^
CMake Error at cuda_compile_generated_im2col.cu.o.cmake:207 (message):
Error generating /mydir/caffe/build/src/caffe/CMakeFiles/cuda_compile.dir/util/./cuda_compile_generated_im2col.cu.o
Software version:
OS: Debian.
gcc version: 5.3.1.
nvcc version: 6.5.12.
cat /proc/driver/nvidia/version result:
NVRM version: NVIDIA UNIX x86_64 Kernel Module 352.63 Sat Nov 7 21:25:42 PST 2015
GCC version: gcc version 4.8.5 (Debian 4.8.5-3)
Attempts to solve the problem
1st try
Simple solutions are often best ones, so (as suggested here) I tried to comment out macro checking gcc version from /usr/include/host_config.h (line 82). Unfortunately it doesn't work and compilation fails badly:
1 catastrophic error detected in the compilation of "/tmp/tmpxft_000069c2_00000000-4_im2col.cpp4.ii".
2nd try
I tried to run:
cmake -D CMAKE_CXX_COMPILER=g++-4.8 ..
make
but it fails with exactly the same error message (even though g++-4.8 should be accepted).
3rd try
I've found similar problem (though not related to Caffe) and I tried to solve it as suggested in the accepted answer.
What I did:
I've ran grep -iR "find_package(CUDA" caffe command and found Cuda.cmake file which has find_package(CUDA 5.5 QUIET) in line 225.
I added set(CUDA_HOST_COMPILER /usr/bin/gcc-4.8) to Cuda.cmake, line before line: find_package(CUDA 5.5 QUIET).
I removed everything from build directory and ran cmake and make again - with and without -D CMAKE_CXX_COMPILER=g++-4.8.
Unfortunately result is exactly the same. Caffe probably overwrites it somehow - I didn't figure it out how.
make VERBOSE=1 2>&1 | grep -i compiler-bindir returns nothing.
What's interesting, make VERBOSE=1 prints command that fails, which is:
/usr/bin/nvcc -M -D__CUDACC__ /mydir/caffe/src/caffe/util/im2col.cu -o /mydir/caffe/build/src/caffe/CMakeFiles/cuda_compile.dir/util/cuda_compile_generated_im2col.cu.o.NVCC-depend -ccbin /usr/bin/cc -m64 -DUSE_LMDB -DUSE_LEVELDB -DUSE_OPENCV -DWITH_PYTHON_LAYER -DGTEST_USE_OWN_TR1_TUPLE -Xcompiler ,\"-fPIC\",\"-Wall\",\"-Wno-sign-compare\",\"-Wno-uninitialized\",\"-O3\",\"-DNDEBUG\" -gencode arch=compute_20,code=sm_21 -Xcudafe --diag_suppress=cc_clobber_ignored -Xcudafe --diag_suppress=integer_sign_change -Xcudafe --diag_suppress=useless_using_declaration -Xcudafe --diag_suppress=set_but_not_used -Xcompiler -fPIC -DNVCC -I/usr/include -I/mydir/caffe/src -I/usr/include -I/mydir/caffe/build/include -I/usr/include/hdf5/serial -I/usr/include/opencv -I/usr/include/atlas -I/usr/include/python2.7 -I/usr/lib/python2.7/dist-packages/numpy/core/include -I/mydir/caffe/include -I/mydir/caffe/build
when I add --compiler-bindir /usr/bin/gcc-4.8 flag manually, it prints error:
nvcc fatal : redefinition of argument 'compiler-bindir'
which may be related to this bug report.
Edit: I didn't notice that --compiler-bindir and -ccbin are the same options, and the latter is already set in above command that failed. When I changed -ccbin /usr/bin/cc to -ccbin /usr/bin/gcc-4.8 in above command that failed, it completes successfully. Now I need to find option in Caffe's CMake file that overwrite -ccbin in all subsequent Caffe's CMakes. Looking at cmake/Cuda.cmake:252:list(APPEND CUDA_NVCC_FLAGS ${NVCC_FLAGS_EXTRA} seems to be good way to go.
How can I successfully complete my compilation? Any help is appreciated.
Related SO questions:
host_config.h:unsupported GNU version! gcc versions later than 4.9 are not supported.
CUDA 6.5 complains about not supporting gcc 4.9 - what to do?.
cmake -D CUDA_NVCC_FLAGS="-ccbin gcc-4.8" .. && make causes successful compilation.
Now another problem showed up: linking Google's libgflags or libprotobuf fails probably due to fact that it was compiled with newer gcc version but it's not related to asked question.
My machine runs Ubuntu 15.10, and my default compiler version is gcc 5.2.1 .
Commenting out the #error directive in line 115 of file
/usr/local/cuda-7.5/include/host_config.h
(or whatever the path on your system is) did the trick for me. Caffe compiled fine, all tests ran smoothly.
On the other hand, if one chooses to ignore this and proceed to compile part of the project with one compiler version, part of the project with another (for me it was gcc-4.8 and gcc-5.2.1), linking problems will arise. The linking problems of protobuf and libgflags another answer mentions are not unrelated to this.

CMake (2.8.12.2) compiler check on Ubuntu 14.04 fails

I'm trying to run this simple CMake command:
$ cmake -D CMAKE_C_COMPILER=/usr/bin/gcc -D CMAKE_CXX_COMPILER=/usr/bin/g++ ./src/
I get the following output:
-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- broken
CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:61 (message):
The C compiler "/usr/bin/gcc" is not able to compile a simple test program.
The reason for the error is the following:
gcc: error: unrecognized command line option ‘-rpath’
because CMake is trying to link with the following command:
/usr/bin/gcc -rpath /usr/local/openblas/lib
CMakeFiles/cmTryCompileExec1190183239.dir/testCCompiler.c.o -o
cmTryCompileExec1190183239 -rdynamic
to my knowledge there is no stand alone '-rpath' option with gcc. I'm not sure why CMake is trying to do this.
Did anyone else come across this? Solutions?
Thanks!
PS: Some more info that maybe useful:
I'm trying to learn how to use CMake so the directory structure is very simple:
-cmake_test/
-bin/
-src/
-executable.cpp
-CMakeLists.txt
-CMakeLists.txt
Edit:
Complete output for
$ cmake ./src/
-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- broken
CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:61 (message):
The C compiler "/usr/bin/cc" is not able to compile a simple test program.
It fails with the following output:
Change Dir: /home/gyorgy/Workspace/CPP_Tests/src/cmake_test/CMakeFiles/CMakeTmp
Run Build Command:/usr/bin/make "cmTryCompileExec961681416/fast"
/usr/bin/make -f CMakeFiles/cmTryCompileExec961681416.dir/build.make
CMakeFiles/cmTryCompileExec961681416.dir/build
make[1]: Entering directory
`/home/gyorgy/Workspace/CPP_Tests/src/cmake_test/CMakeFiles/CMakeTmp'
/usr/bin/cmake -E cmake_progress_report
/home/gyorgy/Workspace/CPP_Tests/src/cmake_test/CMakeFiles/CMakeTmp/CMakeFiles
1
Building C object
CMakeFiles/cmTryCompileExec961681416.dir/testCCompiler.c.o
/usr/bin/cc -o CMakeFiles/cmTryCompileExec961681416.dir/testCCompiler.c.o
-c
/home/gyorgy/Workspace/CPP_Tests/src/cmake_test/CMakeFiles/CMakeTmp/testCCompiler.c
Linking C executable cmTryCompileExec961681416
/usr/bin/cmake -E cmake_link_script
CMakeFiles/cmTryCompileExec961681416.dir/link.txt --verbose=1
/usr/bin/cc -rpath /usr/local/openblas/lib
CMakeFiles/cmTryCompileExec961681416.dir/testCCompiler.c.o -o
cmTryCompileExec961681416 -rdynamic
cc: error: unrecognized command line option ‘-rpath’
make[1]: *** [cmTryCompileExec961681416] Error 1
make[1]: Leaving directory
`/home/gyorgy/Workspace/CPP_Tests/src/cmake_test/CMakeFiles/CMakeTmp'
make: *** [cmTryCompileExec961681416/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
-- Configuring incomplete, errors occurred!
See also "/home/gyorgy/Workspace/CPP_Tests/src/cmake_test/CMakeFiles/CMakeOutput.log".
See also "/home/gyorgy/Workspace/CPP_Tests/src/cmake_test/CMakeFiles/CMakeError.log".
I apologize to everyone... The error resulted from me making a mistake a while ago.
The answer in short is that I had the following incorrect line in my .bashrc file:
export LDFLAGS="-rpath /usr/local/openblas/lib "$LDFLAGS
and CMake has the following line in the CMakeCommonLanguageInclude.cmake module:
set (CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS_INIT} $ENV{LDFLAGS}"
Which obviously resulted in setting the CMAKE_EXE_LINKER_FLAGS to -rpath /usr/local/openblas/lib and
hence the error. After changing the .bashrc file to:
export LDFLAGS="-Wl,-rpath=/usr/local/openblas/lib "$LDFLAGS
the issue was resolved.
I have no idea why this didn't come up with the GUI version though :-)
I probably messed up the .bashrc file by reading an OSX forum or something.
Anyway thanks for the answers!

Configure an autotools project with Clang sanitizers in a static lib configuration?

EDIT: If its TLDR, just skip to the bottom. Its where I ask: How do I configure an autotools project to use a static library?
I'm working with a couple of open source libraries, and I'm trying to run their test suite under Clang's sanitizers. To run under Clang sanitizers, we need to (1) specify some options, and (2) link static libraries from Clang's Compiler-RT as required. Note: there are no dynamic libraries or shared objects.
Setting the options is easy:
export DYLD_FALLBACK_LIBRARY_PATH=/usr/local/lib/clang/3.3/lib/darwin/
export CC=/usr/local/bin/clang
export CXX=/usr/local/bin/clang++
export CFLAGS="-g3 -fsanitize=address -fsanitize=undefined"
export CXXFLAGS="-g3 -fsanitize=address -fsanitize=undefined -fno-sanitize=vptr"
./configure
However, this will generate some archive warnings (when AR is run) and link errors (when LD is run) with undefined symbols. The message will be similar to:
libjpeg.a(jmemmgr.o): In function `do_sarray_io':
/home/jwalton/jpeg-6b/jmemmgr.c:695: undefined reference to
`__ubsan_handle_type_mismatch'
/home/jwalton/jpeg-6b/jmemmgr.c:695: undefined reference to
`__ubsan_handle_type_mismatch'
/home/jwalton/jpeg-6b/jmemmgr.c:696: undefined reference to
`__ubsan_handle_type_mismatch'
I know the libraries that need to be linked. For the sanitizers that I use, they are libclang_rt.asan_osx.a and libclang_rt.ubsan_osx.a (or libclang_rt.full-x86_64.a and libclang_rt.ubsan-x86_64.a on Linux).
To supply the libraries, I then export the following. Note: it is LIBS, and not LDLIBS as expected by most other make related tools.
export LIBS="/usr/local/lib/clang/3.3/lib/darwin/libclang_rt.asan_osx.a \
/usr/local/lib/clang/3.3/lib/darwin/libclang_rt.ubsan_osx.a"
This results in a configure problem of:
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
...
Looking at config.log, it looks like two problems are occurring. First, the path is being butchered by changing from /usr/local/... to /Users/jwalton/.... And second, the filename is being butchered by changing from a static lib to a dynamic lib:
configure:3346: ./conftest
dyld: Library not loaded: /Users/jwalton/clang-llvm/llvm-3.3.src/Release+Asserts/lib/clang/3.3/lib/darwin/libclang_rt.asan_osx_dynamic.dylib
Referenced from: /Users/jwalton/libpng-1.6.7/./conftest
Reason: image not found
In another attempt, I tried using LDFLAGS:
export LDFLAGS="-L/usr/local/lib/clang/3.3/lib/darwin/"
export LIBS="libclang_rt.asan_osx.a libclang_rt.ubsan_osx.a"
That results in a similar error:
configure: error: in `/Users/jwalton/libpng-1.6.7':
configure: error: C compiler cannot create executables
And config.log:
configure:3209: /usr/local/bin/clang -g3 -fsanitize=address -fsanitize=undefined -L/usr/local/lib/clang/3.3/lib/darwin/ conftest.c libclang_rt.asan_osx.a libclang_rt.ubsan_osx.a >&5
clang: error: no such file or directory: 'libclang_rt.asan_osx.a'
clang: error: no such file or directory: 'libclang_rt.ubsan_osx.a'
And dropping the lib prefix and .a suffix from the LIBS results in:
configure:3209: /usr/local/bin/clang -g3 -fsanitize=address -fsanitize=undefined -L/usr/local/lib/clang/3.3/lib/darwin/ conftest.c clang_rt.asan_osx clang_rt.ubsan_osx >&5
clang: error: no such file or directory: 'clang_rt.asan_osx'
clang: error: no such file or directory: 'clang_rt.ubsan_osx'
And adding the -l to LIBS results in:
configure:3335: /usr/local/bin/clang -o conftest -g3 -fsanitize=address -fsanitize=undefined
-L/usr/local/lib/clang/3.3/lib/darwin/ conftest.c -lclang_rt.asan_osx -lclang_rt.ubsan_osx >&5
configure:3339: $? = 0
configure:3346: ./conftest
dyld: could not load inserted library: /Users/jwalton/libpng-1.6.7/./conftest
./configure: line 3348: 38224 Trace/BPT trap: 5 ./conftest$ac_cv_exeext
Finally, the -L argument is valid:
$ ls /usr/local/lib/clang/3.3/lib/darwin/
libclang_rt.10.4.a libclang_rt.ios.a
libclang_rt.asan_osx.a libclang_rt.osx.a
libclang_rt.asan_osx_dynamic.dylib libclang_rt.profile_ios.a
libclang_rt.cc_kext.a libclang_rt.profile_osx.a
libclang_rt.cc_kext_ios5.a libclang_rt.ubsan_osx.a
libclang_rt.eprintf.a
After all the background: how do I configure an autotools project to use a static library?
Bonus points: why has something so easy been made so difficult?
You need to add -fsanitize flags to LDFLAGS as well.
Shipping versions of GNU libtool do not pass -fsanitize=... arguments to the linker. You will need to update libtool with the patch from http://savannah.gnu.org/patch/?8775 Specifically:
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 0c40da0..b99b0cd 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
## -5362,10 +5362,11 ## func_mode_link ()
# -O*, -g*, -flto*, -fwhopr*, -fuse-linker-plugin GCC link-time optimization
# -specs=* GCC specs files
# -stdlib=* select c++ std lib with clang
+ # -fsanitize=* Clang memory and address sanitizer
-64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
-t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|#*|-tp=*|--sysroot=*| \
-O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*| \
- -specs=*)
+ -specs=*|-fsanitize=*)
func_quote_for_eval "$arg"
arg=$func_quote_for_eval_result
func_append compile_command " $arg"
As for getting libtool to accept a static library, you should be able to just include the full path to the static library on the command line, or you can use options like -L/usr/local/lib/clang/3.3/lib/darwin/ -lclang_rt.ubsan_osx. However, cfe should take care of the library magic for you once libtool tells it to use -fsanitize=... for linking.
As for the undefined symbol issue, if you are linking C++ objects, then you must use clang++ instead of clang. Otherwise you can get error such as:
/bin/bash libtool --tag=CC --mode=link clang-3.6 ... -fsanitize=undefined -o freeswitch ...
libtool: link: clang-3.6 ... -fsanitize=undefined -o .libs/freeswitch ./.libs/libfreeswitch.so ...
./.libs/libfreeswitch.so: undefined reference to `__ubsan_vptr_type_cache'
./.libs/libfreeswitch.so: undefined reference to `__ubsan_handle_dynamic_type_cache_miss'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
In the above case, the atrocious libtool used clang instead of clang++ because automake thought that you wanted to link a set of C objects (it does not understand that linking a libtool archive (libfreeswitch.la) using C++ means that a C++ linker is needed (note the --tag=CC). See also https://lists.debian.org/debian-mentors/2003/06/msg00004.html.
To work around this issue, follow the instructions at https://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Libraries.html and add a (dummy/real) C++ source to your sources in your Makefile.am:
SUBDIRS = sub1 sub2 …
lib_LTLIBRARIES = libtop.la
libtop_la_SOURCES =
# Dummy C++ source to cause C++ linking.
nodist_EXTRA_libtop_la_SOURCES = dummy.cxx
libtop_la_LIBADD = \
sub1/libsub1.la \
sub2/libsub2.la \
…

Problem with linking against libexpat in Boost Build - for building graphml

On my system, expat is located at
/usr/include/expat.h
/usr/include/expat_external.h
/usr/lib/libexpat.1.5.0.dylib
/usr/lib/libexpat.1.dylib
/usr/lib/libexpat.dylib
/usr/lib/libexpat.la
So I export the required variables for boost to build graphml
export EXPAT_INCLUDE=/usr/include
export EXPAT_LIBPATH=/usr/lib
then I run (where $DIR and $BOOST generate the paths I want the includes and libs to go)
./configure --includedir=$DIR/$BOOST --libdir=$DIR/$BOOST/lib \
--with-libraries=test,graph
I get this error:
ld: library not found for -lexpat collect2: ld returned 1 exit status
which boost says is caused by the line:
g++ -dynamiclib -install_name "libboost_graph-mt-1_35.dylib" -L"/usr/lib"
-o "bin.v2/libs/graph/build/darwin/release/macosx-version-10.4/threading-multi/libboost_graph-mt-1_35.dylib"
"bin.v2/libs/graph/build/darwin/release/macosx-version-10.4/threading-multi/read_graphviz_spirit.o"
"bin.v2/libs/graph/build/darwin/release/macosx-version-10.4/threading-multi/graphml.o"
-lexpat -isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -Wl,-dead_strip -no_dead_strip_inits_and_terms
I don't get how it's not finding the expat library with -L"/usr/lib" and -lexpat as arguments? My understanding is that /usr/lib/libexpat.dylib is exactly referenced as -L"/usr/lib" and -lexpat.
The Jamfile for building graphml is here. If EXPAT_INCLUDE and EXPAT_LIBPATH aren't set then it warns you (lines 39-41 of jamfile)
warning: Graph library does not contain optional GraphML reader.
note: to enable GraphML support, set EXPAT_INCLUDE and
note: directories containing the Expat headers and libraries, respectively.
Another update:
I don't see an .so or a .a file in your list of where EXPAT is... doesn't that seem a bit strange? Normally it will create an alias for the library name
for example /usr/lib/libblah.so -> /usr/lib/libblaah.so.1.2
Is dynalib some Macintoshism (I don't use Macs much)
is .la the static version extension on this platform?
Update:
The quotes around the path seem troublesome...
-L"/usr/lib"
Try changing this to -L/usr/lib and -L /usr/lib
Older stuff:
The directive for the linker to include paths during the link step is -L. You need to look for some linker flags to update to include -L path_to_expat. I don't think the linker pays any attention to LD_LIBRARY_PATH. I am not sure what documentation you have read to set EXPAT_INCLUDE or EXPAT_LIBPATH.

Resources