ifort 8.1, icc 8.1, and fftw

[vblum]

I have tried in vain to get an application, built with ifort version 8.1, to link against the fftw3 library. Below are some attempts.

(i) link application against system-prebuilt libfftw3 (system is SUSE Linux 9.1, gcc version is 3.3.3):

This should work in principle. Linking is only possible against the .so version of the non-ifort library. The .a version claims missing symbols, although all relevant symbols are included with one and two underscores appended.

The version linked against .so runs without crashing. however produces bogus results.

(ii) Build fftw3 using CC=icc, FC=ifort : This does not work (in the configure file) unless one specifies all Fortran libraries by hand. Otherwise, the configure command attempts to include a bogus library -lm" (yes, the " is correct) and stops.

Including the fortran libraries by hand produces a complete .a archive, now compiled with icc / ifort. However, it is not possible to link against this newly built .a archive. ifort continues to claim that the relevant symbols cannot be found.

(iii) same build, but with shared object files:

Miraculously, it is possible to link against (ifort-built) shared objects from the same build. When the ensuing executable is executed, the program terminates with this error:

error while loading shared libraries: undefined symbol: _intel_fast_memset

Here I am at wit's end. This has cost me hours, so far, with no success. Does anyone have an answer to this? Specific questions are also welcome.

Thanks

Volker Blum

[TimP]

All right, as no one else appears to have understood your questions, I'll take a stab.

Are you asking whether ifort has the ability to use the same double appended underscore conventions as g77 uses by default? No, it doesn't. If you're trying to force a link with such mis-matches, I don't think you could expect .so link to help you.

If you build C code with icc, you should not be surprised that a memset() call would invoke a special memset() from the libraries which come with icc. If you are not using ifort to drive the link, you would need to find out all the libraries used from the Intel compiler installations, and specify linking them in the proper order.

[vblum]

Thanks very much for the reply, and sorry that my questions were unclear. I was describing three different attempts to link an application, compiled with ifort 8.1 ( version l_fc_p_8.1.018 ), against an instance of the libfftw library.

Key points:

* I found myself unable to link against a static library archive of libfftw ( "libfftw3.a" ) using my present version of ifort. ifort claims that it cannot resolve any symbol that it should get from libfftw. From a visual inspection of the library archive, I am certain that the relevant symbols are in the archive and have the right number of underscores.

* In particular, ifort claims that symbols are missing _independent_ of the compiler used to build fftw - gcc/g77 or icc/ifort . At least for an icc build of a static library archive, I would have expected all symbols to be archived correctly.

* In contrast, I am always able to link against shared object (.so) versions of libfftw, created from the same builds as the .a versions . However, _running_ the actual executable fails for various reasons (depending on the compiler used to build fftw).

Is ifort actually capable of linking against a static library archive (lib*.a) ?

Thanks again,

Volker Blum

[Steven_L_Intel1]

Yes, ifort supports linking against static libraries. Keep in mind that ifort is just invoking ld here.

[vblum]

Hm, that's what I thought; sorry about the blunt question.

Is there any reason why ld would fail to find the required symbols in the .a archive, in the case that the code in the archive was built with the same compiler(s) as my own separate code?

[Is there any specific information that I could provide beyond my general description of the problem?]

[Steven_L_Intel1]

It would help if you'd list the unresolved symbols. I don't see that you have done so. Also let us know which libraries you ARE linking against.

[vblum]

OK, here is the more detailed information:

* Compiler call (my own):

ifort -O0 -c mc_main.bcc.f

[etc - many of the same type]

* Linker line:

ifort -O0 -L/usr/local/fftw-3.0.1/lib -lfftw3-own -o ../../bin/mc.bcc.linux mc_main.bcc.o recipe_fftw.o random.num.o
initialize_spins.o rotate.o index.o samefig.o icart.o ivol.o mdc.o printpi.o rjstrain.o rjpair.o period.bcc.o gamma_nl.o

[excuse the many subroutines, the important bit is that I link against something called fftw3-own in /usr/local/fftw-3.0.1/lib]

* Error messages:

recipe_fftw.o(.text+0x55b): In function `recipe_':
: undefined reference to `dfftw_plan_dft_c2r_3d_'
recipe_fftw.o(.text+0x56b): In function `recipe_':
: undefined reference to `dfftw_execute_'
recipe_fftw.o(.text+0x579): In function `recipe_':
: undefined reference to `dfftw_destroy_plan_'

[repeated for more calls of the same kind]

* Content of directory /usr/local/fftw-3.0.1/lib :

total 1021
drwxr-xr-x 3 root root 176 2004-10-19 16:27 .
drwxr-xr-x 7 root root 168 2004-10-18 11:02 ..
-rw-r--r-- 1 root root 1039128 2004-10-18 14:56 libfftw3.a
-rwxr-xr-x 1 root root 728 2004-10-18 14:56 libfftw3.la
lrwxrwxrwx 1 root root 10 2004-10-18 13:25 libfftw3-own.a -> libfftw3.a
drwxr-xr-x 2 root root 72 2004-10-18 14:56 pkgconfig

[Notice that the softlink of fftw3-own is irrelevant. I only use it as an extra safeguard to avoid any accidental linking against potential other fftw3 libs on the system.]

* The fftw3 archive in question was built using ifort / icc.

Sorry for the amount of information - this is what I thought relevant.

I apologize if this is something trivial; at the same time, I would be quite relieved.

Again, thanks very much for the feedback so far!

Volker Blum

[Steven_L_Intel1]

Ok, have you done a "names" (or whatever it is in Linux, I forget) on the fftw library to see what names it defines? I am going to take a wild guess that it omits the trailing underscore, which is a UNIX Fortran convention, or maybe puts two underscores there for g77. If so, you'll have to rebuild it with the proper convention specified.

[vblum]

Hm ... this is the output - hope I understood you correctly:

blum@blum:/usr/local/fftw-3.0.1/lib> nm libfftw3-own.a |grep dfftw
00000330 T dfftw_cleanup_
0000030c T dfftw_destroy_plan_
000002e6 T dfftw_execute_
000008a0 T dfftw_execute_dft_
[... many more ...]

(I had previously verified this directly in emacs because I usually can't really remember the "nm" command either ... but, both concur.)

[Nevertheless - ld finds the .a library, tries to link using symbols which are all present, and does not find them. At the same time, exactly the same linker command line works flawlessly with a .so library.]

[Steven_L_Intel1]

I'm not a Linux expert, so I've reached the end of my list of suggestions.

[vblum]

Hm. I guess my linker line above and the output from nm didn't strike anyone as obviously wrong.

My preliminary conclusion from this is therefore:

ifort 8.1 version l_fc_p_8.1.018 on SUSE Linux 9.1 calls ld in a way which prevents any linking against a static library archive. Linking against shared objects works.

I suggest this is likely a bug in ifort 8.1, as I can link against .a archives using e.g. g77 or g95.

[Hirchert__Kurt_W]

Probable short solution: move "-lfftw3-own" to the end of the ifort statement on which it appears.

Explanation: In nearly all of the Unix/Linux ld implementations I have encountered, the -l option causes the specified library to be searched once at the point it is encountered. Since you put your -l option _before_ your *.o files, the library was searched before ld had references to resolve from it. (For people doing Unix/Linux support, this is a frequently asked question.)

[vblum]

Bingo. Linking works in different order.

Wow. I could use the exact same makefile (compilers changed) for g95 and for the Portland group compiler, and both linked correctly. I was absolutely certain of that line itself. Oh well.

Now if I could only figure out why my little program gives correct results when everything is built with the Portland group compiler, but gives bogus results both for ifort 8.1. and g95 (which is very experimental anyway). But, that question is certainly _not_ for this forum.

Thanks again!

[Steven_L_Intel1]

Thanks for the help!

[Keith_R_]

This is a slight fork of topic from the main one, but one I hope
will be useful to others attempting to use FFTW with the Intel compilers.
Perhaps it might be better replicated to the C compiler list as well, but
I don't know how to "crosspost" in these fora.

First, I'll echo part of a comment I received from one of the FFTW people,
during an exchange on some of the problems I had compiling FFTW 3.x

> Right, I keep forgetting, there is a problem with icc 8.x, mostly because
> falsely claims to be gcc. If I remember correctly, a workaround is:
>
> 1) use CC="icc -no-gcc" when configuring
>
> 2) insert "#undef __inline" in simd-sse.h and simd-sse2.h before
> "#include ".

Second, I need to warn you that FFTW 2.1.5 compiled with icc 8.0.066
on the IA64 platform gives incorrect results under certain rare conditions.
I managed to waste a considerable amount of time tracking down a
subtle and not readily apparent bug in a plane-wave electronic structure code.
This turned out to be entirely the fault of the icc-compiled FFTW library I
was linking with. In fact FFTW failed it's own self-tests, crashing with
a SEGV during a "make check".

This appears to be fixed in icc 8.1.

[vblum]

Thanks!

I followed this advice (except that the relevant line in simd-sse2.h seems to read "#include ") ; fftw compiles fine, but the result of my own, ifort-built application [which is linked to libfftw3) is still a random number, as before.

I am only posting this here for the sake of completeness. The above may or may not be an ifort problem, and may or may not be a problem of my particular call to fftw3. What I know is, this same code works with the Portland Group compilers.