ISO_C_BINDINGS and underscores

[hdankowski]

Hi,
we have problems linking with the iso_c_binding module since the symbols in the static libifcore.a lib are given with a trailing underscore.
We have a quite large Fortran project and we do not like to add an underscore to every routine with -assume underscore so that option won't work for us.

Is there any other solution? Is it possible to retrieve the libifcore.a without trailing underscores or is there a different option to assume underscores only for intrinsic functions?

Thanks,
Hendrik

[Steven_L_Intel1]

Which compiler version are you using? We fixed a problem like this a long time ago.

[hdankowski]

Hi,

We use:
ifort (IFORT) 11.1 20090827

I attached a simple example. If I compile it the following way
ifort -c test1.f90
ifort -assume underscore test1.o test_iso_c_binding.f90
the error
test_iso_c_binding.f90:(.text+0x7a): undefined reference to `test1_'
occurs

Without "assume underscore":
ifort -c test1.f90
ifort test1.o test_iso_c_binding.f90
the error
test_iso_c_binding.f90:(.text+0x64): undefined reference to `iso_c_binding_mp_c_loc'
occurs.

The problem is that we do not want to add "-assume underscore" to our whole project (due to several reasons). Is it possible to assume an underscore only for intrinsic routines?

Remark: I found a way, but thats quite a bad hack: I created with nm and objcopy my own libifcore.a:
nm libifcore.a | grep iso_c > redefine.dat
.. edit redefine.dat, delete underscores ..
objcopy --redefine-syms redefine.dat libifcore.a libifcore_no_underscore.a

Is there any better official way?

Regards,
Hendrik

[lcoul]

I tested your example on Linux32 with ifort (IFORT) 11.0 20090318, i.e. an older version than yours.

I got no trouble with or without -assume

I suspect a problem of compiler installation...

[Steven_L_Intel1]

It should work without doing anything special. I think you are using a very old version. Make sure also that you are referencing the .modintr file from the 11.1 product and not something else.

[hdankowski]

I'm sorry but it does not work. I'm using version 11.1 056.

If I try the following:
ifort -c -I/global/opt/intel/Compiler/11.1/056/include/ia32/ -nus test1.f90
ifort -I/global/opt/intel/Compiler/11.1/056/include/ia32/ -nus test_iso_c_binding.f90 test1.o

I still get the same error:
test_iso_c_binding.f90:(.text+0x64): undefined reference to `iso_c_binding_mp_c_loc'

To stress it: We normally would like to compile each Fortran source with "-nus" (no underscore)!

How can I check which modules/.modintr files are actually used?

I think the problem started in Jan 2009. This is an extract from your file which comes with the ifort installation
.../Compiler/11.1/056/include/iso_c_binding.f90
! Jan-14-2009 The -assume underscore and 2underscores decorate C_LOC and C_FUNLOC
! (ISO_C_BINDING) intrinsic module inquiry functions
! Jan-15-2009 The -assume underscore and 2underscores decorate
! C_F_PROCPOINTER, C_NULL_FUNPTR and C_NULL_PTR (ISO_C_BINDING)
! intrinsic module inquiry functions and constants
There are no symbols in the libifcore.a forr the iso_c_binding routines which does NOT have a trailing underscore.


Hendrik

[Steven_L_Intel1]

I can't reproduce the problem either. Those bug entries you found are for errors found in 11.0 and fixed in 11.1. What's supposed to happen is that the intrinsic modules have ATTRIBUTES DEFAULT in their declarations so that switches such as -nus and -assume underscore are ignored. There is only one version of each name in the library.

Here's what I see.

[sblionel]$ ifort -c test_iso_c_binding.f90
[sblionel]$ nm -a test_iso_c_binding.o
...
U __intel_new_proc_init
U for_set_reentrancy
U for_stop_core
U for_write_seq_lis
U iso_c_binding_mp_c_associated_ptr_
U iso_c_binding_mp_c_f_pointer_scalar_
U iso_c_binding_mp_c_loc_
U test1_

[sblionel]$ ifort -c -nus test_iso_c_binding.f90
[sblionel]$ nm -a test_iso_c_binding.o
...
U __intel_new_proc_init
U for_set_reentrancy
U for_stop_core
U for_write_seq_lis
U iso_c_binding_mp_c_associated_ptr_
U iso_c_binding_mp_c_f_pointer_scalar_
U iso_c_binding_mp_c_loc_
U test1

Note that the iso_c_binding routines have the trailing underscore whether or not -nus is used. (I will comment that your attached sources had all the references commented out, so I uncommented them.)

[hdankowski]

Hi,

ok that is strange. I have the same problem on two PCs here with 11.1/056

ifort -c -assume underscore test_iso_c_binding.f90
nm test_iso_c_binding.o

gives:
00000000 r LITPACK_0.0.1
00000000 T MAIN__
00000000 r STRLITPACK_4
00000004 r STRLITPACK_5.0.1
0000000c r _2il0floatpacket.0
U _GLOBAL_OFFSET_TABLE_
U __intel_new_proc_init
U for_set_reentrancy
U for_stop_core
U for_write_seq_lis
U iso_c_binding_mp_c_associated_ptr_
U iso_c_binding_mp_c_f_pointer_scalar_
U iso_c_binding_mp_c_loc_
U test1_
00000000 b test_iso_c_binding_$CPTR.0.1

and
ifort -c test_iso_c_binding.f90 (or ifort -c -nus test_iso_c_binding.f90)
nm test_iso_c_binding.o

gives:
00000000 r LITPACK_0.0.1
00000000 T MAIN__
00000000 r STRLITPACK_4
00000004 r STRLITPACK_5.0.1
0000000c r _2il0floatpacket.0
U _GLOBAL_OFFSET_TABLE_
U __intel_new_proc_init
U for_set_reentrancy
U for_stop_core
U for_write_seq_lis
U iso_c_binding_mp_c_associated_ptr
U iso_c_binding_mp_c_f_pointer_scalar
U iso_c_binding_mp_c_loc
U test1
00000000 b test_iso_c_binding$CPTR.0.1

so the default for my installation is to assume no underscores.

I don't know if its important:
gcc --version
gcc (GCC) 4.2.1 (SUSE Linux)


Any idea whats wrong with the installation/ compiler settings?

Hendrik

[hdankowski]

Hi,

I figured it out: The problem was that we installed only the ia32 package on a x86_64 machine, because we only develop a 32bit application. But to do that one needs to install the combined package. After doing that, the underscores where correctly appended, independent of the underscore option.

I just thought it would not make any difference if one installs only the ia32 package or the combined one, but only using the 32bit compiler.

Thanks,
Hendrik

[Steven_L_Intel1]

I don't think that's exactly the issue - but you may have a mixture of 32-bit and 64-bit libraries. You may have been using the 64-bit compiler with 32-bit libraries.