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-
> 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
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
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,
>
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:
>>
>
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
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
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
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
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
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
Out of curiosity, do you have your version of OMPI at the _beginning_ of your
LD_LIBRARY_PATH?
> On Feb 26, 2016, at 8:24 AM, Emmanuel Thomé wrote:
>
> On Fri, Feb 26, 2016 at 5:21 PM, Emmanuel Thomé
> wrote:
>> happens to have an openmpi-1.6.5 installation in /usr, as well as .
>
> Sorry for
On Fri, Feb 26, 2016 at 5:21 PM, Emmanuel Thomé
wrote:
> happens to have an openmpi-1.6.5 installation in /usr, as well as .
Sorry for copy-paste failure. 1.6.5 is only in /usr, of course.
E.
I have a problem with the build and install process of openmpi-1.10.2.
I have here a machine running Debian GNU/Linux 8.2 ; this machine also
happens to have an openmpi-1.6.5 installation in /usr, as well as .
This should not matter, but here it does.
The machine also has an Infiniband software s
14 matches
Mail list logo
