hwloc requires a certain minimum version, but does not check for it

Create issue
Issue #1635 closed
Frank Löffler created an issue

Currently, hwloc's configuration.sh searched for any hwloc library and uses it. However, it requires a pretty new version within some of its own files, which leads to build failure on, e.g. Debian stable systems.

The attached patch uses pkg-config to get the version of the installed hwloc library and if that version is older than 1.6 (educated guess, but see http://lists.einsteintoolkit.org/pipermail/users/2013-February/002860.html), builds the bundled version even if another version is installed (but too old).

Note that this is done (intentionally) only if no library was specified, and the script was looking for it by itself. This allows users to specify something which will not be overwritten by this mechanism.

Keyword: backport

Comments (15)

  1. Frank Löffler reporter
    • removed comment

    Ideally this should not be done using pkg-config (since that might not be installed), but using a autoconf-script. However, I don't have the time to provide this right now, and the current solution is short and provides help in at least the case when pkg-config is installed.

  2. anonymous
    • removed comment

    It seems that

    pkg-config --modversion hwloc < '1.6'
    

    is not the correct way to perform the version check; for the current stable version 1.10.0, the configure script erroneously concludes that 1.10.0 < 1.6 leading to the following complaint:

    Running configuration script for thorn HWLOC:
    hwloc selected, but HWLOC_DIR not set. Checking some places...
    Found hwloc in /usr
    hwloc too old (require at least version 1.6)
    Using bundled hwloc...
    

    Rebuilding hwloc from the included sources is undesirable when a complete hwloc package provided by the OS vendor is already installed on the system.

  3. Frank Löffler reporter
    • removed comment

    Version check in bash is not build-in, and relying on sort (-V) brings up the issue that some implementation of sort might not offer that option. The best pure bash solution I could find quickly is:

    http://stackoverflow.com/questions/4023830/bash-how-compare-two-strings-in-version-format

    Given the length of that function, and it's general usefulness I wonder if we couldn't make this available to configure scripts from within Cactus.

  4. Roland Haas
    • removed comment

    We don't have to use just bash. We can also use perl (Cactus requires it) or awk (POSIX requires it). So something like:

    echo "1.42.12" | perl -ne 'm/0*(\d+)[.]0*(\d+)[.]0*(\d+)/; exit (($1 >= 1 and $2 >= 9 and $3 >= 11) ? 0 : 1)'
    

    would do the trick of checking that the version is larger or equal to 1.9.11.

  5. Roland Haas
    • changed status to open
    • removed comment

    The attached patch check_version.patch uses perl and awk to check the installed version if either pkgconfig is found or the API version can be parsed out of hwloc.h.

  6. anonymous
    • removed comment

    The patch adapted to ET_2014_11 appears to compare the version strings correctly, and indeed, the build system now does not build the bundled version any longer but instead uses version 1.10.0 installed on my system. Thanks!

  7. anonymous
    • removed comment

    There is still a problem leading to a linker error for the final executable already reported at

    http://lists.einsteintoolkit.org/pipermail/users/2014-August/003755.html :

    .. /usr/bin/ld: cannot find -lnuma /usr/bin/ld: cannot find -lltdl ..

    hwloc actually needs numactl-devel. The hwloc configure script does not ensure that libnuma. is installed. The second (unrelated) error was resolved on my system by installing libtool-tdl-devel. Please open a new ticket for these minor issues if you see fit to do so, thanks. Btw, on recent systems, there is a move towards using shared libraries alone; therefore, queries similar to 'grep ... lib.la' found in the build system will only fail more often in the future.

  8. Log in to comment