clang: error: -lm: 'linker' input unused while compiling on MacOSX - c++

I am trying to compile a program mafTools on MacOSX using gnu make. I get the following error:
cd mafExtractor && make all
clang -std=c99 -stdlib=libstdc++ -O3 -c -O3 -Wall -Werror --pedantic -funroll-loops -DNDEBUG -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -I ../../sonLib/lib -I ../inc -I ../external src/mafExtractorAPI.c -o src/mafExtractorAPI.o.tmp -lm
This gives the error:
clang: error: -lm: 'linker' input unused [-Werror,-Wunused-command-line-argument]
make[1]: \*** [src/mafExtractorAPI.o] Error 1
make: \*** [mafExtractor.all] Error 2
I looked at similar errors but couldn't fix it. Any help will be much appreciated. Thanks!
This is the package: https://github.com/dentearl/mafTools/tree/master/mafExtractor
Everything else here compiled successfully.
This is the makefile:
https://github.com/dentearl/mafTools/blob/master/mafExtractor/Makefile
Thanks a bunch.

Your clang commaand includes the -c option which means you do not want to link and resolve external references, you just want to produce an unlinked object file.
Your -lm option says you want to link with the maths library.
Basically, the aforementioned options are incompatible - you cannot both link with the math library and not link.
TLDR; Remove -lm

Related

How to fix "Unexpected token... for architecture x86_64" error when running makefile

I'm trying to install HLA-LA on my 2016 MacBookPro (running Mojave 10.14.3) but I've been having issues compiling the makefile. I've installed all the dependencies, added the bamtools and boost paths as the README describes, and added CFLAGS to specify c++11. Still, when I run the makefile I get the following error:
$ make all
/usr/local/Cellar/gcc/8.3.0/bin/g++-8 -I/usr/local/Cellar/boost/1.68.0_1/include -I/usr/local/Cellar/bamtools/2.5.1/include/bamtools -I/usr/local/Cellar/bamtools/2.5.1/src -std=c++11 -ggdb -O2 -fopenmp -std=gnu++0x -fstack-protector-all HLA-LA.cpp -c -o ../obj/HLA-LA.o;
/usr/local/Cellar/gcc/8.3.0/bin/g++-8 -I/usr/local/Cellar/boost/1.68.0_1/include -I/usr/local/Cellar/bamtools/2.5.1/include/bamtools -I/usr/local/Cellar/bamtools/2.5.1/src -std=c++11 -ggdb -O2 -fopenmp -std=gnu++0x -fstack-protector-all ../obj/Edge.o ../obj/Graph.o ../obj/GraphAndEdgeIndex.o ../obj/Node.o ../obj/HaplotypePanel.o ../obj/simpleGraphSimulator.o ../obj/LocusCodeAllocation.o ../obj/simulator.o ../obj/readSimulator.o ../obj/trueReadLevels.o ../obj/processBAM.o ../obj/protoSeeds.o ../obj/oneRead.o ../obj/oneReadPair.o ../obj/oneReadPairwithSeedChains.o ../obj/alignerBase.o ../obj/alignmentContext.o ../obj/extensionAligner.o ../obj/BWAmapper.o ../obj/Bowtie2mapper.o ../obj/statistics.o ../obj/VirtualNWUnique.o ../obj/PRGContigBAMAlignment.o ../obj/verboseSeedChain.o ../obj/HLATyper.o ../obj/pathFinder.o ../obj/linearALTs.o ../obj/oneExonPosition.o ../obj/seedChain.o ../obj/Utilities.o ../obj/HLA-LA.o -o ../bin/HLA-LA -L/usr/local/Cellar/boost/1.68.0_1/lib -L/usr/local/Cellar/bamtools/2.5.1/lib64 -L/usr/local/Cellar/zlib/1.2.11/lib -lboost_random -lboost_filesystem -lboost_system -lbamtools -lz -lboost_serialization;
collect2: fatal error: ld terminated with signal 11 [Segmentation fault: 11]
compilation terminated.
ld: unexpected token: !tapi-tbd-v3 file '/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/libSystem.tbd' for architecture x86_64
make: *** [HLA-LA] Error 1
I've seen other people with similar errors, but the recommended fixes havent worked. I've also tried specifying CLT via the path: /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/lib/ but it doesn't change the outcome at all. I read some thread that suggested it could be an ld issue but I'm not sure how I can fix that? Here are my specs:
macOS: 10.14.3-x86_64
CLT: 10.1.0.0.1.1539992718
Xcode: 10.1

GCC link error "__wcsrtombs: Zusicherung »data.__outbuf[-1] == '\0'« nicht erfüllt"

Based on this question i get error message...
collect2: fatal error: ld terminated with signal 6 [Abgebrochen]
compilation terminated.
/usr/bin/ld: ld: wcsrtombs.c:99: __wcsrtombs: Zusicherung »data.__outbuf[-1] == '\0'« nicht erfüllt.
...when trying to link a shared library but setting LC_ALL=C doesn't solve the problem in my case!
I'm on a german Linux Mint 17.3 (Cinnamon). My project gets build with CMake 2.8.4 (native repository). Compiler is g++ 5.3.1 (Ubuntu xenial repository).
Compile command for all sources looks like this:
/usr/bin/c++ -D_USE_MATH_DEFINES -Dfluag_EXPORTS -g -fPIC -I/home/youka/Schreibtisch/Projekte/FLuaG/build/src -I/usr/include/luajit-2.0 -I/usr/local/include -Wall -Wextra -pedantic -Wredundant-decls -Wunreachable-code -Wmissing-include-dirs -Wswitch-enum -Wno-missing-field-initializers -std=c++11 -mmmx -o CMakeFiles/fluag.dir/main/FLuaG.cpp.o -c /home/youka/Schreibtisch/Projekte/FLuaG/src/main/FLuaG.cpp
Link command which causes error:
/usr/bin/c++ -fPIC -g -shared -Wl,-soname,libfluag.so -o libfluag.so CMakeFiles/fluag.dir/lualibs/utf8.cpp.o CMakeFiles/fluag.dir/lualibs/mathx.cpp.o CMakeFiles/fluag.dir/lualibs/regex.cpp.o CMakeFiles/fluag.dir/lualibs/png.cpp.o CMakeFiles/fluag.dir/lualibs/geometry.cpp.o CMakeFiles/fluag.dir/lualibs/tablex.cpp.o CMakeFiles/fluag.dir/lualibs/filesystem.cpp.o CMakeFiles/fluag.dir/lualibs/tgl.cpp.o CMakeFiles/fluag.dir/lualibs/font.cpp.o CMakeFiles/fluag.dir/interfaces/vapoursynth.cpp.o CMakeFiles/fluag.dir/interfaces/public.cpp.o CMakeFiles/fluag.dir/main/FLuaG_image.cpp.o CMakeFiles/fluag.dir/main/FLuaG.cpp.o -Wl,-Bstatic -lluajit-5.1 -Wl,-Bdynamic -lGLEW /usr/local/lib/libglfw3.a -lGL -lpng -lz
Compiling this project with MinGW64 on Windows Vista works. Release or Debug build, with or without SIMD, etc. makes no difference.
The error message tells me that in file wcsrtombs.c (linked libgcc), line 99, memory comparison data.__outbuf[-1] == '\0' isn't ensured... which pretty confuses me.
After setting the system language to english, the error message suddenly made sense:
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libluajit-5.1.a(ljamalg.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libluajit-5.1.a: error adding symbols: Bad value
The problem was -Wl,-Bstatic -lluajit-5.1. I linked to the .a file which was expected to be a static library by CMake. Changing to .so solved the problem.

gcc error wrong ELF class: ELFCLASS64, despite haveing -m64 flag

I have been trying to build a library in solaris using gcc, and keep on hitting wrong ELF class: ELFCLASS64 error. I have googled and found out this is due to trying to link with a 32 bit file which compiling as a 64 bit library. But I have made sure that I build rakesh.o as a 64 bit using -m64 compiler option.
/rdcomb/run/pd/gcc/32-bit/4.4.1/bin/g++ -Wall -W -Wunreachable-code -Winline -Wshadow -Weffc++ -Wfloat-equal -Wunsafe-loop-optimizations -Wcast-qual -Wdisabled-optimization -shared -fPIC -m64 -c -DDEBUG -I../include -I/home/radha/ali/trunk/src/top//src/ -I../../../top/include -g -o Suni386/dll/rakesh.o rakesh.cpp
xmake: /home/radha/ali/trunk/src/tools/bin/Suni386/xlink -g -o Suni386/dll/rakesh -p../../../top/gtcpp/Suni386/dll -lgtcpp -lsocket -lnsl Suni386/dll/rakesh.o
ld: fatal: file Suni386/dll/rakesh.o: wrong ELF class: ELFCLASS64
ld: fatal: file processing errors. No output written to Suni386/dll/rakesh
collect2: ld returned 1 exit status
/rdcomb/run/pd/gcc/32-bit/4.4.1/bin/g++ -g -o Suni386/dll/rakesh -L../../../top/gtcpp/Suni386/dll Suni386/dll/rakesh.o -lgtcpp -lsocket -lnsl
xmake: /home/radha/ali/trunk/src/tools/bin/Suni386/xlink: error 1 (0x1)
What am I doing wrong here? Is it due to some compiler flag that using or missing?
You must provide the -m64 flag for the linker as well so it knows what type of binaries to expect.

Compile error with RcppArmadillo and R 3.1.3 and Mac Yosemite

I have recently installed R 3.1.3. I am using a Mac with Yosemite system and my Xcode is of version 6.2.
After I source the CPP file using sourceCpp("try.cpp"), I get the following error. My try.cpp file has
#include <RcppArmadillo.h>
#include <math.h>
The error is below in R
ld: warning: directory not found for option '-L/usr/local/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2'
ld: library not found for -lquadmath
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [sourceCpp_15736.so] Error 1
clang++ -arch x86_64 -ftemplate-depth-256 -I/Library/Frameworks/R.framework/Resources/include -I/usr/local/include -I/usr/local/include/freetype2 -I/opt/X11/include -I"/Library/Frameworks/R.framework/Versions/3.1/Resources/library/Rcpp/include" -I"/Library/Frameworks/R.framework/Versions/3.1/Resources/library/RcppArmadillo/include" -fPIC -mtune=core2 -O3 -c CAR.cpp -o CAR.o
clang++ -arch x86_64 -ftemplate-depth-256 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module - multiply_defined suppress -L/Library/Frameworks/R.framework/Resources/lib - L/usr/local/lib -o sourceCpp_15736.so CAR.o -L/Library/Frameworks/R.framework/Resources/lib -lRlapack -L/Library/Frameworks/R.framework/Resources/lib -lRblas -L/usr/local/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2 -lgfortran -lquadmath -lm -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework -Wl,CoreFoundation
Error in sourceCpp("~/RA2015/Code/BYMCAR/CAR.cpp") :
Error 1 occurred building shared library.
WARNING: The tools required to build C++ code for R were not found.
Please install Command Line Tools for XCode (or equivalent).
I have installed the command line tools for Xcode, my gfortran version is 4.9.0
But when I type
gfortran --version
It has the following error:
gfortran: warning: couldn’t understand kern.osversion ‘14.1.0
When I use R 3.1.2, I did not encounter this problem before!
Any help is appreciated!
After some finding I find a solution online.
If you have same problem with me, just type
curl -O http://r.research.att.com/libs/gfortran-4.8.2-darwin13.tar.bz2
sudo tar fvxz gfortran-4.8.2-darwin13.tar.bz2 -C /
on the terminal and sourceCpp can run smoothly.
A detailed explanation can be found at [http://www.thecoatlessprofessor.com/programming/rcpp-rcpparmadillo-and-os-x-mavericks-lgfortran-and-lquadmath-error]

How can I fix libstdc++ (or does it need fixing?)

I have been trying to install HEALPix over the last few days on my iMac and I am at something of a dead end as to how to proceed. When I run the necessary make command, I am told that the file string does not exist.
# compiling Healpix_cxx/syn_alm_cxx.cc
cd /Users/keir/Software/Healpix_3.11/src/cxx/build.osx/Healpix_cxx && g++ -I/usr/local
/include -I/Users/keir/Software/Healpix_3.11/src/cxx/c_utils -I/Users/keir/Software
/Healpix_3.11/src/cxx/libfftpack -I/Users/keir/Software/Healpix_3.11/src/cxx/libsharp
-I/Users/keir/Software/Healpix_3.11/src/cxx/cxxsupport -I/Users/keir/Software/
Healpix_3.11/src/cxx/Healpix_cxx -I/Users/keir/Software/Healpix_3.11/src/cxx/alice
-I/Users/keir/Software/Healpix_3.11/src/cxx/build.osx -Wall -Wextra -Wstrict-aliasing=2
-Wundef -Wshadow -Wwrite-strings -Wredundant-decls -Woverloaded-virtual -Wcast-qual
-Wcast-align -Wpointer-arith -Wold-style-cast -Wno-unknown-pragmas -Wfatal-errors -g
-fopenmp -fPIC -O2 -ffast-math -fomit-frame-pointer -ansi -fdata-sections
-ffunction-sections -c /Users/keir/Software/Healpix_3.11/src/cxx/Healpix_cxx/
syn_alm_cxx.cc
In file included from /Users/keir/Software/Healpix_3.11/src/cxx/Healpix_cxx/
syn_alm_cxx.cc:2:0:
/Users/keir/Software/Healpix_3.11/src/cxx/cxxsupport/error_handling.h:35:18: fatal
error: string: No such file or directory
#include <string>
^
compilation terminated.
make[1]: *** [/Users/keir/Software/Healpix_3.11/src/cxx/build.osx/Healpix_cxx/syn_alm_cxx.o] Error 1
I have had a look and it certainly does as is the whole of the libstdc++ library (I think). I have tried many solutions including re-installing Xcode and its Command Line Tools and trying various other versions of gcc (4.8, 4.9, 5.0 and a 4.9 copy from homebrew) - none of which solve the problem.
I have created a test file 'foo.cpp' with just #include <string> in it and this will still not compile even if I specify a directory for string with the -I tag, because it then can't find more headers that string depends on. It seems to me that libstdc++ isn't installed in the correct place? Or the '#include' command isn't looking in the right places? Do you have an idea as to how to fix this problem?