nios2 gsl linking problem

Altera_Forum · ‎02-11-2013

hello

i am using Nios II EDS 11.1 and i want to use gsl for some processing. i had done all of steps for introducing gsl include path to eclipse. gsl is built with nios ii gcc. and i wrote the blew code:

#include <stdio.h>#include <gsl/gsl_sf_bessel.h>
int main()
{
  printf("Hello from Nios II!\n");
double x=5.0;
double y=gsl_sf_bessel_J0(x);
  return 0;
}

and i recieve the below error on console:

**** Build of configuration Nios II for project gslt1 ****
make all 
Info: Building ../gslt1_bsp/
make --no-print-directory -C ../gslt1_bsp/
Info: Compiling hello_world.c to obj/default/hello_world.o
nios2-elf-gcc -xc -MP -MMD -c -I../gslt1_bsp//HAL/inc -I../gslt1_bsp/ -I../gslt1_bsp//drivers/inc -IC:\altera\11.1\quartus\bin\cygwin\usr\local\include -IC:\altera\11.1\quartus\bin\cygwin\usr\local\include\gsl  -DSYSTEM_BUS_WIDTH=32 -pipe -D__hal__ -DALT_NO_INSTRUCTION_EMULATION -DALT_SINGLE_THREADED    -O0 -g -Wall   -EL -mno-hw-div -mhw-mul -mno-hw-mulx  -o obj/default/hello_world.o hello_world.c
hello_world.c: In function 'main':
hello_world.c:23: warning: unused variable 'y'
Info: Linking gslt1.elf
nios2-elf-g++ -u close -T'../gslt1_bsp//linker.x' -msys-crt0='../gslt1_bsp//obj/HAL/src/crt0.o' -msys-lib=hal_bsp -L../gslt1_bsp/ -LC:\altera\11.1\quartus\bin\cygwin\usr\local\lib   -Wl,-Map=gslt1.map   -O0 -g -Wall   -EL -mno-hw-div -mhw-mul -mno-hw-mulx  -o gslt1.elf obj/default/hello_world.o -lm -lgsl -lgslcblas 
obj/default/hello_world.o: In function `main':
E:\DE2-115\DE2_115_demonstrations\DE2_115_Audio\software\gslt1/hello_world.c:23: undefined reference to `gsl_sf_bessel_J0'
collect2: ld returned 1 exit status
make: ***  Error 1

please help me.

thank you

Altera_Forum · ‎02-11-2013

I'd check that the library (libgsl.a ?) actually contains the required symbol.

Altera_Forum · ‎02-11-2013

thank you for your response, yes this is true, but in linking session this error occurred.what can i do with this problem?

Altera_Forum · ‎02-11-2013

It is also possible that the linker is finding a different copy of the library - the -L parameters set the search path.

An alternative is to explicitly specify path/libfoo.a (or libfoo.so) on the linker command line instead of -lfoo. Removing the vaguaries of the search path.

Not sure whether the IDE will let you do that though.