I have 2 shared object libs and one executable.
1 of the libs that I compile has linkage error: Undefined _cxa_pure_virtual.
Why?
Usually we do not need to implement it. Any Ideas?
If I implement it both the libs compile and link OK, but the application that links to both has same linkage issue?
The lib in question is a C++ library and the __cxa_pure_virtual is needed by the C++ runtime. Suggest that you try first linking with g++ command instead of gcc.
Read more under this question: What is the purpose of cxa pure virtual
Related
I'm compiling a static library, let's call it static.a which is later linked by a shared library shared.so and by a final executable binary file (shared.so uses just a few functions from static.a maybe later this can be further splited). If I try to compile it suing gcc 7.4 I get this linker error:
/usr/bin/ld: ../../static.a(file.cpp.o): relocation R_X86_64_TPOFF32 against symbol `_ZGVZN6spdlog7details2os9thread_idEvE3tid' can not be used when making a shared object; recompile with -fPIC
I decided to try also gcc 9.1 and this error doesn't apear anymore.
should I always use -fpic when building a static library that will be used in a shared library? I know fpic adds some overhead.
how come a newer version of gcc can relocate the symbols of the static.a inside the shared library? Is this safe?
Thank you.
All code in shared library should be compiled with -fPIC so your static library should too. -fPIC does indeed introduce an overhead but to a large extent it can be mitigated with options like -fno-semantic-interposition and/or -fvisibility=hidden.
The error that you see is coming from the linker so it seems that the newer GCC does not use the problematic relocation. You can inspect the generated assembly to find out the difference in generated code.
I have a third party C library, both in static format (.lib) and in dynamic format (.dll) with its own import library (.lib). It is MKL (Intel Math Kernel Library). I am working with cygiwn 64 on Windows 7.
In brief, I am trying to get a compiler born to work in POSIX world to talk to a lib compiled in Windows world, assuming that is vene possible.
I want to link that library as part of a C++ executable I am compiling with g++ in cygwin and I am trying to link with the DLL using the import library.
My command line, where I omit the file paths for simplicity, results in a undefined reference error.
$ g++ main.obj mkl_intel_lp64_dll.lib mkl_sequential_dll.lib mkl_core_dll.lib -o paper.exe
mkl_intel_lp64_dll.lib: blah, blah, blah: undefined reference to `__GSHandlerCheck'
... and many other similar errors
Anybody knows if it is possible, and, if yes, how to do it?
Thanks
Try rearranging the arguments to g++ so that main.obj precedes the libraries it references.
I am trying to compile OpenVDB, but I get a linker error telling me:
"cannot find -ldl"
That is the only linker I am getting. I have no idea what library -ldl belongs to. The makefile doesn't help either, so I'm guessing it is a standard lib. I am using Mingw-w64 on windows.
The -ldl is a linker option to link to libdl library. This library is used to perform dynamic library loading (.dll in Window's world) through dlopen, dlsym... functions.
Since this library is not available on Windows, I think you could remove the -ldl from your makefile.
Since Window's equivatent functions are accessible by kernel.lib, you do not need to add specific instruction in makefile.
I've just installed trilinos 11.0.3 and now I'm trying to compile my first application using cmake.
The file I'm trying to compile is here
http://code.google.com/p/trilinos/wiki/EpetraSimpleVector
The first command cmake seems to work although I get the following warnings (just in case its relevant) for each trilinos package:
CMake Warning (dev) at /home/giorgos/Documents/TRILINOS/lib/cmake/Trilinos/
TrilinosTargets.cmake:208 (ADD_LIBRARY):
ADD_LIBRARY called with SHARED option but the target platform does not
support dynamic linking. Building a STATIC library instead. This may lead
to problems.
Other than that it seems that the location of trilinos includes and libraries have been found correctly
However the make command produce a list of similar errors such as :
/home/giorgos/Documents/mpi_tests/trilinos_test/test1/src/teuchos_test.cpp:11:
undefined reference to `Epetra_SerialComm::Epetra_SerialComm()'
/home/giorgos/Documents/mpi_tests/trilinos_test/test1/src/teuchos_test.cpp:16:
undefined reference to `Epetra_Map::Epetra_Map(int, int, Epetra_Comm const&)'
/home/giorgos/Documents/mpi_tests/trilinos_test/test1/src/teuchos_test.cpp:19:
undefined reference to `Epetra_Vector::Epetra_Vector(Epetra_BlockMap const&, bool)'
/home/giorgos/Documents/mpi_tests/trilinos_test/test1/src/teuchos_test.cpp:20:
undefined reference to `Epetra_Vector::Epetra_Vector(Epetra_BlockMap const&, bool)'
Any idea what's going on here?
(I named the source file teuchos_test.cpp because first I tried to compile some code from the teuchos package, However I was receiving similar errors as above)
Thank you
Giorgos
You can use cmake or make to build your program with Trilinos. I refer you to the official tutorial website here, which provides detailed explanations for both methods.
I haven't been able to compile the trilinos examples with cmake but I was able to do so by linking everything my self. For the example that gives me the above errors I did the following
g++ -o teuchos_test teuchos_test.cpp \
-I/home/giorgos/Documents/TRILINOS/include \
-L/home/giorgos/Documents/TRILINOS/lib -lepetra
since it depends on the epetra package only (I still have to change the name :))
However if anyone knows how to compile trilinos with cmake I'd appreciate the input here
I am trying to link a C++ module using GCC, essentially like this:
gcc -c hello.c
g++ -c world.cpp
gcc -ohello -lstdc++ hello.o world.o
Note that I use -lstdc++ to link the C++ module in, so that I can use gcc instead of g++. The problem is that I'm getting the error:
undefined reference to `operator new(unsigned long)'
(Assuming that world.cpp contains at least one call to new.)
This error is fixed if I put -lstdc++ at the end of the linker line, like this:
gcc -ohello hello.o world.o -lstdc++
I am aware that this question has been asked many times here, but I have a special requirement. I am not directly calling GCC. I am using a build system for a different programming language (Mercury) which is calling GCC on my behalf, and I can't easily modify the way it calls GCC (though I can specify additional libraries using the LDFLAGS environment variable). So I have two additional requirements:
I cannot use g++ to link (only gcc) -- that is why I am doing the -lstdc++ trick above rather than simply linking with g++).
I don't think that I can control the order of the linker commands -- Mercury will put the .o files on the command-line after any libraries.
I understand the basic reason why the order is important, but what is baffling me is why did this break now? I just updated to Ubuntu 11.10 / GCC 4.6.1. I have been successfully compiling this program for years using precisely the above technique (putting -lstdc++ first). Only now has this error come up. An unrelated program of mine links against OpenGL using -lgl and that too broke when I upgraded and I had to move -lgl to the end of the command-line. I'm probably going to discover that dozens of my programs no longer compile. Why did this change? Is there something wrong with my new system or is that the way it is now? Note that these are ordinary shared libraries, not statically linked.
Is there anything I can do to make GCC go back to the old way, where the order of libraries doesn't matter? Is there any other way I can convince GCC to link libstdc++ properly without moving it after the .o files on the command-line?
If Mercury puts object files after libraries, Mercury is broken. Libraries belong after object files - always. You may sometimes get away with the reverse order, but not reliably. (Static libraries must go after the object files that reference symbols in the static library. Sometimes, a linker will note the symbols defined by a shared library even when none of the symbols are used; sometimes, the linker will only note the shared library symbols if the shared library provides at least one symbol.)