- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 .
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
sourceware.org/bugzilla
![](/skins/images/7FC17B7B85029576C25F1E43CE255B51/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page