undefined reference with -O3, not -O0

[Alexis_R_]

Hi there,

Taking baby steps towards using FGSL , which essentially comes as a compiled .mod file, which in my case sits in /gusr/alr99/linux/apps/include/ifort/ - attached. Am having trouble building with -O3. Apologies if this is a fgsl rather than ifort issue, but it seems to me if ifort can find the functions in the module with -O0, why not with -O3...?

With 11.1.059, here are the commands I use to build the program below successfully:

[shell]ifort -I. -Isrc/ -I/gusr/alr99/linux/apps/include/ifort -L/gusr/alr99/linux/apps/lib -lfgsl_ifort -lgsl -lgslcblas   -fpp  -warn all -gen-interfaces -warn interfaces -check all -assume realloc_lhs -O0 -FR -c -o main.o /gusr/alr99/cluster/workspace/helloworld/main.f90
ifort -I. -Isrc/ -I/gusr/alr99/linux/apps/include/ifort -L/gusr/alr99/linux/apps/lib -lfgsl_ifort -lgsl -lgslcblas   -fpp  -warn all -gen-interfaces -warn interfaces -check all -assume realloc_lhs -O0 -g -FR  -L/gusr/alr99/linux/lib64/fftw3/lib -o helloworld  main.o  -lfftw3f[/shell]

When the -O0 in the second command is subsituted with -O3, I get the following errors:

[shell]main.o: In function `MAIN__':
/gusr/alr99/cluster/workspace/helloworld/main.f90:(.text+0x6f0): undefined reference to `fgsl_mp_fgsl_interp_accel_alloc_'
/gusr/alr99/cluster/workspace/helloworld/main.f90:(.text+0x70a): undefined reference to `fgsl_mp_fgsl_interp_cspline_'
/gusr/alr99/cluster/workspace/helloworld/main.f90:(.text+0x71f): undefined reference to `fgsl_mp_fgsl_spline_alloc_'
/gusr/alr99/cluster/workspace/helloworld/main.f90:(.text+0x748): undefined reference to `fgsl_mp_fgsl_spline_name_'
/gusr/alr99/cluster/workspace/helloworld/main.f90:(.text+0x78d): undefined reference to `fgsl_mp_fgsl_spline_init_'
/gusr/alr99/cluster/workspace/helloworld/main.f90:(.text+0x874): undefined reference to `fgsl_mp_fgsl_spline_eval_'
/gusr/alr99/cluster/workspace/helloworld/main.f90:(.text+0x8ae): undefined reference to `fgsl_mp_fgsl_spline_eval_deriv_'
/gusr/alr99/cluster/workspace/helloworld/main.f90:(.text+0x8de): undefined reference to `fgsl_mp_fgsl_spline_eval_deriv2_'
/gusr/alr99/cluster/workspace/helloworld/main.f90:(.text+0x91d): undefined reference to `fgsl_mp_fgsl_spline_eval_integ_'
/gusr/alr99/cluster/workspace/helloworld/main.f90:(.text+0xa2a): undefined reference to `fgsl_mp_fgsl_spline_min_size_'
/gusr/alr99/cluster/workspace/helloworld/main.f90:(.text+0xa4d): undefined reference to `fgsl_mp_fgsl_spline_free_'[/shell]

Here is the code:

[cpp]program hello
	use fgsl
	implicit none
	integer :: i,index
	real(fgsl_double) :: x(10),y(10),xa
	type(fgsl_interp_accel) :: acc
	type(fgsl_spline) :: spline
	character(kind=fgsl_char,len=fgsl_strmax) :: name
	integer(fgsl_int) :: status
	real(fgsl_double) :: ra, rda, rd2a, ri
	integer, parameter :: nstep = 10000

	! build the signal
	print *, '#m=0,S=2'
	do i=1,10
		x(i) = i + 0.5 * sin(real(i))
		y(i) = i + cos (real(i)**2)
		print '(2g)', x(i), y(i)
	end do

	!
	acc = fgsl_interp_accel_alloc()
	spline = fgsl_spline_alloc(fgsl_interp_cspline,10)
	name = fgsl_spline_name(spline)
	status = fgsl_spline_init(spline,x,y,10)
	!print *, 'FGSL spline init status = ', status

	print *, '#m=1,S=0'
	do i=1,nstep
		xa = x(1) + (x(10)-x(1))*i/nstep
		ra = fgsl_spline_eval(spline, xa, acc)
		rda = fgsl_spline_eval_deriv(spline, xa, acc)
		rd2a = fgsl_spline_eval_deriv2(spline, xa, acc)
		ri = fgsl_spline_eval_integ(spline, 0.0_fgsl_double, xa, acc)
		!print *, i, ra, rda, rd2a, ri
		print '(2g)', xa, ra
	enddo
	index = fgsl_spline_min_size(spline)
!	print *, 'index = ', index
	call fgsl_spline_free(spline)


end program hello[/cpp]

Am I missing something?

[jimdempseyatthecove]

The fgsl should come as two files: .mod and either a .o or library.
It appears as if the object file or library is not linked in you build.

Jim

[Alexis_R_]

Quoting - jimdempseyatthecove

The fgsl should come as two files: .mod and either a .o or library.
It appears as if the object file or library is not linked in you build.

Jim

You're correct, it comes as a .mod and a library, libfgsl_ifort.a, which is in the directory specified by the -L. Any idea why the linking would happen with -O0 but not with -O3?

[Lorri_M_Intel]

Quoting - A. Rohou

You're correct, it comes as a .mod and a library, libfgsl_ifort.a, which is in the directory specified by the -L. Any idea why the linking would happen with -O0 but not with -O3?

There is no extra linking happening at -O0; we don't do that. Are the external references actually in the object file (see with nm foo.o).

I could understand the reverse; that is, a higher optimization level mayremove references to external routines if the code is never accessed.

- Lorri

[Alexis_R_]

Quoting A. Rohou

Quoting - A. Rohou

You're correct, it comes as a .mod and a library, libfgsl_ifort.a, which is in the directory specified by the -L. Any idea why the linking would happen with -O0 but not with -O3?

There is no extra linking happening at -O0; we don't do that. Are the external references actually in the object file (see with nm foo.o).

I could understand the reverse; that is, a higher optimization level mayremove references to external routines if the code is never accessed.

- Lorri

Firstly, here is the output from "nm main.o":

[bash]00000000000000e8 r LITPACK_0.0.1
00000000000000f0 r LITPACK_1.0.1
00000000000000f8 r LITPACK_2.0.1
0000000000000000 T MAIN__
0000000000000018 r STRLITPACK_0
0000000000000110 r STRLITPACK_10.0.1
0000000000000114 r STRLITPACK_11.0.1
0000000000000118 r STRLITPACK_12.0.1
000000000000011c r STRLITPACK_13.0.1
0000000000000120 r STRLITPACK_14.0.1
0000000000000128 r STRLITPACK_15.0.1
000000000000012c r STRLITPACK_16.0.1
0000000000000130 r STRLITPACK_17.0.1
0000000000000138 r STRLITPACK_18.0.1
0000000000000140 r STRLITPACK_19.0.1
000000000000000c r STRLITPACK_2
0000000000000148 r STRLITPACK_20.0.1
0000000000000150 r STRLITPACK_21.0.1
0000000000000158 r STRLITPACK_22.0.1
0000000000000000 r STRLITPACK_4
0000000000000100 r STRLITPACK_5.0.1
0000000000000000 r STRLITPACK_6.0.1
0000000000000108 r STRLITPACK_7.0.1
0000000000000080 r STRLITPACK_8.0.1
000000000000010c r STRLITPACK_9.0.1
0000000000000168 r _2il0floatpacket.0
0000000000000160 r _2il0floatpacket.1
                 U __intel_new_proc_init
                 U cosf
                 U fgsl_mp_fgsl_interp_accel_alloc_
                 U fgsl_mp_fgsl_interp_cspline_
                 U fgsl_mp_fgsl_spline_alloc_
                 U fgsl_mp_fgsl_spline_eval_
                 U fgsl_mp_fgsl_spline_eval_deriv2_
                 U fgsl_mp_fgsl_spline_eval_deriv_
                 U fgsl_mp_fgsl_spline_eval_integ_
                 U fgsl_mp_fgsl_spline_free_
                 U fgsl_mp_fgsl_spline_init_
                 U fgsl_mp_fgsl_spline_min_size_
                 U fgsl_mp_fgsl_spline_name_
                 U for_emit_diagnostic
                 U for_set_reentrancy
                 U for_write_seq_fmt
                 U for_write_seq_fmt_xmit
                 U for_write_seq_lis
                 U for_write_seq_lis_xmit
0000000000000140 b hello_$ACC.0.1
0000000000000000 d hello_$BLK$format_pack.0.1
00000000000000c0 b hello_$NAME.0.1
0000000000000148 b hello_$SPLINE.0.1
0000000000000000 b hello_$X.0.1
0000000000000060 b hello_$Y.0.1
                 U sinf[/bash]

But in the end, I managed to solve the problem by changing the order of the arguments & options of the linking command, so that the following command worked:

[bash]ifort -o helloworld -I. -Isrc/ -I/gusr/alr99/linux/apps/include/ifort main.o -L/gusr/alr99/linux/apps/lib -lfgsl_ifort -lgsl -lgslcblas -fpp -warn all -gen-interfaces -warn interfaces -check all -assume realloc_lhs -O3 -FR -L/gusr/alr99/linux/lib64/fftw3/lib -lfftw3f[/bash]

So it seems to me that ifort shows inconsistent behaviour: with -O3, it appears to be intolerant to "disorder" of arguments & options, whereas -O0 seems more flexible. I wonder if anyone can reproduce this?

[TimP]

I think you're talking about the behavior of gnu ld (supplied by your linux distro), rather than of ifort. Libraries are searched in the order specified, so objects are taken from static libraries only for unsatisfied references at the point of the search. In order to instruct ld to cycle through a group of libraries in case of circular dependencies, there are the -Wl,--start-group...-Wl,--end-group commands; otherwise ld is single-pass.

Depending on the version of ifort, -O settings may have some influence on the building of the script passed to ld, but there is no effort to change the basic ordering requirements of ld.

If you trot out your search engine, you will see that the design of ld goes way back before the origin of linux.

[Alexis_R_]

Quoting A. Rohou

I think you're talking about the behavior of gnu ld (supplied by your linux distro), rather than of ifort. Libraries are searched in the order specified, so objects are taken from static libraries only for unsatisfied references at the point of the search. In order to instruct ld to cycle through a group of libraries in case of circular dependencies, there are the -Wl,--start-group...-Wl,--end-group commands; otherwise ld is single-pass.

Depending on the version of ifort, -O settings may have some influence on the building of the script passed to ld, but there is no effort to change the basic ordering requirements of ld.

If you trot out your search engine, you will see that the design of ld goes way back before the origin of linux.

Thanks for your instructive post! I had no idea ifort was actually calling ld. Neither did I know about search orders etc.

Quoting A. Rohou

Depending on the version of ifort, -O settings may have some influence on the building of the script passed to ld, but there is no effort to change the basic ordering requirements of ld.

In my case, I was using ifort 11.1.059 and 11.1.064.