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
Related
If I compile in two stages, using a particular language standard:
g++ -std=c++2a -c file1.cpp #compile source files
g++ -std=c++2a -c file2.cpp
g++ -std=c++2a file1.o file2.o -o program #link 'em
...can I leave the -std=c++2a out of the link command, or is it sometimes needed?
Version is gcc 10.
I guess you are compiling on Linux with a recent GCC. Be sure to read more about C++ and about your particular compiler (i.e. GCC 9 is not the same as GCC 10). Check with g++ --version what it is.
In practice you want to compile with warnings and debug information (in DWARF for GDB inside your ELF object files and executables), so use
g++ -std=c++2a -Wall -Wextra -g -c file1.cpp
and likewise for file2.cpp
Later (once your program is correct enough, e.g. has few bugs) you could want to ask the compiler to optimize it. So you could use
g++ -std=c++2a -Wall -Wextra -O3 -g -c file1.cpp
Practically speaking, you'll configure your build automation tool (e.g. GNU make or ninja) to run your compilation commands.
In rare cases, you could want to use link time optimizations. Then you need to both compile and link with g++ -std=c++2a -Wall -Wextra -O3 -g -flto and perhaps other options.
Be aware that link time optimization could almost double your build time.
You could also be interested by static analysis options of GCC 10 (or even by writing your own static analysis using GCC plugins).
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
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.
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.