I want to link opencv library to my C project, I have to compile the C project by gcc cause it link lots of C library, if compile by g++ it reports compatible errors. and the opencv is a c++ library without C version.this may a gcc and g++ object file linking problem
the makefile example below simply describe the situation
#compile myproject by gcc
myproject.o: myproject.c
gcc -c myproject.c -o myproject.o
#compile opencv by g++
opencv.o: opencv.cpp
g++ -c opencv.cpp -o opencv.o
#link then by gcc or g++, it reports undefined reference error
main:opencv.o myproject.o
g++(or gcc) -o main opencv.o myproject.o
myproject.o reports undefined reference error at link step
I tried add "-x c++" flag on 'myproject' compile, I think this equivalent to compile by g++,cause it reports the same compatible errors
Related
(Note: This question had been closed, citing that this had an answer. However, my question is not generic, I am asking why this works in ubuntu/redhat, but not in macos/cygwin. So I have edited this question, by modifying the title, mentioning the words macos and ubuntu.)
I have the following c++ code:
// main.cpp
#include<iostream>
#include<cstdio>
#include "defs.h" // has the function headers only
int func0(int a0) {
printf("func0-%d\n", a0);
return a0+1;
}
int func1(int a1) {
int x;
x=func0(a1);
printf("func1-%d\n", x);
return a1+1;
}
int func2(int a2) {
int x;
x=func1(a2);
printf("func2-%d\n", x);
return x+5;
}
int main() {
func1(5);
func2(8);
}
I can compile and run this code as:
g++ main.cpp; ./a.out
Now I would like to move the functions to different files (func1 to f1.cpp,
fun0 and func2 to f2.cpp, and main to main.cpp), and create shared libraries
like this:
g++ -c -pipe -std=c++11 -fPIC main.cpp
g++ -c -pipe -std=c++11 -fPIC f1.cpp
g++ -c -pipe -std=c++11 -fPIC f2.cpp
g++ -shared -o libx1.so f1.o
g++ -shared -o libx2.so f2.o
g++ main.o -L. -lx1 -lx2 -o exe
export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
./exe
The above instructions work in redhat linux and ubuntu. But when I run the same commands in other variants of linux (eg macos or cygwin) I get errors during creation of the shared library like this:
g++ -shared -o libx1.so f1.o
undefined reference to func0(int)
g++ -shared -o libx2.so f2.o
undefined reference to func1(int)
Why is this error happening only in some OS versions, and not happening in redhat/ubuntu? Is it due to the gcc versions, or something to do with the OS?
(The above instructions work with g++ in redhat(gcc version 8.3.1) and ubuntu (9.4.0). It does not work with g++ in cygwin(11.3.0) and in macos(11.2.0).)
The problem is caused by cyclic dependencies between the two libraries. Before doing anything else, you should ask yourself whether it is acceptable to have cyclic dependencies for your project. It is never a good idea, but if the alternative involves massive refactoring, it could be the lesser of two evils. Still, refactoring should probably be the default answer in most cases. If you cannot refactor, the rest of this answer is for you.
How are cyclic dependencies handled on different OSes?
On both Linux and Mac OS X (and on FreeBSD and on most commercial Unixes of old), references are resolved at load time. The loader uses the first suitable symbol definition it encounters, be it it in the main executable, in the shared object itself, or in a different shared object. It is not known until load time where that definition will be found.
So when the executable from the question is loaded, the dynamic loader finds the definition of func1 in libx1 and the definitions of func0 and func2 in libx2, and all is well.
The difference between Linux and Mac OS X lies in the linker (ld) behaviour. Both GNU ld and LLVM ld by default allow unresolved references when building a shared library. Mac OS X ld appears to be of a different breed and unresolved references are not allowed by default. One can either list the dependencies on the link line, or explicitly allow unresolved references using the Mac-specific ld option -undefined dynamic_lookup. But of course when the dependencies are cyclic, the first option is problematic. For code in question:
g++ -shared -o libx1.so f1.o -Wl,-undefined,dynamic_lookup
g++ -shared -o libx2.so f2.o -Wl,-undefined,dynamic_lookup
Windows DLLs work very differently. Each symbol must be resolved at link time. Unlike the Unix-y loaders, the loader must know exactly which DLL to search for each imported symbol. There is no option to allow unresolved references in DLLs because there is no mechanism to resolve them at load time from an unknown source.
Windows still allows cyclic dependencies between DLLs, but the mechanism is a bit different. The linker must use separate import libraries in this case (they are usually optional when using GNU or LLVM toolchains). The linking is done in two phases. First, the .lib files are generated for each future .dll, and then .dll themselves are produced using the .lib files from the first stage. For code in question:
# first stage
g++ -shared -Wl,--out-implib=x1.lib -o x1.dll f1.o
g++ -shared -Wl,--out-implib=x2.lib -o x2.dll f2.o
# second stage
g++ -shared -o x1.dll f1.o x2.lib
g++ -shared -o x2.dll f2.o x1.lib
The first stage will report undefined symbols but will still produce the .lib file needed for the second stage.
I am creating a gcc shared library having a static library dependency.
I compile the parts for static library as following:
gcc -c -m64 -O2 -fPIC -std=c99 -Wall ms*.c //there are 10 C files, no warnings
Next I create a static library with:
ar rc static_lib.a ms*.o
Next I compile the parts for my program as following:
g++ -c -m64 -O2 -fPIC -std=c++14 -Wall ab*.cpp //there are 5 C++ files, just -Wunused-variable warnings
Then I create a shared library as following:
g++ -shared -g -Wall ab*.o static_lib.a -o shared_lib.so
in the normal case, this shared_lib.so will be called by a Ruby program using a foreign function interface. There is no problem if I do it on ubuntu or mac(.dylib), but if I try this on debian stretch I get an error related to the static library as if the configurations are not set properly. If I run the application without foreign function interface, such as creating a tester and running with the cpp file main function as following:
> g++ -o library_test ab*.o static_lib.a
> ./library_test
There is no problem!
My question is what kind of configuration for creating a shared library may be missing here to not get that undesirable behaviour. Especially on debian stretch 9.5!
Or is there a way that I can understand if there is a problem in the shared library.
From the comments, you indicate the problem is with a #define. Those are preprocessor directives. Libraries are for the linker.
You might be confused because g++ does include the preprocessor phase, and might call the linker depending on the requested output. Still, g++ follows the C++ language rules.
Ok, so this might not be a great question, but I'm a bit stuck.
I have 3 programs:
pegio.c/pegio.h - Does hardware initialization and functions for my device
PegIOHandler.cpp/PegIOHandler.h - Handles I/O for device
PegRTU.cpp - Main function
My project implements the opendnp3 (which allows one to transmit data using the DNP3 protocol) library.
Now, to compile it I first compile the pegio.c file
gcc -c pegio.c -o pegio.o
Easy, up to here I understand.
Secondly I compile the IOHandler and reference pegio.c as it uses it.
g++ -c PegIOHandler.cpp pegio.c -o PegIOHandler.o -std=c++0x
Now it gives me the following output.
g++: warning: pegio.o: linker input file unused because linking not done
But, it still creates the object file. HOWEVER, PegIOHandler implements opendnp3 header files, which is included in PegIOHandler.cpp and PegIOHandler.h. When I attempt to compile these files without using the '-c', it tells me that there are undefined references to the opendnp3 files. I know I have to link them to my project, but how do I do that?
Then compililing my third and final file:
g++ PegRTU.cpp pegio.o PegIOHandler.o -o pegrtu -std=c++0x
This now tells me that there are undefined references to the opendnp3 files.
So: How do I link the opendnp3 library to my project / code files???
Thanks!
Ouch. So many misunderstandings. You don't need the previously compiled object files to compile further source files to object code. However, you do need to link them together at the end of the compilation process, including any libraries required. All in all:
gcc -c pegio.c -o pegio.o
g++ -c PegIOHandler.cpp -o PegIOHandler.o -std=c++0x
g++ -c PegRTU.cpp -o PegRTU.o -std=c++0x
g++ -o executable_name *.o -lopendnp3 # or whatever linker flag is needed for OpenDNP3
And pretty please, read this.
I am trying to build a project with many depencies. For simplying, let's say 2 projects "Mathematics" and "PhysicalProperties which depends on "Mathematics". These projects are build in libraries static and dll. So we need to get libMathematics.a, Mathematics.dll libPhysicalProperties.a and .dll...
So "PhysicalProperties" needs Boost and the libMathematics.a...
I'm working with Eclipse Indigo and the toolchain is MingW 4.5.0.
The build of "Mathematics" works but not the build of "PhysicalProperties" which gave a linker errors : "undefined reference to function..." in "Mathematics"
I check the dependencies but everything is ok, the function is really declared and defined and the library Mathematics is linked. I check also the symbols in the libMathematics.a and found the function that linker didn't find... So if you 've got ideas, i wil be glad to read you ?
Below are the errors when building :
//===========================================================================
Building file: ../WaveTools.cpp
Invoking: GCC C++ Compiler
g++ -I"C:\Users\StageTahar\Desktop\Lucid\Common\Includes" -I"C:\Boost/include/Boost-1_49/" -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"WaveTools.d" -MT"WaveTools.d" -o "WaveTools.o" "../WaveTools.cpp"
Finished building: ../WaveTools.cpp
Building target: ElectromagneticWave.dll
Invoking: GCC C++ Linker
g++ -s -L"C:\Users\StageTahar\Desktop\Lucid\Common\Libraries" -L"C:\Boost/lib" -shared -Wl,--out-implib=libElectromagneticWave.a -o "ElectromagneticWave.dll" ./ElectromagneticWaveImplementation.o ./WaveTools.o -lMathematics -lboost_wserialization-mgw45-mt-d-1_49
./ElectromagneticWaveImplementation.o: In function `ZNK11JonesVectorIfE12getIntensityEv':
C:\Users\StageTahar\Desktop\Lucid\Engines\ElectromagneticWave\Debug/../WaveDefinitions.h:124: undefined reference to `float norm<float>(ComplexT<float> const&)'
//=========================================================================================
I have a C++ library and a C++ application trying to use functions and classes exported from the library. The library builds fine and the application compiles but fails to link. The errors I get follow this form:
app-source-file.cpp:(.text+0x2fdb): undefined reference to `lib-namespace::GetStatusStr(int)'
Classes in the library seem to be resolved just fine by the linker, but free functions and exported data (like a cosine lookup table) invariably result in the above error.
I am using Ubuntu 8.04 (Hardy), and it is up to date with the latest Ubuntu packages.
The command to link the library is (with other libraries removed):
g++ -fPIC -Wall -O3 -shared -Wl,-soname,lib-in-question.so -o ~/project/lib/release/lib-in-question.so
The command to link the application is (with other libraries removed):
g++ -fPIC -Wall -O3 -L~/project/lib/release -llib-in-question -o ~/project/release/app-in-question
Finally, it appears (as best as I can tell) that the symbols in question are being exported properly:
nm -D ~/project/lib/release/lib-in-question.so | grep GetStatusStr --> U _ZN3lib-namespace12GetStatusStrEi
the U before _ZN3lib-namespace12GetStatusStrEi in the nm output shows that the symbol is undefined in the library.
Maybe it's defined in the wrong namespace: it looks like you're calling it in lib-namepace but you might be defining it in another.
It's been a while, but if you specify a lib with the -l option, then don't you have the skip the lib prefix?
(I changed the name from "lib-in-question.so" to "libfoobar.so" for easier reading for the example below)
g++ -fPIC -Wall -O3 -L~/project/lib/release -lfoobar
or
g++ -fPIC -Wall -O3 ~/project/lib/release/libfoobar.so