hwloc configure check should use libtool for link args

[ronawho]

qthread_check_hwloc.m4 checks to see if hwloc is working first with just -lhwloc and then with -lhwloc -lnuma in case hwloc was built with libnuma support. However, hwloc can depend on other libraries such as -lcudart in the case where cuda support was detected.

Instead of trying to figure out what libs hwloc might depend on it seems like it'd be better to use libtool to get their dependencies out of their .la file. There's probably a clean way to do this in autoconf, but I have very little experience with autoconf/automake so I'm not sure what it would be.

And note that we build qthreads/hwloc (and all our 3rd party libs) statically. This wouldn't be an issue for shared libs.

For more context see https://github.com/chapel-lang/chapel/pull/7794

[npe9]

http://ftp.ics.uci.edu/pub/centos0/ics-custom-build/BUILD/hwloc-1.4.1/doc/doxygen-doc/html/a00010.html may offer a solution for what you're trying to do.

[ronawho]

I don't think qthreads works with an embedded hwloc. I'm pretty sure qthreads expects a "standalone" hwloc install. (embedded version has different function prefixes, "install" dirs, and lib names)

Ignoring chapel -- if you have a statically built hwloc that has library dependencies (e.g. cudart) qthreads configure will fail when it tries to check if hwloc is working.

For chapel -- at final link time we parse all .la files or use pkg-config to figure out the right link args, so this is only an issue during qthreads build. We can work around this issue by manually adding hwlocs dependencies to qthreads configure step (https://github.com/chapel-lang/chapel/pull/7794#issuecomment-344437530), but I figured I'd open the issue because this could affect other qthreads users.

[npe9]

@ronawho Would there be any reason from the chapel side not to move to embedded hwloc?

[ronawho]

I can't think of any reason we couldn't move to an embedded hwloc, and I would expect it to help with https://github.com/Qthreads/qthreads/issues/44