Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

linking C, Fortran is generating unresolved references

Dane_A_
Beginner
843 Views

I have been tasked with porting an application from the AIX environment to the suse-linux environment.

The application contains 3 executables, which I will call app1, app2, and app3.

I am using the intel 64 bit fortran compiler, and the cc that comes with suse-linux.

FC=/ots/sw/Intel/compilers_and_libraries_2016.1.150/linux/bin/intel64/ifort

CC=/usr/bin/cc

App1 is all Fortran. It compiles and links with no errors.

App2 is a mix of Fortran and C with a Fortran program statement linked using FC. It compiles and links with no errors

App3 is a mix of Fortran and C with a C main. All the source compiles with no errors

When I attempt to link app3 however the spit hits the fan. Linked using FC I get multiple main defined errors, and

MANY undefined references such as __intel_security_cookie, for_cpystr, for_emit_diagnostic (note: this is NOT

an exhaustive list of undefineds, just an example). Linked using CC I get the same undefined references (at least

I don't get the multiple main defined errors).

 

By using objdump I found a few libraries that contained the symbol intel_security_cookie (please note the lack of leading __),

for_cpystr, and for_emit_diagnostic. I elected to try to use

/ots/sw/Intel/compilers_and_libraries_2016.1.150/linux/mpi/intel64/lib/libmpigi.a  for the intel_security_cookie undefined

and
/ots/sw/Intel/compilers_and_libraries_2016.1.150/linux/compiler/lib/intel64_lin/libifcore.a for the for_* for the other

undefineds.

(note the for_* symbols do exist in that lib without the leading __). The problem is, that did NOT resolve ANY of the

unresolved references.

So, what am I not doing that would get the symbols resolved?

Note: the main is in r165.o which is in C_OBJS.

DEPLIB is the list of libraries used, EXTLIBS is the same list in -L -l form (where a .so would not get sucked in instead of the .a)

 

SYSLIBs = -L/usr/lib64 -lX11 -lm -ly \
          /ots/sw/Intel/compilers_and_libraries_2016.1.150/linux/mpi/intel64/lib/libmpigi.a \
          /ots/sw/Intel/compilers_and_libraries_2016.1.150/linux/compiler/lib/intel64_lin/libifcore.a

r165.exe: $(F_OBJS) $(C_OBJS) $(PC_OBJS) $(DEPLIB) $(ORA_LIB)
        $(CC) -g -o r165.exe $(F_OBJS) $(C_OBJS) $(PC_OBJS) $(EXTLIB) \
                             $(ORACLELINKLIBS) $(LIBHOME)/libclntsh.so.12.1 \
                             $(SYSLIBS)

 

0 Kudos
11 Replies
Steven_L_Intel1
Employee
842 Views

You should be using FC for the link, but you say this also fails. Did you "source" the compiler environment (<source install-dir>/bin/ifortvars.sh)? That you are referencing an explicit path to ifort makes me think you're trying to set this up by hand. Which objects/libraries are the missing references coming from? 

libifcore.a and libirc_s.a (I think) should resolve the symbols you name. 

0 Kudos
mecej4
Honored Contributor III
843 Views

When you wish to build mixed Fortran and C programs using "legacy" linkage, your code needs to conform to the name decoration rules of the specific compilers and the platform. These rules are probably quite different in AIX and Linux. Please see the Mixed Language Programming chapter of the Intel Fortran documentation, https://software.intel.com/en-us/node/524874 .

0 Kudos
Steven_L_Intel1
Employee
843 Views

That shouldn't be an issue for compiler-generated references, which are the ones listed in this thread.

There's a lot of description here and not much actual code/commands one could use to understand the problem. Any chance of a tarball with a minimal example? A log of the commands used by the makefile and all the build output would also be handy.

0 Kudos
mecej4
Honored Contributor III
843 Views

Steve Lionel (Intel) wrote:

That shouldn't be an issue for compiler-generated references, which are the ones listed in this thread.

I was responding to the line "note the for_* symbols do exist in that lib without the leading __" in #1.

There's a lot of description here and not much actual code/commands one could use to understand the problem. Any chance of a tarball with a minimal example? A log of the commands used by the makefile and all the build output would also be handy.

Seconded.

0 Kudos
Steven_L_Intel1
Employee
843 Views

For the leading underscore thing, I was thinking about 32-bit vs. 64-bit as it is on Windows, but on Linux there is no underscore prefix on user routines. Intel Fortran does follow the Linux/Unix convention of a trailing underscore for Fortran.

Seeing the actual build output and, one hopes, a small test case, would allow a prompt solution.

0 Kudos
Dane_A_
Beginner
843 Views

A tarball is not possible for two reasons. 1) for some reason I am denied execute to tar. And more importantly

2) sending that tarball would violate company policy, and possibly US ITAR regulations. I'm pushing it as it is

already.

 

The shell variables are being set up by executing (FC among them):

module load $moduleHome/$moduleSpec

moduleHome=/boeing/modulefiles/intel/compiler

moduleSpec=64/16.0/2016.1.150

Adding libirc_s.a (libifcore.a was already on the link command line) did nothing.

 

Linking using CC I still get undefineds starting with

`__intel_security_cookie'

obj/abortrn.o: In function `abortrn':
/panfs/pan-ewd-z06-r001.panfs.cs.boeing.com/q012/InfoTech/Sws/dtanal/r165/dvlp/abortrn.f:1: undefined reference to `__intel_security_cookie'
/panfs/pan-ewd-z06-r001.panfs.cs.boeing.com/q012/InfoTech/Sws/dtanal/r165/dvlp/abortrn.f:37: undefined reference to `for_cpystr'
/panfs/pan-ewd-z06-r001.panfs.cs.boeing.com/q012/InfoTech/Sws/dtanal/r165/dvlp/abortrn.f:38: undefined reference to `for_cpystr'
/panfs/pan-ewd-z06-r001.panfs.cs.boeing.com/q012/InfoTech/Sws/dtanal/r165/dvlp/abortrn.f:48: undefined reference to `for_cpstr'
/panfs/pan-ewd-z06-r001.panfs.cs.boeing.com/q012/InfoTech/Sws/dtanal/r165/dvlp/abortrn.f:62: undefined reference to `for_cpstr'
/panfs/pan-ewd-z06-r001.panfs.cs.boeing.com/q012/InfoTech/Sws/dtanal/r165/dvlp/abortrn.f:65: undefined reference to `for_emit_diagnostic'
/panfs/pan-ewd-z06-r001.panfs.cs.boeing.com/q012/InfoTech/Sws/dtanal/r165/dvlp/abortrn.f:65: undefined reference to `for_emit_diagnostic'
/panfs/pan-ewd-z06-r001.panfs.cs.boeing.com/q012/InfoTech/Sws/dtanal/r165/dvlp/abortrn.f:66: undefined reference to `for_emit_diagnostic'
/panfs/pan-ewd-z06-r001.panfs.cs.boeing.com/q012/InfoTech/Sws/dtanal/r165/dvlp/abortrn.f:66: undefined reference to `for_emit_diagnostic'
/panfs/pan-ewd-z06-r001.panfs.cs.boeing.com/q012/InfoTech/Sws/dtanal/r165/dvlp/abortrn.f:72: undefined reference to `for_emit_diagnostic'

(note there are a few more for_ undefineds, mostly having to do with fortran strings)

 

Linking using FC I don't get the

`__intel_security_cookie'

or the for_* undefineds, but EVERY XWindow function call from the C code generates an undefined error.

A non-exhaustive example of the errors follows:

obj/display_image.o: In function `Gdspimg':
display_image.c:(.text+0x1142): undefined reference to `XCreateGC'
display_image.c:(.text+0x118c): undefined reference to `XGetImage'
display_image.c:(.text+0x13b9): undefined reference to `XPutImage'
display_image.c:(.text+0x13e0): undefined reference to `XFreeGC'
/home/m/mmn3244/swslibs/libsawgr.a(gwchatt.o): In function `Ggwchatt':
gwchatt.c:(.text+0x1af): undefined reference to `XChangeWindowAttributes'
gwchatt.c:(.text+0x1da): undefined reference to `XChangeWindowAttributes'

Note: ALL of those ARE defined in libX11.a

in the libraries following, explicit paths are the result of a non-lib---.a file name, or a .so file in

the same directory. For some reason both the FC and CC linker want to pull in the .so rather than

the .a. We want the executable linked statically. We do NOT want them linked to shared libraries.

EXTLIB= -L/boeing/sw/sws/lib -L/home/m/mmn3244/swslibs \
        -L$(SAWGRHOME) -L/boeing/lib/bcslibs/bcslibs.4/lib64/intel/kind=4 \
        -L/boeing/lib/bcslibs/bcslibs.4/lib64/intel -L../../externals \
        -L/cm/images/compute-image/usr/lib64 \
        -lstress -lgau -lsawgr -lutil -lpuppet -lXpiglet -lprinter -ltool \
        -lMagickCore \
        /ots/sw/osstoolkit/15.1/sles11-x86_64/lib/libjpeg.a \
        /ots/sw/osstoolkit/15.1/sles11-x86_64/lib/libpng.a \
        /ots/sw/osstoolkit/15.1/sles11-x86_64/lib/libtiff.a \
        /ots/sw/osstoolkit/15.1/sles11-x86_64/lib/libz.a \
        -lbcsext -lbcslib -lbcslibc -lqs -lutil -lbcslib

SYSLIBs = -L/usr/lib64 -lX11 -lm -ly \
          /ots/sw/Intel/compilers_and_libraries_2016.1.150/linux/mpi/intel64/lib/libmpigi.a \
          /ots/sw/Intel/compilers_and_libraries_2016.1.150/linux/compiler/lib/intel64_lin/libifcore.a \
          /ots/sw/Intel/compilers_and_libraries_2016.1.150/linux/compiler/lib/intel64_lin/libirc_s.a

 

r165.exe: $(F_OBJS) $(C_OBJS) $(PC_OBJS) $(DEPLIB) $(ORA_LIB)

(I move and comment out the build rule I am NOT using. ORACLELINKLIBS is NOT defined. It's there

for consistancy with other makefiles we are using) DEPLIB and ORA_LIB list out the libraries for make dependency

they are included in EXTLIB and SYSLIB

        $(CC) -g -o r165.exe $(F_OBJS) $(C_OBJS) $(PC_OBJS) $(EXTLIB) \
                             $(ORACLELINKLIBS) $(LIBHOME)/libclntsh.so.12.1 \
                             $(SYSLIBS)

       $(FC) -g -nofor-main -fexceptions -o r165.exe $(F_OBJS) $(C_OBJS) \
                            $(PC_OBJS) $(EXTLIB) $(ORACLELINKLIBS) \
                            $(LIBHOME)/libclntsh.so.12.1 $(SYSLIBS)

 

 

0 Kudos
Steven_L_Intel1
Employee
843 Views

Ok - this is not the same as you described before. Using ifort to link resolves the Intel libraries correctly. So now it's just the xlib issue, yes? Can you see the exact line being sent to ifort including libraries to link against? Which xlib libraries you link to should be entirely under your control.

0 Kudos
Dane_A_
Beginner
843 Views

THANK YOU! Getting the answer to your question, gave me MOST of the answers I needed.

I was defining:

SYSLIBs in the code. That contained -lX11.

In the build rule I was USING:

SYSLIBS Which wasn't defined anywhere.

In the font I use in my XTerms (so I can actually READ the things), the upper and lower case S do not differ in size

very much. Thus I could see that libX11.a was in the SYSLIBs and that SYSLIBS was on the build line. What I

didn't notice was that -lX11 did NOT appear in the output from make when it ran the linker. Fixing that upper

case vrs. lower case problem got rid of MOST of my undefineds. adding libXext.a got rid of the rest. The only

remaining problem is the following error (Note: I don't know WHO to report this bug to, or what to do about it):

ld: BFD (GNU Binutils; SUSE Linux Enterprise 11) 2.23.1 internal error, aborting at ../../bfd/reloc.c line 444 in bfd_get_reloc_size

ld: Please report this bug.

make: *** [r165.exe] Error 1

 

 

Googleing this bug shows that this is a known bug in the red hat world. I am on suse though. And I still don't

have a clue as to WHO to report it to, or what to do to avoid it.

 

0 Kudos
Steven_L_Intel1
Employee
843 Views

That would be a gcc issue. I think they use some sort of bugzilla tracking system for reporting bugs. https://gcc.gnu.org/bugs/

Sorry I can't help with "what to do about it".

0 Kudos
Dane_A_
Beginner
843 Views

I'm not sure that link is going to be useful to me. In their "what we don't want" section, they state they don't want:

 

  • Bugs in the assembler, the linker or the C library. These are separate projects, with separate mailing lists and different bug reporting procedures

Since this is clearly a linker problem, I am left wondering who the linker writer wants me to report the bug to.

0 Kudos
TimP
Honored Contributor III
843 Views

sourceware.org/bugzilla

0 Kudos
Reply