how to link ifort anc gcc binaries?

how to link ifort anc gcc binaries?


Hi,

I have a problem with linking binaries compiled with ifort 10.0 and gcc. The main code is written in fortran with some subroutines in C. Everything compiles correctly but it doesn't link. I get the following errors when linking:

ifort -c -O problemQCQP.f
ifort -c -O exampleProgram.f
gcc -c -O -I/usr/local/knitro-5.1.2-student/include knitro_fortran.c
ifort -o example_static problemQCQP.o exampleProgram.o knitro_fortran.o /usr/local/knitro-5.1.2-student/lib/libknitro.a -ldl -cxxlib
exampleProgram.o(.text+0xd4): In function `MAIN__':
: undefined reference to `ktrf_open_instance_'
exampleProgram.o(.text+0xd9): In function `MAIN__':
: undefined reference to `ktrf_load_param_file_'
exampleProgram.o(.text+0x134): In function `MAIN__':
: undefined reference to `ktrf_init_problem_'
exampleProgram.o(.text+0x176): In function `MAIN__':
: undefined reference to `ktrf_solve_'
exampleProgram.o(.text+0x1d5): In function `MAIN__':
: undefined reference to `ktrf_close_instance_'
make: *** [example_static] Error 1

AmI missing some libraries which I have to include for this to work or is there a compatibility isssue? When using g77 on this simple example program everything compiles and links correctly (using libstdc++). The problem is that I have my code written in Fortran 95 and it is compiled with ifort so I really need this to run using ifort instead of g77. The system I'm runnning is the following:

Linux aveden.localdomain 2.6.9-55.0.12.ELsmp #1 SMP Wed Oct 17 08:19:30 EDT 2007 i686 i686 i386 GNU/Linux

ifort (IFORT) 10.0 20070426

gcc version 3.4.6 20060404 (Red Hat 3.4.6-9)

Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs

Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux

Thread model: posix

I would really appreciate any help with this problem.

Thanks,

Grgur

5 posts / 0 new

In knitro_fortran.c, what assumptions do you make for name decoration of functions to be called by Fortran? g77, by default, assumes double-underscore. Ifort single underscore.

I suspect all the 'ktrf_*' functions are assuming g77 decoration.

You can force ifort to use double underscore with -assume 2underscores

HOWEVER, I would recommend cleaning up the code and removing the assumption that the compiler will use double-underscore decoration - this is very g77 specific.

ron


All currently supported Fortran compilers which I know of for linux use the single appended underscore convention default, including gfortran.
To specify the exact name, including (or excluding) any appended underscores, use the ISO C binding rather than the double underscore option of ifort.
I don't know your arguments, so I show a single (c_float):

use iso_c_binding
interface
subroutine ktrf_open_instance(arg)bind(c,name='ktrf_open_instance__')
use, intrinsic :: iso_c_binding
real(c_float) :: arg
end subroutine ktrf_open_instance
end interface


Instead of adding a second underscore, I suggest to eliminate the entire underscore mess. Recompile all your Fortran code with the option -assume nounderscore
and do not add any leading or trailing underscores in your C/C++ code.
The whole mess with those underscores is just a misguided idea from the
60's.

For my own project I have to link the CERN Library. CERN decided a long
time ago to ditch VMS. As alternative they added more and more unix
stuff. And because all those unix clones are so compatible (cough), the
entire CERN library is totally screwed up with hacks for every unix
clone. You should see how they handle all those different concepts of
adding underscores (and other special characters). If you think that
adding one trailing underscore is "unix standard", you should see what
other unix compilers produce. And there are not only the
identifiers for the functions. Common blocks are such a nich playground
for new "conventions". One trailing underscore, two trailing
underscores, sometimes another one infront, or two, extra dollars, or
two etc.. I presume Ada2005 routines get 2005 underscores.

Because I have no time to recompile (and test!) the CERN Library on my
unix machine (Gentoo Linux), I wrote a single assembler file which adds
a few entry points to connect my software (all compiled without the
underscore mess) with the CERN Library. Here is a typical entry from
the assembler file:

.global legacy
.type legacy,@function
legacy:
jmp legacy_
.weak legacy
(problem solved for now)


Thanks very much everybody for your help, it helped a lot! Ron, I've tried what you've said and everything works correctly now. I haven't had time to try the other suggestions from tim and oh_moose, i will try that as soon as i find the time now knowing what confusion it causes.

Best,

grgur

Leave a Comment

Please sign in to add a comment. Not a member? Join today