Thanks to Alastair for filing https://github.com/open-mpi/ompi/issues/5114 to inform us upstream of this issue.
When this problem occurs, can you tell: 1. Is the errant "-l" being added by libtool (i.e., at "make" time)? 2. Or is the errant "-l" being added by configure (i.e., at "./configure" time)? Looking at the very bottom of one of the logs on this ticket (https://buildd.debian.org/status/fetch.php?pkg=openmpi&arch=ppc64&ver=3.0.1-9&stamp=1524654706&raw=0) -- extra blank lines inserted below for just for clarity): ----- make[3]: Entering directory '/<<PKGBUILDDIR>>/ompi/mpi/fortran/use-mpi-ignore-tkr' /bin/bash ../../../../libtool --tag=FC --mode=link gfortran -I../../../../ompi/include -I../../../../ompi/include -I../../../.. -I../../../.. -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -O3 -version-info 40:0:0 -Wl,-z,relro -L/usr//lib -o libmpi_usempi_ignore_tkr.la -rpath /usr/lib/powerpc64-linux-gnu/openmpi/lib mpi-ignore-tkr.lo mpi-ignore-tkr-sizeof.lo /<<PKGBUILDDIR>>/opal/libopen-pal.la -lrt -lm -lutil -lhwloc -levent -levent_pthreads libtool: link: gfortran -shared -fPIC .libs/mpi-ignore-tkr.o .libs/mpi-ignore-tkr-sizeof.o -Wl,-rpath -Wl,/<<PKGBUILDDIR>>/opal/.libs -Wl,-rpath -Wl,/usr/lib/powerpc64-linux-gnu/openmpi/lib -L/usr//lib /<<PKGBUILDDIR>>/opal/.libs/libopen-pal.so -lrt -lutil -lhwloc -levent -levent_pthreads -l -L/usr/lib/gcc/powerpc64-linux-gnu/7 -L/usr/lib/gcc/powerpc64-linux-gnu/7/../../../powerpc64-linux-gnu -L/usr/lib/gcc/powerpc64-linux-gnu/7/../../../../lib -L/lib/powerpc64-linux-gnu -L/lib/../lib -L/usr/lib/powerpc64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/powerpc64-linux-gnu/7/../../.. -lgfortran -lm -lc -lgcc_s -g -O2 -fstack-protector-strong -O3 -Wl,-z -Wl,relro -pthread -Wl,-soname -Wl,libmpi_usempi_ignore_tkr.so.40 -o .libs/libmpi_usempi_ignore_tkr.so.40.0.0 /usr/bin/powerpc64-linux-gnu-ld: cannot find -l-L/usr/lib/gcc/powerpc64-linux-gnu/7 collect2: error: ld returned 1 exit status make[3]: *** [Makefile:1866: libmpi_usempi_ignore_tkr.la] Error 1 ---- I see: /usr/bin/powerpc64-linux-gnu-ld: cannot find -l-L/usr/lib/gcc/powerpc64-linux-gnu/7 But the real problem looks like "-l" was added with either no library name, or a *blank* library name following it. In the middle of the long "libtool:" line: ---- ... -levent_pthreads -l -L/usr/lib/gcc/powerpc64-linux-gnu/7 ... ---- Note the "-l" hanging out there by itself. I also note the "-levent_pthreads" immediately preceding it, which is the last argument from the Open MPI-issued compile line. That means that libtool itself is adding the -l without a following library name (or erroneously blank following library name). It might be worth checking the .la files that libtool is examining -- perhaps from elsewhere on the system / outside the source/build trees -- here to see if there are any unexpectedly-empty library names. If those .la files got built incorrectly somehow, that could lead to link errors later like this...? Is it possible to check the build product from your automated CI like this? This is using the Open MPI-bootstrap-provided libtool, right (i.e., from the Open MPI 3.0.x tarball)? I.e., you didn't invoke "autogen.pl" again to re-bootstrap the Open MPI build system, right? -- Jeff Squyres jsquy...@cisco.com
