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.
Related
I'm having trouble trying to compile a simple fortran program which uses a module in the same directory.
I have 2 files: test1.f90 which contains the program and modtest.f90 which contains the module.
This is test1.f90:
program test
use modtest
implicit none
print*,a
end program test
This is modtest.f90:
module modtest
implicit none
save
integer :: a = 1
end module modtest
Both files are in the same directory. I compile modtest.f90 and test.f90 like this:
gfortran -c modtest.f90
gfortran -o test1 test1.f90
But then I get this error:
/tmp/cckqu8c3.o: In function `MAIN__':
test1.f90:(.text+0x50): undefined reference to `__modtest_MOD_a'
collect2: ld returned 1 exit status
Is there something I'm missing?
Thanks for the help
What you're doing is not telling the linker where reference module modtest is so that the your code can use its contents.
This should work:
gfortran -o test1 test1.f90 modtest.o
Some context:
The -o option tells the compiler to put the output of the full build (compile + link) into a program called test1. Then we supply a file that we are to compile (test1.f90). Finally we are telling the compiler to consider a file that contains the compiled output of another build (modtest.o) and to link this to the compiled output of test1.f90, and use the contents of modtest.o when trying to sort out references within the test1.f90 that reference the module modtest (in the statement use modtest in the source code).
So the statement says:
Please compile and subsequently link test1.f90 to modtest.o, and produce a file called test1 as the final output.
I am having an issue with the LAPACK/BLAS libraries when compiling a C code that needs them.
The issues are, when I run "make", I get:
file.c:(.text+0x1c41): undefined reference to `zgesvd_'
file.c:(.text+0x1c9c): undefined reference to `zgetrf_'
../file.a(SpatialOrientation.o): In function `myfunction.c':myfunction.c:(.text+0x7be): undefined reference to `dsyev_'
And several other such lines, all referring to similar missing references.
I have chased this error down to being something to do with BLAS. I followed the directions given at this excellent link for installing BLAS and put the relevant directory on the path. I also changed my Makefile accordingly to find these libraries.
Any help on this issue would be really appreciated!
Just to update, I recently installed itpp as well, also following the instructional here, since it seemed my missing references were linked to that. No changes so far...
Thanks for your help!
The problem is solved! Hooray! I just danced around my office...
For those who have the same problem, here is what I did:
1) Follow the instructions given here to make the lapack and blas libraries. To paraphrase, for a scientific Linux 6 machine, they are:
wget http://www.netlib.org/lapack/lapack.tgz
tar xvzf lapack.tgz
cd lapack-3.3.0 //if version number changes, change here to the right directory
mv make.inc.example make.inc
2) Then (important bit, also recommended here):
edit make.inc and add -m64 -fPIC flag to fortran compiler options: FORTRAN, OPTS, NOOPT, LOADER
Then
make blaslib
make
Now, what you have is, in /lapack-3.6.1 (or whatever your directory is called after this process), two files:
librefblas.a , and liblapack.a.
3) The next thing I did was to copy librefblas.a and liblapack.a into some subdirectories - i.e. /lib/liblapack for liblapack.a and /lib/libblas for librefblas.a
4) Then, put those directories in your makefile, like this:
LIBDIR1 = /path/lib/lapack
LIBDIR2 = /path/lib/blas
LIBS = -L$(LIBDIR1) -llapack -L$(LIBDIR2) -lblas $(SYSLIBS)
LIBSMPI = -L$(LIBDIR1) -llapack -L$(LIBDIR2) -lblas $(MPILIBS) $(SYSLIBS)
I also added /path/lib/lapack and /path/lib/blas onto my LD_LIBRARY_PATH (and PATH, just-in-case...)
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/lib/lapack:/path/lib/blas
export PATH=$PATH:/path/lib/lapack:/path/lib/blas
Then, go to wherever you Makefile is, and type
make
Yay yay yay!
By the way, with the latest version of lapack and blas, obtained in step 1), I compiled with gcc version 5.1.0 and the corresponding mpicc (openmpi 1.10.2).
Hope this helps someone else and shares the absolute delight.
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
I'm unable to link my program correctly. I use the following command line, but get an error.
g++ -I/home/blah/intel/composerxe/mkl/include dotProduct.cpp /home/blah/intel/composerxe/mkl/lib/intel64/libmkl_core.a
The output is this:
/tmp/ccvw6w13.o: In function `main':
dotProduct.cpp:(.text+0x108): undefined reference to `cblas_sdot'
collect2: ld returned 1 exit status
I also tried running a script that tries to link one by one against all .a files, but they all fail. Can anybody please suggest a solution.
Thanks.
Here's a KB article from Intel:
http://software.intel.com/en-us/articles/intel-math-kernel-library-intel-mkl-for-linux-linking-applications-with-intel-mkl-version-100/
On a side note, if you can use Intel compiler instead of gcc, this works (at least it does for me):
icpc files -mkl
Notice there's no l in front, it's just -mkl.
i tried to compile my first class in Objective-C (Personne.m) and i got the following errors :
undefined reference to WinMain#16
Id returned 1 exit status
i know that this question was asked before but i still didn`t know how to fix it. THX in advance :)
If you don't have a WinMain function in that file, you probably want to add -c to your command line:
gcc -c -o className.o className.m
Then later, when you're linking together your object files into the final executable, you can leave the -c off. Just make sure one of your object files has WinMain in it or that you link against whatever system library is supposed to contain it:
gcc -o myApp className.o className2.o ... WinMainLib.a