g++ compile multiple files - g++

I'got a problem with compiling linking of a program with multiple files by g++ (I usually use vstudio, but...).
If I use only main.cpp (and include appropriate header files for openCV), everything is ok with
g++ main.cpp -o main -I"C:\OpenCV2.1\include\opencv" -L"C:\OpenCV2.1\lib"
-lcxcore210 -lcv210 -lhighgui210
If I have main.cpp and some otherfile.cpp (both need openCV) and use
g++ main.cpp otherfile.cpp -o main -I"C:\OpenCV2.1\include\opencv"
-L"C:\OpenCV2.1\lib" -lcxcore210 -lcv210 -lhighgui210
it simply doesn't work and I got
c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe: warning: a
uto-importing has been activated without --enable-auto-import specified on the c
ommand line.
This should work unless it involves constant data structures referencing symbols
from auto-imported DLLs.
C:\Users\ONDEJM~1\AppData\Local\Temp\ccNisCoC.o:main.cpp:(.text+0x16d0): undefin
ed reference to `cv::Mat::Mat(_IplImage const*, bool)'
C:\Users\ONDEJM~1\AppData\Local\Temp\ccNisCoC.o:main.cpp:(.text+0x16f1): undefin
ed reference to `cv::FAST(cv::Mat const&, std::vector<cv::KeyPoint, std::allocat
or<cv::KeyPoint> >&, int, bool)'
C:\Users\ONDEJM~1\AppData\Local\Temp\ccNisCoC.o:main.cpp:(.text$_ZN2cv3Mat7relea
seEv[cv::Mat::release()]+0x3f): undefined reference to `cv::fastFree(void*)'
collect2: ld returned 1 exit status
What am I doing wrong?

Pass "-Wl,--enable-auto-import" to g++. Read ld's documentation about this.

Hm, it seems that I made a silly mistake... solution is simple: just recompile all openCV binarries by g++ and everything will be ok!

Related

How to link with chart director library with mingw

I am trying to build an application under mingw with Chart Director. My code compiles fine, but I get undefined reference errors from the linker.
The object file needs to link with ../ChartDirector.cpp/lib/chartdir51.lib
I have renamed this file to ../ChartDirector.cpp/lib/libchartdir51.a If I do not do this the linker cannot find it.
The result is:
mingw32-g++.exe -LJ:\wxWidgets-3.0.1\lib\gcc481TDM_dll
-L..\ChartDirector_cpp\lib -o ..\bin\plot.exe obj\Debug\plot.o
-lwxbase30u -lwxmsw30u_core -lchartdir51 -mwindows
obj\Debug\plot.o: In function `ZN3BoxC2EP11BoxInternal':
C:\Users\James\Documents\code\vase\plot/../ChartDirector_cpp/include/chartdir.h:804:
undefined reference to `Box2DrawObj'
obj\Debug\plot.o: In function `ZN7TextBoxC1EP15TextBoxInternal':
C:\Users\James\Documents\code\vase\plot/../ChartDirector_cpp/include/chartdir.h:832:
undefined reference to `TextBox2Box'
... and so on
To make things simpler, I changed to trying to build the simplebar demo application supplied by Chart Director. The build command now looks like this:
mingw32-g++.exe
C:\Users\James\Documents\code\vase\test\simplebar.cpp
-IC:\Users\James\Documents\code\vase\ChartDirector_cpp\include
-o C:\Users\James\Documents\code\vase\bin\test.exe
-LC:\Users\James\Documents\code\vase\ChartDirector_cpp\lib\
-lchartdir51
I still have the same undefineds.
Following this recipe I created a def file looking like this
EXPORTS
Box2DrawObj
TextBox2Box
CBaseChart_destroy
CBaseChart_makeChart
CAxis_setLabels
BarLayer2Layer
CXYChart_create
XYChart2BaseChart
CXYChart_xAxis
CXYChart_setPlotArea
CXYChart_addBarLayer
and used the dlltool to create a new libchartdir51.a
dlltool -d C:\Users\James\Documents\code\vase\ChartDirector_cpp\lib\chartdir.def
-l C:\Users\James\Documents\code\vase\ChartDirector_cpp\lib\libchartdir51.a
Well that fixed the undefined I saw before, but now I am getting something even more mysterious:
C:\Users\James\Documents\code\vase\ChartDirector_cpp\lib/libchartdir51.a(diaybs00001.o):(.idata$7+0x
0):
undefined reference to `_head_C__Users_James_Documents_code_vase_ChartDirector_cpp_lib_libchartd
ir51_a'
C:\Users\James\Documents\code\vase\ChartDirector_cpp\lib/libchartdir51.a(diaybs00009.o):(.idata$7+0x
0): undefined reference to `_head_C__Users_James_Documents_code_vase_ChartDirector_cpp_lib_libchartd
ir51_a'
... and so on
I tried downloading the linux version of chartdir. The result was:
mingw32-g++.exe
C:\Users\James\Downloads\ChartDirector\cppdemo\simplebar\simplebar.cpp
-IC:\Users\James\Downloads\ChartDirector\include
-o C:\Users\James\code\vase\bin\test.exe
C:\Users\James\Downloads\ChartDirector\lib\libchartdir.so.5.1.0
C:\Users\James\Downloads\ChartDirector\lib\libchartdir.so.5.1.0:
could not read symbols: File in wrong format
collect2.exe: error: ld returned 1 exit status
The problem was that I was trying to build with a 64 bit version of ChartDirector on a 32 bit mingw. Downloading the 32 bit library fixes the problem:
mingw32-g++
C:\Users\James\Downloads\chartdir_cpp_win32\ChartDirector\cppdemo\simplebar\simplebar.cpp
-IC:\Users\Jam es\Downloads\chartdir_cpp_win32\ChartDirector\include
-o C:\Users\James\code\vase\bin\test2.exe
-C:\Users\James\Downloads\chartdir_cpp_win32\ChartDirector\lib\chartdir51.dll
Normally undefined reference errors comes when the libs are not matching. Always get the latest libs from ChartDirector download page.

Xcode linker error writing Objective-C

A friend of mine asked me to re-write Box2D in objective-c as much as possible. I started writing and when I build the project so far I got, I got some linker errors, I faced similar problem from before, but it didn't help. The error I get is:
Ld /Users/aizen-qa/Library/Developer/Xcode/DerivedData/Obj-Box2D-bwsosdvwkjzsscahpbqrbrnzlall/Build/Products/Debug/Obj-Box2D normal x86_64
cd /Users/aizen-qa/Desktop/Obj-Box2D
setenv MACOSX_DEPLOYMENT_TARGET 10.9
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -L/Users/aizen-qa/Library/Developer/Xcode/DerivedData/Obj-Box2D-bwsosdvwkjzsscahpbqrbrnzlall/Build/Products/Debug -F/Users/aizen-qa/Library/Developer/Xcode/DerivedData/Obj-Box2D-bwsosdvwkjzsscahpbqrbrnzlall/Build/Products/Debug -filelist /Users/aizen-qa/Library/Developer/Xcode/DerivedData/Obj-Box2D-bwsosdvwkjzsscahpbqrbrnzlall/Build/Intermediates/Obj-Box2D.build/Debug/Obj-Box2D.build/Objects-normal/x86_64/Obj-Box2D.LinkFileList -mmacosx-version-min=10.9 -fobjc-arc -fobjc-link-runtime -framework Foundation -Xlinker -dependency_info -Xlinker /Users/aizen-qa/Library/Developer/Xcode/DerivedData/Obj-Box2D-bwsosdvwkjzsscahpbqrbrnzlall/Build/Intermediates/Obj-Box2D.build/Debug/Obj-Box2D.build/Objects-normal/x86_64/Obj-Box2D_dependency_info.dat -o /Users/aizen-qa/Library/Developer/Xcode/DerivedData/Obj-Box2D-bwsosdvwkjzsscahpbqrbrnzlall/Build/Products/Debug/Obj-Box2D
duplicate symbol _Ob2IsValid in:
/Users/aizen-qa/Library/Developer/Xcode/DerivedData/Obj-Box2D-bwsosdvwkjzsscahpbqrbrnzlall/Build/Intermediates/Obj-Box2D.build/Debug/Obj-Box2D.build/Objects-normal/x86_64/Ob2Vec3.o
/Users/aizen-qa/Library/Developer/Xcode/DerivedData/Obj-Box2D-bwsosdvwkjzsscahpbqrbrnzlall/Build/Intermediates/Obj-Box2D.build/Debug/Obj-Box2D.build/Objects-normal/x86_64/Ob2Mat22.o
duplicate symbol _Ob2InvSqr in:
/Users/aizen-qa/Library/Developer/Xcode/DerivedData/Obj-Box2D-bwsosdvwkjzsscahpbqrbrnzlall/Build/Intermediates/Obj-Box2D.build/Debug/Obj-Box2D.build/Objects-normal/x86_64/Ob2Vec3.o
/Users/aizen-qa/Library/Developer/Xcode/DerivedData/Obj-Box2D-bwsosdvwkjzsscahpbqrbrnzlall/Build/Intermediates/Obj-Box2D.build/Debug/Obj-Box2D.build/Objects-normal/x86_64/Ob2Mat22.o
duplicate symbol _Ob2IsValid in:
/Users/aizen-qa/Library/Developer/Xcode/DerivedData/Obj-Box2D-bwsosdvwkjzsscahpbqrbrnzlall/Build/Intermediates/Obj-Box2D.build/Debug/Obj-Box2D.build/Objects-normal/x86_64/Ob2Vec3.o
/Users/aizen-qa/Library/Developer/Xcode/DerivedData/Obj-Box2D-bwsosdvwkjzsscahpbqrbrnzlall/Build/Intermediates/Obj-Box2D.build/Debug/Obj-Box2D.build/Objects-normal/x86_64/Ob2Vec2.o
duplicate symbol _Ob2InvSqr in:
/Users/aizen-qa/Library/Developer/Xcode/DerivedData/Obj-Box2D-bwsosdvwkjzsscahpbqrbrnzlall/Build/Intermediates/Obj-Box2D.build/Debug/Obj-Box2D.build/Objects-normal/x86_64/Ob2Vec3.o
/Users/aizen-qa/Library/Developer/Xcode/DerivedData/Obj-Box2D-bwsosdvwkjzsscahpbqrbrnzlall/Build/Intermediates/Obj-Box2D.build/Debug/Obj-Box2D.build/Objects-normal/x86_64/Ob2Vec2.o
ld: 4 duplicate symbols for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I've read of similar problems, and tried the solutions such as checking the imports not use .m, and duplicate variable names. But I noticed that the classes of vector have same instance variable names, x, y so is this the reason for the error I'm getting or not?
You have data elements being defined, rather than declared, in multiple implementation files. This is usually because of something in an included header.
Look for wherever you reference Ob2InvSqr or Ob2IsValid and make sure that storage for those items is only done once.
the file Ob2Vec2.o and Ob2Vec3.o contain the same symbol _Ob2InvSqr
very likely that means you have both Ob2Vec2.m and Ob2Vec3.m in the same target.
make sure only one is really compiled
I guess you have an inline function _Ob2IsValid(...) in one of your header files that isn't being inlined (it's too large?)
If that's the case you can force it to be inlined like this:
__attribute__((always_inline)) inline void MyFunction(...) {}
Or just make it out-of-line
I was able to solve this thanks to a comment form MartinR. It was because I defined a function in a .h file that I included in multiple Objective-C classes. So what I did was put the function header in the .h file and its implementation in a .m file.

undefined reference to Class::method()

I'm using a framework called ROOT in my code, ROOT provides a large amount of libs, between then there is PROOF which should allow my code run in parallel.
Should be defined in TProof.h a static method Open that starts the parallel environment. I'm using this method as the following:
//usual includes (including ROOT's)
#include
//lots of code
int main(int argc, const char *argv[]) {
//Initialization code
TProof *p = TProof::Open("");
// more code
return 0;
}
g++ gives me this error:
mini2.o: In function `main':
/path/to/file/name.cxx:279: undefined reference to `TProof::Open(char const*, char const*, char const*, int)'
ROOT provides a script that prints all the necessary flags to compile and link its libs, I'm using those flags, in this case:
$ root-config --libs
-L/my/path/root/lib -lCore -lCint -lRIO -lNet -lHist -lGraf -lGraf3d -lGpad -lTree -lRint -lPostscript -lMatrix -lPhysics -lMathCore -lThread -pthread -lm -ldl -rdynamic
What I'm doing wrong? How can I solve it?
You are missing at least -lProof in your compiler (linker) options. I don't really know the framework, so I can't tell you whether this is your fault or a problem with the configuration script.
(This is how I found out: Downloaded the binary distribution of ROOT, checked the lib folder and found libProof.so.)
If this is not enough, include the other Proof* libraries you can find in the library directory.

Missing something in arm g++

I installed the CodeSourcery g++ toolchain and tried to compile a simple hello world program:
#include <iostream>
using namespace std;
int main()
{
cout << "Hello World" << endl;
return 0;
}
And got a lot of errors from the linker
$ arm-none-eabi-g++ helloworld.cpp -o helloworld.exe
bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000000008018
lib/libc.a(lib_a-abort.o): In function `abort':
abort.c:(.text.abort+0x10): undefined reference to `_exit'
lib/libc.a(lib_a-fstatr.o): In function `_fstat_r':
fstatr.c:(.text._fstat_r+0x1c): undefined reference to `_fstat'
lib/libc.a(lib_a-openr.o): In function `_open_r':
openr.c:(.text._open_r+0x20): undefined reference to `_open'
lib/libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text._sbrk_r+0x18): undefined reference to `_sbrk'
lib/libc.a(lib_a-signalr.o): In function `_kill_r':
signalr.c:(.text._kill_r+0x1c): undefined reference to `_kill'
lib/libc.a(lib_a-signalr.o): In function `_getpid_r':
signalr.c:(.text._getpid_r+0x4): undefined reference to `_getpid'
lib/libc.a(lib_a-writer.o): In function `_write_r':
writer.c:(.text._write_r+0x20): undefined reference to `_write'
lib/libc.a(lib_a-closer.o): In function `_close_r':
closer.c:(.text._close_r+0x18): undefined reference to `_close'
lib/libc.a(lib_a-isattyr.o): In function `_isatty_r':
isattyr.c:(.text._isatty_r+0x18): undefined reference to `_isatty'
lib/libc.a(lib_a-lseekr.o): In function `_lseek_r':
lseekr.c:(.text._lseek_r+0x20): undefined reference to `_lseek'
lib/libc.a(lib_a-readr.o): In function `_read_r':
readr.c:(.text._read_r+0x20): undefined reference to `_read'
collect2: ld returned 1 exit status
What library am I missing here?
The GCC toolchain is only half of what you need to create a working executable*. The other half is the runtime library. The runtime includes crt0.o, which contains the entry point (the code that calls main()), and generally a libc that contains the standard C functions (strcmp(), memcpy(), etc) as well as the system calls (open(), read(), and others). You need to find a source for these. If you're targeting an embedded Linux or BSD machine, you'll have to find out what libc your target is using. It's probably either GNU libc, BSD libc, newlib, or uclibc. You can get these and build them yourself, or they may be available already with your OS.
*unless you're building a freestanding binary, but this doesn't look to be what you're doing.
Basing on the cross compiler it appears that end target is bare metal. The default gcc libraries (OS dependent) will not work here. You can use the NewlibC or NewlibC-Nano. This generally will be shipped along with the cross compiler tool chain.
Look for lib folder which has precompiled NewlibC.
Once that is done,
This statement might help you to an extent.
arm-none-eabi-gcc --specs=rdimon.specs \
-Wl,--start-group -lgcc -lc -lc -lm -lrdimon -Wl,--end-group $(OTHER_OPTIONS)
Don't forget to provide the path of looking the libraries -L(path).
I had this same problem.
It turns out there are a handful of options you can send to the linker to make it start working, but the one that had the least splash damage in my code base was
-nostartfiles

Linking with libpng & zlib?

I'm trying to compile a project that uses both libjpeg and libpng. I know that libpng needs zlib, so I compiled all the three independently and put them (libjpeg.a, libpng.a and libz.a) on a folder called linrel32. What I execute then is:
g++ -Llinrel32/ program.cpp otherfile.cpp -o linrel32/executable -Izlib/ -Ilpng140/ -Ijpeg/ -lpthread -lX11 -O2 -DLINUX -s -lz -lpng -ljpeg
So I include the three libraries. Still, the linker complains:
linrel32//libpng.a(png.o): In function `png_calculate_crc':
png.c:(.text+0x97d): undefined reference to `crc32'
linrel32//libpng.a(png.o): In function `png_reset_crc':
png.c:(.text+0x9be): undefined reference to `crc32'
linrel32//libpng.a(png.o): In function `png_reset_zstream':
png.c:(.text+0x537): undefined reference to `inflateReset'
linrel32//libpng.a(pngread.o): In function `png_read_destroy':
pngread.c:(.text+0x6f4): undefined reference to `inflateEnd'
linrel32//libpng.a(pngread.o): In function `png_read_row':
pngread.c:(.text+0x1267): undefined reference to `inflate'
linrel32//libpng.a(pngread.o): In function `png_create_read_struct_2':
(... you get the idea :D)
collect2: ld returned 1 exit status
I know the missing functions are from zlib, and I'm adding zlib there. Opened libz.a and it seems to have a good structure. Recompiled it, everything looks fine. But it is not...
I don't know, is likely that the problem is trivial, and what I need is to sleep for a while. But still, if you could help me to figure out this thing ...
You need to rearrange the order of the libraries:
-lpng -ljpeg -lz
What is happening is that the linker has special rules on how it treats static libraries. What it does is that it only includes a .o from inside the .a if the .o is needed to satisfy a reference.
Furthermore, it handles static archives in the order in which they appear on the link line.
So, your code does not directly call any functions in zlib. So when the linker handles -lz first, there are not yet any calls to it so it doesn't pull in any of zlib.
Next, when the linker handles libpng, it sees that there are calls to it from your code. So it pulls the code from libpng and since it makes calls to zlib, now there are references to the zlib functions.
Now you come to the end of your libraries and there are unsatisfied calls which causes your error.
So, if libhigh.a makes use of liblow.a, you must have -lhigh before -llow in your link order.
you probably need to surround the zlib and png headers with extern "C", e.g.:
extern "C" {
#include <zlib.h>
}