I am trying to use address sanitizer with g++ and during the build it produces the following linker command, which produces the error g++: error: cannot specify -static with -fsanitize=address
I don't understand what this means, so any help is appreciated. The g++ version is g++ (GCC) 8.3.0 20190222 (Cray Inc.).
g++ -g -fsanitize=address CMakeFiles/pisa.dir/src/Alphabet.cpp.o {more .o files} -o pisa -L/global/homes/e/esaliya/sali/git/bitbucket/combinatorial-blas-2.0/CombBLAS/_install/lib -Wl,-rpath,/global/homes/e/esaliya/sali/git/bitbucket/combinatorial-blas-2.0/CombBLAS/_install/lib -lCombBLAS -lGraphGenlib -lUsortlib
Related
From the research I have done, the problem seems to be with clang. If that is the case, how would I fix this on a Mac? Would switching to Ubuntu/Linux be a better option?
I'm not sure if it is relevant, but my professor is having us code using C syntax using g++ and saving our files as '.cpp' before we dive into C++.
Warning:
clang: warning: argument unused during compilation: '-ansi'
[-Wunused-command-line-argument]
Makefile:
CC = g++
calendar: main.o calendar.o appt.o day.o time.o
$(CC) main.o calendar.o appt.o day.o time.o -g -ansi -Wall -o calendar.out
%.o: %.cpp
$(CC) -Wall -c $<
You are correct in believing that this warning is issued by clang++ in these
circumstances and not by g++, and that you see it on your Mac because g++ is
really clang++.
The GCC option -ansi is meaningful for compilation and not meaningful
for linkage. Clang is warning you because you are passing it in your linkage recipe:
$(CC) main.o calendar.o appt.o day.o time.o -g -ansi -Wall -o calendar.out
where it is ineffective, and not passing it to your compilation recipe:
$(CC) -Wall -c $<
The wording of the diagnostic is misleading since it is provoked here
precisely by the absence of compilation. Nevertheless, it does
draw attention to a mistake on your part. Remove -ansi from your linkage recipe and add it to your compilation recipe.
I'm building a shared library and an application using that lib on Cygwin. With GCC CMake creates a .dll.a to use when linking. Switching to clang I get
[ 34%] Built target xxx_shared
make[2]: *** No rule to make target 'src/libxxx.dll.a', needed by 'xxx.exe'. Stop.
Is this a bug in the clang CMake extension?
I'm using cmake --version 3.3.2
Yes, it seems to be a bug in CMake. Running make VERBOSE=1 reveals that with GCC:
/usr/bin/c++.exe -g -shared -Wl,--enable-auto-import -o XXX -Wl,-Bstatic -lm -Wl,-Bdynamic -lstdc++ -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32
while with clang:
/usr/bin/clang++ -fPIC -g -shared -o XXX -Wl,-Bstatic -lm -Wl,-Bdynamic -lstdc++ -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32
So it seems that somehow clang++ does not get the -Wl,--enable-auto-import flag. Manually running the corrected clang++ command correctly creates the expected .dll.a allowing the rest of the build to proceed as expected.
Haven't figured out why this happens yet, though. At this point I can't decipher CMakes platform extensions, which seems to set this for GCC.
Update: I've reported this here.
I'm trying to link a really simple GLES2 & EGL program using g++ 4.9.1, on a Ubuntu Trusty system. I'm using the mesa libraries.
I'm getting linker errors for EGL functions:
test.cpp:(.text+0x342): undefined reference to `eglGetDisplay'
test.cpp:(.text+0x389): undefined reference to `eglInitialize'
test.cpp:(.text+0x40f): undefined reference to `eglCreateContext'
test.cpp:(.text+0x458): undefined reference to `eglCreatePbufferSurface'
test.cpp:(.text+0x49e): undefined reference to `eglMakeCurrent'
I am compiling test.cpp with
g++ -std=c++0x -Wall -Werror -lEGL -lGLESv2 -o test test.cpp
I've tried switching the order of libraries, which sometimes matters, but I get the same problem. Is there a library I'm missing here?
I've run readelf -Ws /usr/lib/x86_64-linux-gnu/mesa-egl/libEGL.so and all of the required functions are defined.
You should put libraries to the end of a command line
g++ -std=c++0x -Wall -Werror -o test test.cpp -lEGL -lGLESv2
I managed to fix this by compiling the C++ file to an object file, and then linking as a separate step. I'm not sure why this works, when the one-line compilation doesn't.
g++ -std=c++0x -Wall -Werror -c -o test.o test.cpp
g++ -o test test.o -lGLESv2 -lEGL
I've put the question to the community to try to figure out why: Single-command compile and link fails, separate steps work
My code is as simple as this:
#include <mpi.h>
int main(int argc, char**args) {
MPI_Init(&argc, &args);
int mpiSize;
int mpiRank;
MPI_Comm_size(MPI_COMM_WORLD, &mpiSize);
MPI_Comm_rank(MPI_COMM_WORLD, &mpiRank);
MPI_Finalize();
}
I first compile it to object file:
g++ -c src/mpitest.cpp -o src/mpitest.o
Then I can easily use mpicxx:
mpicxx src/mpitest.o -o mpi
But I want to use g++ instead, because It's easier for automake, so I tried:
mpicxx src/mpitest.o -o mpi -show
It prints out:
g++ src/mpitest.o -o mpi -I/usr/local/include -L/usr/local/lib -L/usr/local/lib -lmpichcxx -lmpich -lopa -lpthread -lrt
And yes, that command actually does the same thing successfully. However, If I tried to change it to (I just change the object file and output to the end):
g++ -I/usr/local/include -L/usr/local/lib -L/usr/local/lib -lmpichcxx -lmpich -lopa -lpthread -lrt src/mpitest.o -o mpi
Which is what automake does when it adds LDFLAGS, the g++ start complaining...
src/mpitest.o: In function `main':
..src/mpitest.cpp:5: undefined reference to `MPI_Init'
../src/mpitest.cpp:8: undefined reference to `MPI_Comm_size'
../src/mpitest.cpp:9: undefined reference to `MPI_Comm_rank'
../src/mpitest.cpp:10: undefined reference to `MPI_Finalize'
collect2: ld returned 1 exit status
What happens with g++ ? I couldn't figure out. Please enlighten me. Why the order here matter at all ? What is the proper way to do what I want from the beginning ?
Thanks a lot
p/s : g++ --version
g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3
mpi is mvapich2
I didn't really remember, maybe since version 4, library to link with -l must be passed after all source and object files.
I've very simple example, and can't correctly build it, I was using next arguments:
g++ -lpq -libpqxx -Wall -o "pg" "pg.cpp" (in dir: /home/user)
/usr/lib/gcc/i586-suse-linux/4.5/../../../../i586-suse-linux/bin/ld: cannot find -lpq
collect2: ld returned 1 exit status
or
returned 1 exit status g++ -libpqxx -Wall -o "pg" "pg.cpp"
(in dir: /home/user)
/usr/lib/gcc/i586-suse-linux/4.5/../../../../i586-suse-linux/bin/ld:
cannot find -libpqxx collect2: ld
but everywere had error.
libpqxx succ installed
#lisuse-home:~> locate libpqxx | grep /lib/
/usr/lib/libpqxx-3.1.so
/usr/lib/libpqxx.la
/usr/lib/libpqxx.so
/usr/lib/pkgconfig/libpqxx.pc
g++ filename.cpp -o target -lpqxx
-lpqxx should take care of -lpq. If for some reason it does not find pq, find pq and put it in the same directory as pqxx.
compiling g++ -libpqxx-3.1 -Wall -c "%f"
building g++ -Wall -o "%e" /usr/lib/libpqxx-3.1.so "%f"