Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

Subject: Re: [hwloc-devel] hwloc embedding vs libltdl
From: Jeff Squyres (jsquyres) (jsquyres_at_[hidden])
Date: 2013-05-07 18:00:14

Sorry for the high latency reply.

I thought about this quite a bit today. Here's a thinking-out-of-the-box question: should we just use the default/system installed libltdl instead of embedding? If we don't embed, many of these problems go away, right? I.e., we can still have the same options for plugins: non-default, but available if you ask for it *and* there's a system-level libltdl available.

FWIW: I see RHEL 6.x uses libtool/libltdl 2.2.6. Do we:

a) care about supporting plugins by default on distros with older ltdl versions?
b) use any functionality beyond libltdl 2.2.6? (or some other older/benchmark distro ltdl version that we care about supporting)

Attached is a patch that does a few minor things:

- avoid the use of AM_CONDITIONAL for the libltdl subdir
- ensure to have libtool avoid setting up Fortran and C++ (a trick we learned from MPICH :-) )
- disallow embedded mode and plugins (per our phone discussion the other day)
- reorder the plugins support AC_MSG_RESULT to come before any WARN/ERROR messages

On Apr 30, 2013, at 5:30 AM, Brice Goglin <Brice.Goglin_at_[hidden]> wrote:

> Jeff,
> I've been working on making hwloc v1.7 pass our tests/embedded scripts
> in the last days. I fixed some minor issues but here's the remaining
> (big) one.
> First problem is that we need the AM_CONDITIONAL for HWLOC_LTDL_INCLUDED
> to be executed when embedded. I can fix this by moving into
> We conditionally enable SUBDIRS=libltdl (in src/ when
> plugins are enabled and the internal ltdl is used. Assuming embedders
> don't want hwloc plugins, this builds fine since we don't enter libltdl
> during "make", and we can avoid the (ugly) ltdl configuration entirely
> [1]. But "make distclean" still enters libltdl unconditionally, and it
> fails if LTDL wasn't configured because the Makefile is missing.
> For the record, you had a similar issue with doc/tests/tools where you
> don't even have a in these directories in OMPI. You fixed it
> by doing DIST_SUBDIRS=$(SUBDIRS). It means that distclean doesn't enter
> those directories at all. But it also means that you don't get
> doc/tests/tools in make dist when embedded is enabled. We don't build
> hwloc tarballs in embedded mode so that's fine. Using the same idea for
> my issue would require to build hwloc tarballs with plugins enabled and
> ltld included (both non default), I don't thing we should to this way.
> So we need a way to have src/libltdl stay in DIST_SUBDIRS by default, go
> in SUBDIRS when needed, and disappear totally when embedded. So here's
> the only solution I finally found: hwloc sets a shell
> variable to yes, and a new AM_CONDITIONAL adds src/libltdl to
> DIST_SUBDIRS only when this variable is "yes".
> This still causes hwloc tarballs to contain libltdl (because hwloc
> sets the variable to yes). It's still enabled only when the
> system doesn't have libltdl installed or --with-included-ltdl is given,
> as previously. And embedders totally ignore src/libltdl, including in
> distclean, because they don't set the variable to yes.
> If an embedder ever wants to use hwloc plugins, he will have to
> duplicate what the hwloc does [1], and it can still link
> with another libltdl if needed (to be tested).
> Patch attached, on top of trunk. Note that you may need these additional
> commits if you or Pavan want to test things [2]
> Let me know what you think because you have the same problem as Pavan
> when OMPI switches to hwloc v1.6+
> Brice
> [1] Enabling ltdl requires some code like
> AM_PROG_LIBTOOL([dlopen win32-dll])
> LT_LANG([C])
> # Here's what we need to configure ltdl properly
> LT_CONFIG_LTDL_DIR([src/libltdl])
> LTDL_INIT([recursive convenience])
> AC_CONFIG_FILES([src/libltdl/Makefile])
> # Tell src/ that things were configured under src/libltdl/
> hwloc_mayenter_src_libltdl=yes
> libtool doesn't seem to like having it in a HWLOC_SETUP_LTDL macro
> outside of the main, and I think we have to let embedders call
> AM_PROG_LIBTOOL() directly in case they need other options.
> There's also a hack below these lines that is specific to the
> "recursive" mode, but we may switch to "subproject" mode (hwloc
> configure explicitly calls libltdl configure) at some point if libtool
> doesn't fix the issue.
> [2]
> <ltdl.patch>

Jeff Squyres
For corporate legal information go to: