I'm using a crosstool through cygwin to compile for an ARM processor. The compile log looks like this:
Building Makefile: "C:\Documents and Settings\student\Desktop\sepatriot\spa pc\gsl-test\Makefile.win"
Executing make...
make.exe -f "C:\Documents and Settings\student\Desktop\sepatriot\spa pc\gsl-test\Makefile.win" all
arm-unknown-linux-gnu-gcc.exe test-gsl.o -o "gsl-test.exe" -L"C:/cygwin/opt/crosstool/gcc-3.3.4-glibc-2.3.2/arm-unknown-linux-gnu/lib" -L"C:/cygwin/opt/crosstool/gcc-3.3.4-glibc-2.3.2/arm-unknown-linux-gnu/arm-unknown-linux-gnu/lib" -L"C:/cygwin/lib" -L/cygdrive/c/cygwin/opt/crosstool//gcc-3.3.4-glibc-2.3.2/arm-unknown-linux-gnu/lib -L/cygdrive/c/cygwin/opt/crosstool//gcc-3.3.4-glibc-2.3.2/arm-unknown-linux-gnu/usr/include -lgsl -lm -lgslcblas
test-gsl.o(.text+0x60): In function main':
: undefined reference togsl_matrix_view_array'
test-gsl.o(.text+0x78): In function main':
: undefined reference togsl_vector_view_array'
test-gsl.o(.text+0x80): In function main':
: undefined reference togsl_vector_alloc'
test-gsl.o(.text+0x90): In function main':
: undefined reference togsl_permutation_alloc'
test-gsl.o(.text+0xac): In function main':
: undefined reference togsl_linalg_LU_decomp'
test-gsl.o(.text+0xc4): In function main':
: undefined reference togsl_linalg_LU_solve'
test-gsl.o(.text+0xe0): In function main':
: undefined reference togsl_vector_fprintf'
test-gsl.o(.text+0xe8): In function main':
: undefined reference togsl_permutation_free'
test-gsl.o(.text+0xf0): In function main':
: undefined reference togsl_vector_free'
collect2: ld returned 1 exit status
make.exe: *** [gsl-test.exe] Error 1
Execution terminated
the reason that this confuses me is that I have the libraries stored in: C:\cygwin\lib and the includes for gsl in: C:\cygwin\usr\include. If anybody can help me out I will be eternally grateful.
TMR
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First, let me say thanks for responding. I am targeting linux, but when I tried the code sourcery toolchain the executables would not run on my ARM. I also tried to build the gsl library in cygwin for the arm-unknown-linux-gnu and I have had some problems. I'm also not wuite sure how that works. the configure executable for the library will let you specify the build computer and the host computer, which I have done, and you also get the option of being able to change the compiler, which I set to be my toolchain. however, when I try to make the library I get compile errors. Does that mean I have messed up the configuration?
Thanks.
TR
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Welcome to the world of GNU cross-development! (and Cygwin only makes things worse). There are so many things that could be wrong, it is impossible to say (especially without you posting the logs!). If the CodeSourcery build failed to work on your ARM I seriously doubt that it is an issue with the compiler. Tt is the essentially the same GNU compiler as every other, the code generation will be identical for a given target and set of compiler/linker options. The compiler supports a wide range of ARM variants, if for example you created an ARM9 build and tried to run it on an ARM7 it is unlikely to work, ARM9 has additional instructions and features.
> the library will let you specify the build computer and the host computer
Let us be sure we have the terminology right: The the 'host' is the 'build' computer; it is the machine that 'hosts' the compiler/toolchain. The architecture the code will run on is called the 'target'.
What precisely is your target device BTW? And do you have remote debug facilities (the ability to run GDB or Insight from the host)? Without a debugger, you are going to have a hard time getting anything non-trivial working.
Another unrelated thought has occurred to me in the interim - you do realise that most off-the-shelf ARM microcontrollers do not have floating point hardware? (NXP LPC3xxx and Freesacale iMX-31 excepted), without an FPU the GSL code is likely to run very slowly. The ARM Vector Floating Point (VFP), included in the aforementioned parts accelerates math intensive code by about 5 times compared with software FP code (more - perhaps 10 times - if the compiler generates vectorised (SIMD) code, although so far I have not found a single ARM compiler that does). If you do have VFP on your ARM, bear in mind also that most GNU toolchains use teh Newlib C library and that the sqrt()/sqrtf() functions are implemented an an algorithm using primitive operations rather than using the VFP's SQRT/SQRTF instructions.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I have the libraries stored in: C:\cygwin\lib
> and the includes for gsl in: C:\cygwin\usr\include.
By convention (and for your own sanity) libraries in C:\cygwin\lib would be for Cygwin targets only. What you need is a library built for the ARM target (arm-unknown-linux-gnu in your case). So you either have the library in an ill-advised location or you have the wrong library altogether (i.e. not an ARM targeted library). It is likely that you will have to build the library yourself for the appropriate target.
You certainly should not have -L"C:/cygwin/lib" in your library path list since that will contain libraries targeted for the host (cygwin).
The library should be in /cygdrive/c/cygwin/opt/crosstool/gcc-3.3.4-glibc-2.3.2/arm-unknown-linux-gnu/arm-unknown-linux-gnu/lib or in an alternative location specified by an additional -L<path> option. The latter is prefereable in my opinion, although if you use the "make install" command to build and install the library, you may have no choice. It must have been built for target arm-unknown-linux-gnu (typically an option in the libraries .configure script I believe).
Note that /cygdrive/c/ is equivalent to c:/ but the former should be used in cygwin if using the bash shell. If using Windows cmd.exe or as appears to be the case Dev-C++, then I believe that you will have to use c:/ exclusively, but you appear to have used a mix of these. You have also essentially specified the same path twice, once with /cygdrive/c and once with c:, but these are either side of -L"C:/cygwin/lib" which shouldn't be there, but which will override the subsequent paths if the necessary library is found there, so it is a bit messed up.
I imagine that cygdrive/c/cygwin/opt/crosstool/gcc-3.3.4-glibc-2.3.2/arm-unknown-linux-gnu/usr/include contains only header files, so there is no benefit in specifying it as a library path (and outside of bash it needs c:/ in any case). It should be specified an an include path (using -I<path>) in the compiler options. Your log only shows the linker step, so there is no telling whether you have the compiler options correct - we need to see a clean build to determine that. Unfortunately Dev-C++ insists in generating makefiles that invoke the linker (ld.exe) through the compiler gcc.exe) so it is somewhat less obvious what is going on.
Are you really targeting Linux on your ARM device? If not I can recommend WinARM as a bare-metal (OS-less) GNU cross-toolchain for ARM that does not require all that Cygwin nonsense to work ( http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ ). The problem with Cygwin for cross-development is that it also has tools and libraries host development and you have to be sure that you are not accidentally mixing target and host tools/libraries as seems to be the case here. Unfortunately once you have had Cygwin on your system, it can be very hard to get rid of its ghost. I once had to reformat and reinstall Windows to stop it screwing up other GNU dependent tools!
If you do need a Windows based GNU arm-linux toolchain, you might also try http://www.codesourcery.com/gnu_toolchains/arm/portal/package2548?@template=release To be honest, you will be far better off not using Cygwin, especially if you want to use Dev-C++. There are so many inappropriate interactions that can happen.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hey all,
I'm trying to use gsl to do some linear algebra, and right now I'm just trying to compile this example code from the gnu website:
include <stdio.h>
include <gsl/gsl_linalg.h>
int
main (void)
{
double a_data[] = { 0.18, 0.60, 0.57, 0.96,
0.41, 0.24, 0.99, 0.58,
0.14, 0.30, 0.97, 0.66,
0.51, 0.13, 0.19, 0.85 };
double b_data[] = { 1.0, 2.0, 3.0, 4.0 };
gsl_matrix_view m
= gsl_matrix_view_array (a_data, 4, 4);
gsl_vector_view b
= gsl_vector_view_array (b_data, 4);
gsl_vector *x = gsl_vector_alloc (4);
int s;
gsl_permutation * p = gsl_permutation_alloc (4);
gsl_linalg_LU_decomp (&m.matrix, p, &s);
gsl_linalg_LU_solve (&m.matrix, p, &b.vector, x);
printf ("x = \n");
gsl_vector_fprintf (stdout, x, "%g");
gsl_permutation_free (p);
gsl_vector_free (x);
return 0;
}
I'm using a crosstool through cygwin to compile for an ARM processor. The compile log looks like this:
Building Makefile: "C:\Documents and Settings\student\Desktop\sepatriot\spa pc\gsl-test\Makefile.win"
Executing make...
make.exe -f "C:\Documents and Settings\student\Desktop\sepatriot\spa pc\gsl-test\Makefile.win" all
arm-unknown-linux-gnu-gcc.exe test-gsl.o -o "gsl-test.exe" -L"C:/cygwin/opt/crosstool/gcc-3.3.4-glibc-2.3.2/arm-unknown-linux-gnu/lib" -L"C:/cygwin/opt/crosstool/gcc-3.3.4-glibc-2.3.2/arm-unknown-linux-gnu/arm-unknown-linux-gnu/lib" -L"C:/cygwin/lib" -L/cygdrive/c/cygwin/opt/crosstool//gcc-3.3.4-glibc-2.3.2/arm-unknown-linux-gnu/lib -L/cygdrive/c/cygwin/opt/crosstool//gcc-3.3.4-glibc-2.3.2/arm-unknown-linux-gnu/usr/include -lgsl -lm -lgslcblas
test-gsl.o(.text+0x60): In function
main': : undefined reference togsl_matrix_view_array'test-gsl.o(.text+0x78): In function
main': : undefined reference togsl_vector_view_array'test-gsl.o(.text+0x80): In function
main': : undefined reference togsl_vector_alloc'test-gsl.o(.text+0x90): In function
main': : undefined reference togsl_permutation_alloc'test-gsl.o(.text+0xac): In function
main': : undefined reference togsl_linalg_LU_decomp'test-gsl.o(.text+0xc4): In function
main': : undefined reference togsl_linalg_LU_solve'test-gsl.o(.text+0xe0): In function
main': : undefined reference togsl_vector_fprintf'test-gsl.o(.text+0xe8): In function
main': : undefined reference togsl_permutation_free'test-gsl.o(.text+0xf0): In function
main': : undefined reference togsl_vector_free'collect2: ld returned 1 exit status
make.exe: *** [gsl-test.exe] Error 1
Execution terminated
the reason that this confuses me is that I have the libraries stored in: C:\cygwin\lib and the includes for gsl in: C:\cygwin\usr\include. If anybody can help me out I will be eternally grateful.
TMR
First, let me say thanks for responding. I am targeting linux, but when I tried the code sourcery toolchain the executables would not run on my ARM. I also tried to build the gsl library in cygwin for the arm-unknown-linux-gnu and I have had some problems. I'm also not wuite sure how that works. the configure executable for the library will let you specify the build computer and the host computer, which I have done, and you also get the option of being able to change the compiler, which I set to be my toolchain. however, when I try to make the library I get compile errors. Does that mean I have messed up the configuration?
Thanks.
TR
Welcome to the world of GNU cross-development! (and Cygwin only makes things worse). There are so many things that could be wrong, it is impossible to say (especially without you posting the logs!). If the CodeSourcery build failed to work on your ARM I seriously doubt that it is an issue with the compiler. Tt is the essentially the same GNU compiler as every other, the code generation will be identical for a given target and set of compiler/linker options. The compiler supports a wide range of ARM variants, if for example you created an ARM9 build and tried to run it on an ARM7 it is unlikely to work, ARM9 has additional instructions and features.
> the library will let you specify the build computer and the host computer
Let us be sure we have the terminology right: The the 'host' is the 'build' computer; it is the machine that 'hosts' the compiler/toolchain. The architecture the code will run on is called the 'target'.
What precisely is your target device BTW? And do you have remote debug facilities (the ability to run GDB or Insight from the host)? Without a debugger, you are going to have a hard time getting anything non-trivial working.
Another unrelated thought has occurred to me in the interim - you do realise that most off-the-shelf ARM microcontrollers do not have floating point hardware? (NXP LPC3xxx and Freesacale iMX-31 excepted), without an FPU the GSL code is likely to run very slowly. The ARM Vector Floating Point (VFP), included in the aforementioned parts accelerates math intensive code by about 5 times compared with software FP code (more - perhaps 10 times - if the compiler generates vectorised (SIMD) code, although so far I have not found a single ARM compiler that does). If you do have VFP on your ARM, bear in mind also that most GNU toolchains use teh Newlib C library and that the sqrt()/sqrtf() functions are implemented an an algorithm using primitive operations rather than using the VFP's SQRT/SQRTF instructions.
Clifford
> I have the libraries stored in: C:\cygwin\lib
> and the includes for gsl in: C:\cygwin\usr\include.
By convention (and for your own sanity) libraries in C:\cygwin\lib would be for Cygwin targets only. What you need is a library built for the ARM target (arm-unknown-linux-gnu in your case). So you either have the library in an ill-advised location or you have the wrong library altogether (i.e. not an ARM targeted library). It is likely that you will have to build the library yourself for the appropriate target.
You certainly should not have -L"C:/cygwin/lib" in your library path list since that will contain libraries targeted for the host (cygwin).
The library should be in /cygdrive/c/cygwin/opt/crosstool/gcc-3.3.4-glibc-2.3.2/arm-unknown-linux-gnu/arm-unknown-linux-gnu/lib or in an alternative location specified by an additional -L<path> option. The latter is prefereable in my opinion, although if you use the "make install" command to build and install the library, you may have no choice. It must have been built for target arm-unknown-linux-gnu (typically an option in the libraries .configure script I believe).
Note that /cygdrive/c/ is equivalent to c:/ but the former should be used in cygwin if using the bash shell. If using Windows cmd.exe or as appears to be the case Dev-C++, then I believe that you will have to use c:/ exclusively, but you appear to have used a mix of these. You have also essentially specified the same path twice, once with /cygdrive/c and once with c:, but these are either side of -L"C:/cygwin/lib" which shouldn't be there, but which will override the subsequent paths if the necessary library is found there, so it is a bit messed up.
I imagine that cygdrive/c/cygwin/opt/crosstool/gcc-3.3.4-glibc-2.3.2/arm-unknown-linux-gnu/usr/include contains only header files, so there is no benefit in specifying it as a library path (and outside of bash it needs c:/ in any case). It should be specified an an include path (using -I<path>) in the compiler options. Your log only shows the linker step, so there is no telling whether you have the compiler options correct - we need to see a clean build to determine that. Unfortunately Dev-C++ insists in generating makefiles that invoke the linker (ld.exe) through the compiler gcc.exe) so it is somewhat less obvious what is going on.
Are you really targeting Linux on your ARM device? If not I can recommend WinARM as a bare-metal (OS-less) GNU cross-toolchain for ARM that does not require all that Cygwin nonsense to work ( http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ ). The problem with Cygwin for cross-development is that it also has tools and libraries host development and you have to be sure that you are not accidentally mixing target and host tools/libraries as seems to be the case here. Unfortunately once you have had Cygwin on your system, it can be very hard to get rid of its ghost. I once had to reformat and reinstall Windows to stop it screwing up other GNU dependent tools!
Another other Cygwin-free toolchain is http://www.yagarto.de/ It too is OS-less
If you do need a Windows based GNU arm-linux toolchain, you might also try http://www.codesourcery.com/gnu_toolchains/arm/portal/package2548?@template=release To be honest, you will be far better off not using Cygwin, especially if you want to use Dev-C++. There are so many inappropriate interactions that can happen.
Clifford