[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

LT 2.2 series regression

From: Jeff Squyres
Subject: LT 2.2 series regression
Date: Wed, 21 May 2008 11:03:17 -0400

The Open MPI project just switched yesterday to using LT 2.2.4, AC 2.62, and AM 1.10.1 for our nightly trunk snapshot tarballs. Several developers have been using this combo for a while (including me), but using this trio for the nightly tarballs opens it up to a much wider testing audience.

We ran into a problem with last night's regression testing with the Fortran Intel compiler suite and shared libraries.

It seems that LT 2.2.x determines that the Intel ifort compiler option for building shared libraries is -KPIC (when it should be -fPIC). It then tests -KPIC, determines that it doesn't work, and then discards it. Hence, sources built with ifort have *no* PIC option, and therefore you can't build shared libraries for them. Here's the relevant output from configure (RHEL4U4, x86_64, Intel compiler suite 10.1):

checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for ifort option to produce PIC... -KPIC
checking if ifort PIC flag -KPIC works... no
checking if ifort static flag -static works... yes

The output from building is therefore fairly predictable:

libtool: compile: ifort -I../../../ompi/include -I../../../ompi/ include -I. -I. -I../../../ompi/mpi/f90 -c mpi_wtick_f90.f90 -o .libs/ mpi_wtick_f90.o /bin/sh ../../../libtool --mode=compile ifort -I../../../ompi/ include -I../../../ompi/include -I. -I. -I../../../ompi/mpi/f90 -c - o mpi_wtime_f90.lo mpi_wtime_f90.f90 libtool: compile: ifort -I../../../ompi/include -I../../../ompi/ include -I. -I. -I../../../ompi/mpi/f90 -c mpi_wtime_f90.f90 -o .libs/ mpi_wtime_f90.o /bin/sh ../../../libtool --mode=link ifort -I../../../ompi/include - I../../../ompi/include -I. -I. -I../../../ompi/mpi/f90 -export- dynamic -o -rpath /home/jsquyres/bogus/lib mpi.lo mpi_sizeof.lo mpi_comm_spawn_multiple_f90.lo mpi_testall_f90.lo mpi_testsome_f90.lo mpi_waitall_f90.lo mpi_waitsome_f90.lo mpi_wtick_f90.lo mpi_wtime_f90.lo -lnsl -lutil libtool: link: ifort -shared -nofor_main .libs/mpi.o .libs/ mpi_sizeof.o .libs/mpi_comm_spawn_multiple_f90.o .libs/ mpi_testall_f90.o .libs/mpi_testsome_f90.o .libs/ mpi_waitall_f90.o .libs/mpi_waitsome_f90.o .libs/mpi_wtick_f90.o .libs/ mpi_wtime_f90.o -lnsl -lutil -Wl,-soname -Wl, - o .libs/ ld: .libs/mpi_comm_spawn_multiple_f90.o: relocation R_X86_64_PC32 against `mpi_comm_spawn_multiple_' can not be used when making a shared object; recompile with -fPIC
ld: final link failed: Bad value

(the compile line for mpi_comm_spawn_multiple_f90.f90 was similar to that of mpi_wtick_f90.f90 and mpi_wtime_f90.f90)

I can send the entire output if necessary.

I tested LT 2.2, 2.2.2, and 2.2.4: the failure behavior is the same. I also tested the Intel compiler suite versions 9.0, 9.1, 10.0, and 10.1: same failure behavior with the Intel 10.x series, but -KPIC *works* with the Intel 9.x series. Specifically, we get this in the output from configure when using Intel ifort 9.0 and 9.1:

checking for ifort option to produce PIC... -KPIC
checking if ifort PIC flag -KPIC works... yes

...and building Open MPI works fine (the fortran shared library builds with "ifort ... -KPIC ..." and everything works properly).

But here's the kicker: until yesterday, Open MPI was using a very old LT 2.1a snapshot for building its nightly trunk tarballs (see . With that 2.1a snapshot, LT was using -fPIC (not -KPIC) for Fortran shared libraries with all versions of the Intel compiler. Additionally, LT 1.5.22 uses -fPIC for ifort shared libraries (I did not test any further in the 1.5 series).

Based on the 2.1a tarball and 1.5.22 results, this *looks* like a regression to us. Does anyone know the history of this -fPIC -> -KPIC change for ifort? It seems like using -fPIC for all versions of ifort should work properly.

Thanks for all your hard work on Libtool!

Jeff Squyres
Cisco Systems

reply via email to

[Prev in Thread] Current Thread [Next in Thread]