Hi,
Thanks for your answer.
I have no LD_LIBRARY_PATH. I am not sure it should matter anyway,
though: the objdump command looks at what the object file requests,
not necessarily what happens at runtime as if we were using ldd.
This seems to be related to the MOFED debian packages including a .la
Emmanuel,
By any chance, does libosmcomp.la contains a -rpath line ?
FWIW, you can simply
make V=1
In order to see how libtool is invoked, and how it will invoke bcc
Cheers,
Gilles
On Saturday, February 27, 2016, Emmanuel Thomé
wrote:
> Hi,
>
> Thanks for your answer.
>
> I have no LD_LIBRAR
On Feb 27, 2016, at 5:42 AM, Emmanuel Thomé wrote:
>
> Specifically, I have /usr/lib/libosmcomp.la. If I delete that file,
> then no -L/usr/lib shows up in the relink command for libmpi; libtool
> just emits -losmcomp alone, which is fine. Then the subsequent
> -lopen-rte finds the one installed
Hi,
I attach both $builddir/ompi/libmpi.la and /usr/lib/libosmcomp.la
(both from a system where I kept that file).
/usr/lib/libosmcomp.la has no embedded rpath information. FWIW, this
.la file comes from the file
MLNX_OFED_LINUX-3.1-1.0.3-debian8.1-x86_64/DEBS/libopensm_4.6.0.MLNX20150830.c69ebab
Can you send all the build information listed here:
https://www.open-mpi.org/community/help/
> On Feb 27, 2016, at 8:48 AM, Emmanuel Thomé wrote:
>
> Hi,
>
> I attach both $builddir/ompi/libmpi.la and /usr/lib/libosmcomp.la
> (both from a system where I kept that file).
>
> /usr/lib/lib
Here's how libtool is called at build time, that is, at the point
where it creates the libmpi.la file, as well as the synthetized gcc
command line.
(sorry, loong line)
/bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -O3
-DNDEBUG -finline-functions -fno-strict-aliasing -pthread
-version
Here you go.
http://www.loria.fr/~thome/vrac/logs.tar.bz2
E.
On Sat, Feb 27, 2016 at 2:56 PM, Jeff Squyres (jsquyres)
wrote:
> Can you send all the build information listed here:
>
> https://www.open-mpi.org/community/help/
>
>
>
>> On Feb 27, 2016, at 8:48 AM, Emmanuel Thomé wrote:
>>
>
I got your log files and looked at them, but am replying earlier in the thread
in order to give more specific answers. More below.
> On Feb 27, 2016, at 5:42 AM, Emmanuel Thomé wrote:
>
> Hi,
>
> Thanks for your answer.
>
> I have no LD_LIBRARY_PATH. I am not sure it should matter anyway,
>
Thanks for your analysis.
On Sat, Feb 27, 2016 at 3:19 PM, Jeff Squyres (jsquyres)
wrote:
> [...]
> 1. osmcomp should not have installed a .la file for a default linker location
Probably not, although the no-brainer default solution does this
(plus, the .la files say "do not delete"...).
> 2. L
> Note, too, that 1.10.2 has a bug that one of the core Open MPI libs has a
> dependency on libibverbs (only Open MPI's plugins are supposed to be
> dependent upon libibverbs). This was a mistake that is fixed in the 1.10.3
> nightly tarballs. Indeed, fixing this bug may have the side-effect o
On Feb 27, 2016, at 9:33 AM, Emmanuel Thomé wrote:
>
>>> dependency_libs=' -losmcomp -libverbs
>>> /tmp/openmpi-1.10.2/orte/libopen-rte.la
>>> /tmp/openmpi-1.10.2/opal/libopen-pal.la -lnuma -ldl -lrt -lm -lutil'
>>
>> Why does this not look good?
>
> Because my general rule of thumb about link-
11 matches
Mail list logo