Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

Subject: Re: [OMPI users] [EXTERNAL] Re: mpicc link shouldn't add -ldl and -lhwloc
From: Barrett, Brian W (bwbarre_at_[hidden])
Date: 2012-05-23 09:29:44

On 5/22/12 10:36 PM, "Orion Poplawski" <orion_at_[hidden]> wrote:

>On 05/22/2012 10:34 PM, Orion Poplawski wrote:
>> On 05/21/2012 06:15 PM, Jeff Squyres wrote:
>>> On May 15, 2012, at 10:37 AM, Orion Poplawski wrote:
>>>> $ mpicc -showme:link
>>>> -pthread -m64 -L/usr/lib64/openmpi/lib -lmpi -ldl -lhwloc
>>>> -ldl and -lhwloc should not be listed. The user should only link
>>>> against libraries that they are using directly, namely -lmpi, and
>>>> they should explicitly add -ldl and -lhwloc if their code directly
>>>> uses those libraries. There does not appear to be any references to
>>>> libdl or libhwloc symbols in the openmpi headers which is the other
>>>> place it could come in.
>>> I just read this a few times, and I admit that I'm a little confused.
>>> libmpi does use symbols from libdl; we use it to load OMPI's plugins.
>>> So I'm not sure why you're saying we shouldn't -ldl in the wrapper
>>> compiler...?
>>> libhwloc might be a little questionable here -- I'll have to check to
>>> see whether 1.6 uses hwloc only in a plugin or whether it's used in
>>> the base library (I don't remember offhand).
>> But libmpi is already linked against libdl and libhwloc. The wrapper
>> libraries are added when linking user code. But unless a user's code
>> directly uses libdl or libhwloc they don't need to link to those
>I should add the caveat that they are need when linking statically, but
>not when using shared libraries.

And therein lies the problem. We have a number of users who build Open
MPI statically and even some who build both static and shared libraries in
the same build. We've never been able to figure out a reasonable way to
guess if we need to add -lhwloc or -ldl, so we add them. It's better to
list them and have some redundant dependencies (since you have to have the
library anyways) than to not list them and have odd link errors.

We're open to better suggestions, but keep in mind that they have to be
portable and not require the user to change their build systems (ie, we
can't just depend on libtool to do everything for us).


  Brian W. Barrett
  Dept. 1423: Scalable System Software
  Sandia National Laboratories