intel fortran linux linking problem: "undefined reference to ..." static library functions

[zbarcelos]

Hi,

I'm porting some applications from windows to linux.
I use Intel Fortran 10.0.

All sources (libraries and modules) are fortran 90 programs developed by our team.

I'm having some problems("undefined reference to...") linking compiled sources (.o) against static libraries (.a) under linux: Linux xxxxx 2.6.16.46-0.12-smp #1 SMP Thu May 17 14:00:09 UTC 2007 x86_64 x86_64 x86_64 GNU/Linux

Under windows everything goes fine. I compile some sources as libraries (.obj) and then create some (.lib) with link.exe

Under linux, I compile the same sources as libraries (.o) and then "ar rc":

# Library compilation
ifort -nologo -heap-arrays 0 -static -threads -O2 -I/libs/bin -module "." -c function1.f90 -o ./function1.o
ifort -nologo -heap-arrays 0 -static -threads -O2 -I/libs/bin -module "." -c function2.f90 -o ./function2.o
# Archive building
ar rc lib.a ./function1.o ./function2.o
ranlib lib.a

Then I use these libraries functions in my program:

# fortran executable compilation
ifort -nologo -heap-arrays 0 -static -threads -O2 -I/libs/bin -module "." -c test.f90 -o ./test.o
# fortran executable linking
ifort -o test ./test.o -Bstatic /libs/bin/dlibxx.a /libs/bin/dlibxy.a
/libs/bin/dlibxx.a(mfunct.o): In function `mqspherical_cut_mp_qspherical_cut_interpoler_':
../../../source/test.f90:(.text+0x5d77): undefined reference to `minterpo_mp_interpo_1d_cubique_cmplx_'

I can't understand why because "nm -s" shows everything goes fine in the library symbols.

I've tried some variants (changing options to see how it reacts, as "Bstatic" or not running ranlib after ar).

Nothing seems to change.

The interesting part is that if I avoid the archive building process and link directly to functions:
ifort -o test ./test.o ./function1.o ./function2.o

Everything goes correctly and the binary is built and runs fine.

Does somebody know how to correct this problem ?
The point is I would like to keep the static library idea for linking instead of a lot of objects.


Thank you,
Fabio Barcelos

[Kevin_D_Intel]

Hi Fabio,

I received a similar report in the past but never received any reproducing sample to work with andwasnever successful at recreating this situation no mater the relationship created between the main program and modules placed into the staticlibraries.

Would you be willing to provide us with a reproducing sample that we could investigate further?

You can either post the source files in this public forum or if you prefer, open a Intel Premier Support issue and attach the files to your issue.

[jimdempseyatthecove]

Kevin,

When searching your documentation for "undefined reference" the prhase is not found. When searching Visual Studio help files entries are found for the phrase, but nothing in the context of the users situation. So this seems like a void in your documentation (error message not in index), and is something that should be addressed (verify that all error messages are in the documentation and are findable by way of search).

Jim

[jimdempseyatthecove]

Fabio,

This may be a situation where case of the name and/or prefix/suffix (leading or trailing "_") or lack thereof. Check to see if consistent between declaration and deffinition.

A second cause is where you may have an expression using what you think is an array but due to typing error the compiler assumes is an external function call. This can be detected by using IMPLICIT NONE (and/or gen interfaces/check interfaces).

Jim Dempsey

[Kevin_D_Intel]

This is a Linux ld issued error, not ifort, but perhaps some mention in the docs is possible to aid with the understanding.

I do not suspect this is a name decoration issue because as Fabio stated, the link succeeds with linking the objects directly and his verifying via nm the symbol in question is present in the static library.

[Ron_Green]

I tend to agree with Kevin, this does like like a Linux ld issue.

Fabio, what distribution and version of Linux do you use? ( Ubuntu 7.10 for example)

AND what is the output of:

ld --version

AND, finally,

ifort -V

we'll see if we can reproduce.

ron

[TimP]

ifort 10.1.012 corrected some problems in the creation of the script which is passed to ld, so I wouldn't trust any earlier version. ifort -# will show what is passed to ld.
Also, as Ron indicated, ld version could be an issue. binutils 2.17.50 is probably the oldest satisfactory one. 2.18.50 is current, but not provided with many distros.

[zbarcelos]

Hi,

Thanks for your reactivity.

I found a way to solve the problem.
And I've forgot to tell you that my high-level(EM field simulation) libs are dependent on my low-level libraries (I/O and error management, math functions).

Let's suppose that my libs are: lib_a.a, lib_b.a and lib_c.a

lib_c.a uses lib_a.a functions. So do lib_b.a.

In the linking command line we must:
ifort -o bin {OBJS} lib_c.a lib_b.a lib_a.a
to avoid undefined references.

This solves my problem. I have to admit I could try this before, but, in windows, I didn't need to place correctly my libraries.

I just wanted to know if this is a bug or if it is really the way things should be. Nevertheless, this should be pointed out in the documentation.
Or is it the GNU linker (ld) fault ? My ld version is "GNU ld version 2.16.91.0.5 20051219 (SUSE Linux)"

I know Intel Fortran is just the compiler (and you don't own the linker), but to the user's point of view, it is a solution to build binaries.

If the problem interests you, I can find a way to provide the sources that reproduced the problem.

Thank you for you attention,
Fabio Barcelos
Thales Alenia Space - Toulouse - FR

[zbarcelos]

Sorry, I forgot to post my compiler version:
ifort --version
ifort (IFORT) 10.1 20080212
Copyright (C) 1985-2008 Intel Corporation. All rights reserved.


And one post says that there was possibly a problem with prefix/suffix, but all undefined references where found in the "nm -s" output of the library in question.

Thanks,
Fabio Barcelos
Thales Alenia Space - Toulouse - FR

[Kevin_D_Intel]

Thank you for the extra details Fabio. This is not a compiler or linker bug but rather just as you stated it, it is really the way things should be. Each is working as expected.

You can read more about how ld only searches archives once on the ld man page under the --start-group archives --end-group option discussion, and how this option permits specifying a group of archives that "are searched repeatedly until no new undefined references are created".

What likely happened with your initial failed links is the specified library order did not satisfy all external references to routines resident in the libraries after they were searched only once. Therefore, instead of ordering the libraries as you did to resolve the issue you can likely use the linker option and library order as follows:

--start-group lib_a.a lib_b.a lib_c.a --end-group

Use the ifort -Xlinker option to pass this option the linker as follows:

ifort -o bin {OBJS} -Xlinker --start-group lib_a.a lib_b.a lib_c.a --end-group

Please let us know if you try the --start-group/--end-group and if that works.

Thank you again for the details. We wish you well going forward with our compiler.

[zbarcelos]

Hi again,

Indeed it works ( the option is: -Xlinker --start-group -Xlinker $(LIBS) -Xlinker --end-group ).

Thank you for your support,
Fabio Barcelos - Electromagmetic Field Simulation Engineer
Thales Alenia Space - France