Re: Unwanted shared runtime libraries getting added
* Ethan Mallove wrote on Fri, Dec 10, 2010 at 07:41:20PM CET: > On Thu, Oct/21/2010 06:13:03AM, Ralf Wildenhues wrote: > > Pass -Wc,-static-intel instead. > > This works like a charm for shared libraries, but for standalone > executables I get an error like this: > > ... > icc: command line warning #10156: ignoring option '-W'; no argument required > /bin/sh ../../../libtool --tag=CC --mode=link icc -Wc,-static-intel -g > -finline-functions -fno-strict-aliasing -restrict -pthread > -fvisibility=hidden -export-dynamic -o orte-iof orte-iof.o > ../../../orte/libopen-rte.la -lnsl -lutil > libtool: link: icc -Wl,-static-intel -g -finline-functions > -fno-strict-aliasing -restrict -pthread -fvisibility=hidden -o .libs/orte-iof > orte-iof.o -Wl,--export-dynamic ../../../orte/.libs/libopen-rte.so -ldl > -lnsl -lutil -pthread -Wl,-rpath -Wl,$ORIGIN -Wl,-rpath -Wl,$ORIGIN/.. > -Wl,-rpath -Wl,$ORIGIN/../lib > ipo: warning #11015: Warning unknown option -static-intel > ld: unrecognized -a option `tic-intel' > > Do you know of a way to get this working in both cases: shared libs > and standalone executable? Yes. Use Libtool 2.2.8 or newer. Quoting from the NEWS file: - Fix ancient bug where "-Wc," was turned into "$wl" (typically "-Wl,") when using the compiler driver to link programs. Now "-Wc," is stripped just as it is when linking libraries through the compiler driver. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Unwanted shared runtime libraries getting added
On Thu, Oct/21/2010 06:13:03AM, Ralf Wildenhues wrote: > Hello Ethan, > > * Ethan Mallove wrote on Wed, Oct 20, 2010 at 10:32:11PM CEST: > > > It looks like that gives us the link line we want, yet we still get the > > > libimf.so dependency: > > > > > > $ /bin/sh ../../../libtool --tag=CC --mode=link icpc -O3 -DNDEBUG > > > -Wall -static-intel -m64 -finline-functions -fexceptions -pthread > > > -version-info 0:0:0 -export-dynamic -fexceptions -o libmpi_cxx.la > > > -rpath /opt/SUNWhpc/HPC9.0/intel/lib/lib64 mpicxx.lo intercepts.lo > > > comm.lo datatype.lo win.lo file.lo ../../../ompi/libmpi.la -lnsl -lutil > > > libtool: link: icc -shared .libs/mpicxx.o .libs/intercepts.o > > > .libs/comm.o .libs/datatype.o .libs/win.o .libs/file.o -Wl,-rpath > > > -Wl,$ORIGIN -Wl,-rpath -Wl,$ORIGIN/.. -Wl,-rpath -Wl,$ORIGIN/../../lib/64 > > > -Wl,-rpath -Wl,$ORIGIN -Wl,-rpath -Wl,$ORIGIN/.. -Wl,-rpath > > > -Wl,$ORIGIN/../../lib/64 ../../../ompi/.libs/libmpi.so -ldl -lnsl -lutil > > > -m64 -pthread -pthread -Wl,-soname -Wl,libmpi_cxx.so.0 -o > > > .libs/libmpi_cxx.so.0.0.0 > > > $ ldd .libs/libmpi_cxx.so.0.0.0 > > > libmpi.so.0 => not found > > > libdl.so.2 => /lib64/libdl.so.2 (0x2b35a9499000) > > > libnsl.so.1 => /lib64/libnsl.so.1 (0x2b35a969e000) > > > libutil.so.1 => /lib64/libutil.so.1 (0x2b35a98b6000) > > > libimf.so => not found > > > libsvml.so => not found > > > libm.so.6 => /lib64/libm.so.6 (0x2b35a9aba000) > > > libintlc.so.5 => not found > > > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x2b35a9d3e000) > > > libpthread.so.0 => /lib64/libpthread.so.0 (0x2b35a9f4c000) > > > libc.so.6 => /lib64/libc.so.6 (0x2b35aa167000) > > > /lib64/ld-linux-x86-64.so.2 (0x003a2000) > > > > The problem is that Libtool is stripping -static-intel from the link > > line. How can I prevent this? > > Pass -Wc,-static-intel instead. This works like a charm for shared libraries, but for standalone executables I get an error like this: ... icc: command line warning #10156: ignoring option '-W'; no argument required /bin/sh ../../../libtool --tag=CC --mode=link icc -Wc,-static-intel -g -finline-functions -fno-strict-aliasing -restrict -pthread -fvisibility=hidden -export-dynamic -o orte-iof orte-iof.o ../../../orte/libopen-rte.la -lnsl -lutil libtool: link: icc -Wl,-static-intel -g -finline-functions -fno-strict-aliasing -restrict -pthread -fvisibility=hidden -o .libs/orte-iof orte-iof.o -Wl,--export-dynamic ../../../orte/.libs/libopen-rte.so -ldl -lnsl -lutil -pthread -Wl,-rpath -Wl,$ORIGIN -Wl,-rpath -Wl,$ORIGIN/.. -Wl,-rpath -Wl,$ORIGIN/../lib ipo: warning #11015: Warning unknown option -static-intel ld: unrecognized -a option `tic-intel' Do you know of a way to get this working in both cases: shared libs and standalone executable? -Ethan > > Cheers, > Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: PIC flags not found for mpif77(ifort)
Hello Christian, * Christian Rössel wrote on Fri, Dec 10, 2010 at 02:56:51PM CET: > ./configure --enable-shared F77=mpif77 ... > > where mpif77 translates to > > ifort -I/opt/parastation/mpi2-intel/include > -L/opt/parastation/mpi2-intel/lib -Wl,-rpath > -Wl,/opt/parastation/mpi2-intel/lib -lmpich -lpthread > -L/opt/parastation/lib64 -Wl,-rpath,/opt/parastation/lib64 > -Wl,--enable-new-dtags -lpscom -lrt > > configure fails in finding PIC flags (mpicc (icc) and mpicxx (icpc) PIC > flags are discovered though): > > configure:17627: checking for mpif77 option to produce PIC > configure:17899: result: > > There is no more output concerning the PIC flags in config.log. > With F77=ifort everything works as expected: > > configure:16805: checking for ifort option to produce PIC > configure:17077: result: -fPIC Yeah, that's because libtool.m4 macros partly match by name, unless the compiler claims to be GCC. A bit dumb, sure, but it's not easy to avoid because portable testing of these flags is not trivial. We might have to think about a more general way to extract the compiler name from an MPI driver (-show and -showme come to mind). For the moment you should be able to work around it using configure lt_cv_prog_compiler_pic_F77=-fPIC \ lt_cv_prog_compiler_pic_FC=-fPIC \ but I'm not sure if you also need fixes for missing -static and -Wl, flags (lt_prog_compiler_wl_F77 and lt_prog_compiler_static_F77 ...). This requires Libtool >= 2.4. Alternatively, the untested patch below should help as well. Can you try it out? Thanks for the report, Ralf Fix PIC flags with mpif77 using ifort on GNU/Linux. * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux]: Match Intel compiler also using $CC -V output, to avoid false negatives with compiler drivers like mpif77. Report by Christian Rössel. diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index 1f61140..e735c75 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -4338,6 +4338,11 @@ m4_if([$1], [CXX], [ _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' ;; +*Intel*\ [CF]*Compiler*) + _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' + _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC' + _LT_TAGVAR(lt_prog_compiler_static, $1)='-static' + ;; esac ;; esac ___ http://lists.gnu.org/mailman/listinfo/libtool
PIC flags not found for mpif77(ifort)
Dear list, if I call ./configure --enable-shared F77=mpif77 ... where mpif77 translates to ifort -I/opt/parastation/mpi2-intel/include -L/opt/parastation/mpi2-intel/lib -Wl,-rpath -Wl,/opt/parastation/mpi2-intel/lib -lmpich -lpthread -L/opt/parastation/lib64 -Wl,-rpath,/opt/parastation/lib64 -Wl,--enable-new-dtags -lpscom -lrt configure fails in finding PIC flags (mpicc (icc) and mpicxx (icpc) PIC flags are discovered though): configure:17627: checking for mpif77 option to produce PIC configure:17899: result: There is no more output concerning the PIC flags in config.log. With F77=ifort everything works as expected: configure:16805: checking for ifort option to produce PIC configure:17077: result: -fPIC configure:17086: checking if ifort PIC flag -fPIC works configure:17104: ifort -c -g -fPIC conftest.f >&5 configure:17108: $? = 0 configure:17121: result: yes Any ideas what is going wrong there? Thanks, Christian ___ http://lists.gnu.org/mailman/listinfo/libtool
