On Sep 5, 2012, at 10:13 AM, Brice Goglin wrote:
> I understand pretty much nothing in your mails :)
Don't linkers suck? :-) That wiki page is the result of much hard-won knowledge.
> The problem I was trying to fix below is that linking hwloc plugins on
> Darwin failed because plugins referred to hwloc-core symbols.
That should be fine, as long as you are dlopening the plugins in the same scope as the main application. Then the unresolved symbols in the plugins should be resolved against the libhwloc.so that is already loaded in the process space.
That's what lt_dladvise() is for.
> Nothing on
> the libtool command-line said where to find those symbols (I don't
> understand why it worked on other platforms).
Correct. This is more of a run-time issue than a compile/link-time issue (discounting -rpath, for the moment).
To clarify: it's fine to build any kind of shared library (DSO or otherwise) with unresolved symbols. They just need to be resolved when that shared library is loaded -- either by symbols that are already in the process space or by some dependent library that also gets loaded at the same time.
> I added -lhwloc as a way to tell the linker "those symbols are there". I
> didn't think it would statically link libhwloc inside the plugins, and
> it doesn't seem to do so (from what I see in objdump). Is this what you
Yes and no.
If libhwloc is libhowloc.a, then yes, it will statically link those symbols in the DSOs. If libhwloc is libhwloc.so, then you're probably ok -- this is case #1 (and footnote (*1*)) on table 1. Specifically:
(*1*) As far as we know, this works on all platforms that have dlopen (i.e., almost everywhere). But we've only tested (recently) Linux, OSX, and Solaris. These 3 dynamic loaders are smart enough to realize that they only need to load libmpi.so once (i.e., that the implicit dependency of libmpi.so brought in by the components is the same libmpi.so that is already loaded), so everything works fine.
> It's really a problem when linking, not about loading (and scopes that I
> don't know anything about), but I couldn't test loading before linking
No. It actually is a problem with loading -- not linking. :-)
> Anyway, how should I solve this?
Let me answer Samuel's mails and come back to this question...
> Le 05/09/2012 15:58, Jeff Squyres a écrit :
>> I should clarify...
>> In OMPI, if we're building libmpi.so, we default to building plugins as DSOs. If we're building libmpi.a, then we slurp all the plugins into libmpi.a (i.e., don't build them as DSOs). This avoids many of the issues in table 2.
>> On Sep 5, 2012, at 9:54 AM, Jeff Squyres wrote:
>>> This is a bad idea.
>>> I'm trying to remember the reason why, but we explicitly *removed* such -l statements (e.g., removed "-lmpi" from the plugins). Hmm... Oh, right. Every time I think I understand linkers, I find out that I don't. So last time we had a Big Confusion Discussion About Linkers (BCDAL), I wrote it all up:
>>> The 4th column in these tables is labeled "OMPI DSO components depend on libmpi.so?" (which is somewhat of a misnomer, because not all components are at the MPI layer -- so consider it to mean "OMPI DSO components depend on some OMPI library, such as libmpi.so?")
>>> The problem cases are #9 and #12 in the first table: i.e., static linking.
>>> Instead, we use lt_dladvise() to open hwloc plugins in the same scope as the main application.
>>> Of course, this has its own tradeoffs -- if hwloc itself, is opened as a plugin in a private scope, then the plugins won't be able to find the symbols it needs (i.e., cases #14, #15, #17, #18, #20, #21, #23, and #24 in the 2nd table).
>>> Until POSIX effects hierarchical linker scopes (or at least something like "please dlopen this plugin and put it in XYZ linker scope"), there's really no good solution here. :-(
>>> On Sep 5, 2012, at 6:03 AM, <svn-commit-mailer_at_[hidden]> wrote:
>>>> Author: bgoglin (Brice Goglin)
>>>> Date: 2012-09-05 06:03:52 EDT (Wed, 05 Sep 2012)
>>>> New Revision: 4815
>>>> URL: https://svn.open-mpi.org/trac/hwloc/changeset/4815
>>>> Pass -lhwloc to all plugins, at least Darwin wants it
>>>> (plugins use some hwloc functions)
>>>> Define a plugins_ldflags with all common stuff for plugins
>>>> (this somehow reverts r4811)
>>>> Text files modified:
>>>> branches/components/src/Makefile.am | 13 +++++++------
>>>> 1 files changed, 7 insertions(+), 6 deletions(-)
>>>> Modified: branches/components/src/Makefile.am
>>>> --- branches/components/src/Makefile.am Wed Sep 5 06:03:36 2012 (r4814)
>>>> +++ branches/components/src/Makefile.am 2012-09-05 06:03:52 EDT (Wed, 05 Sep 2012) (r4815)
>>>> @@ -21,6 +21,7 @@
>>>> pluginsdir = $(libdir)/hwloc
>>>> plugins_LTLIBRARIES =
>>>> +plugins_ldflags = -module -avoid-version -lhwloc
>>>> AM_CPPFLAGS += -DHWLOC_PLUGINS_DIR=\"$(pluginsdir)\"
>>>> # Sources and ldflags
>>>> @@ -40,7 +41,6 @@
>>>> topology-xml.c \
>>>> ldflags =
>>>> -common_ldflags =
>>>> # Conditionally add to the sources and ldflags
>>>> @@ -52,7 +52,7 @@
>>>> xml_libxml_la_SOURCES = topology-xml-libxml.c
>>>> xml_libxml_la_CPPFLAGS = $(AM_CPPFLAGS) -DHWLOC_BUILD_PLUGIN
>>>> xml_libxml_la_CFLAGS = $(AM_CFLAGS) $(HWLOC_LIBXML2_CFLAGS)
>>>> -xml_libxml_la_LDFLAGS = $(common_ldflags) -module -avoid-version $(HWLOC_LIBXML2_LIBS)
>>>> +xml_libxml_la_LDFLAGS = $(plugins_ldflags) $(HWLOC_LIBXML2_LIBS)
>>>> endif HWLOC_HAVE_LIBXML2
>>>> @@ -64,7 +64,7 @@
>>>> core_libpci_la_SOURCES = topology-libpci.c
>>>> core_libpci_la_CPPFLAGS = $(AM_CPPFLAGS) -DHWLOC_BUILD_PLUGIN
>>>> core_libpci_la_CFLAGS = $(AM_CFLAGS) $(HWLOC_PCI_CFLAGS)
>>>> -core_libpci_la_LDFLAGS = $(common_ldflags) -module -avoid-version $(HWLOC_PCI_LIBS)
>>>> +core_libpci_la_LDFLAGS = $(plugins_ldflags) $(HWLOC_PCI_LIBS)
>>>> endif HWLOC_HAVE_LIBPCI
>>>> @@ -105,7 +105,8 @@
>>>> endif HWLOC_HAVE_FREEBSD
>>>> if HWLOC_HAVE_GCC
>>>> -common_ldflags += -no-undefined
>>>> +ldflags += -no-undefined
>>>> +plugins_ldflags += -no-undefined
>>>> endif HWLOC_HAVE_GCC
>>>> if HWLOC_HAVE_WINDOWS
>>>> @@ -136,7 +137,7 @@
>>>> # Installable library
>>>> libhwloc_la_SOURCES = $(sources)
>>>> -libhwloc_la_LDFLAGS = $(common_ldflags) $(ldflags) -version-info $(libhwloc_so_version) $(HWLOC_LIBS)
>>>> +libhwloc_la_LDFLAGS = $(ldflags) -version-info $(libhwloc_so_version) $(HWLOC_LIBS)
>>>> if HWLOC_HAVE_PLUGINS
>>>> AM_CPPFLAGS += $(LTDLINCL)
>>>> @@ -168,5 +169,5 @@
>>>> check_LTLIBRARIES = core_fake.la
>>>> core_fake_la_SOURCES = topology-fake.c
>>>> core_fake_la_CPPFLAGS = $(AM_CPPFLAGS) -DHWLOC_BUILD_PLUGIN
>>>> -core_fake_la_LDFLAGS = $(common_ldflags) -module -avoid-version -rpath /nowhere # force libtool to build a shared-library even it's check-only
>>>> +core_fake_la_LDFLAGS = $(plugins_ldflags) -rpath /nowhere # force libtool to build a shared-library even it's check-only
>>>> hwloc-svn mailing list
>>> Jeff Squyres
>>> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
>>> hwloc-devel mailing list
> hwloc-devel mailing list
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/