Linking mixe C/Fortran programs

[ssabpablo]

Hi I have a mixe project where i try to link (ld) a compiled C-program with several compiled (ifort) fortran subroutines. Unfortunately I get some error-messages from the linker that I can't understand. Can somebody give me a hint where to look. ****** All fortran modules built for tprd ****** ****** All c-modules built for as_tprd ****** /usr/local/intel_fc_80/lib/libifcoremt.a(for_open_proc.o)(.text+0x3826): In function `for__compute_filename': : warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/intel_fc_80/lib/libifcoremt.a(for_open_proc.o)(.text+0x3909): In function `for__compute_filename': : warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/intel_fc_80/lib/libifport.a(utility_c2fstr.o)(.text+0x9b): In function `CstrToFstr': : undefined reference to `for_errsns_load' /usr/local/intel_fc_80/lib/libifport.a(utility_c2fstr.o)(.text+0xb8): In function `CstrToFstr': : undefined reference to `for_errsns_load' collect2: ld returned 1 exit status make: *** [/data1/pwrp/vkvamn/x86_linux/exe/as_tprd] Error 1 I use Debian GNU/Linux 2.6.4 and Intel Fortran Compiler for LINUX v8.1 My link command (in a makefile) looks like: @ $(ld) $(linkflags) -o $(target) $(source) -L$(pwrp_cmn)/x86_linux/lib -lpwrp_vkv -lpwrp -lpwr_rt -lpwr_co -lpwr_rs -lpwr_msg_dummy -lrpcsvc -lpthread -lm -lrt -L/usr/local/intel_fc_80/lib -static -lcxa -lifcoremt -lcprts -lcxaguard -lguide -lguide_stats -lifcore -lifcore_pic -lifcoremt_pic -lifport -limf -lirc -lirc_s -lompstub -lsvml -lunwind wher 'linkflags' looks like; -g -L/usr/local/lib -L$(pwr_lib) -L$(pwrp_lib) -lrt The references in the error-messages are not explicitly used in any of my program-units, neither are they present in my symbol lists. Regards Pablo

[TimP]

When you invoke ld directly, rather than using ifort, you take on the responsibility of specifying the libraries from your compiler installation in the correct order. If you go about it this way, you almost certainly will need to search the libraries for the missing symbols by using nm, then correct your link script. You will need to change things around each time you change compiler or distro versions.
The warnings about ld not knowing whether libc.so will be required at run time (or whether the link is even set up correctly) are associated with the way you have set up indirect references to libc from both dynamic and static linked code. More often than not, it will work in spite of the warnings.

[ssabpablo]

Hi again

Sorry about the state of my 1:st entry. Have no idea why it became so messy.

Glad for your quick reply, but the answer puzzles me a bit.

The warnings I understand, I would only be glad if I could remove/inhibit the warnings for this item.

The missing reference is something else because these means I get no executable.

If I had any hint about what is causing the reference to 'for_errsns_load' or what is calling the CstrToFstr-function I would be glad.

The executable should unfortunately contain one medium sized C-routine (written by me) and 45 Fortran Subroutines written originally by a research institute. This executable works well on a VMS platform but should now be transferred to a Linux platform, Hence my problems.

I have searched the library libifport.a with nm, found the mentioned references but am no wiser anyway.

If I interpret your answer I think you give me the advise either to transform my

C-routine to fortran, and use fortran all through, or transform my fortran routines to C and use gcc all through. Is that correct?

The project will probably have a lifetime of 10 + years so I don't want to have this problem every time I upgrade something (compiler, kernel a.s.o.)

Can I create some sort of list-file/map showing what routine causes the call of the function?

Cheers

Pablo

[TimP]

You will certainly have this problem until you adopt a more normal way of linking. You can't expect each system you run on to have its run-time libraries laid out the same way. Doesn't using ifort to drive the link give you any clues? If you aren't doing anything unusual in C (such as sneaking in some C++), that should help you move ahead. Don't do fancy things with combinations of static and dynamic until you get it working. Don't do it anyway until you have a reason.
Your original diagnostics told you where the missing reference occurs. What you want to find out, if you persist in invoking ld directly, is which of the compiler libraries resolve the missing reference.