Please add hwloc

[hkaiser]

The Portable Hardware Locality (hwloc) software package provides a portable abstraction (across OS, versions, architectures, ...) of the hierarchical topology of modern architectures, including NUMA memory nodes, sockets, shared caches, cores and simultaneous multithreading. See https://www.open-mpi.org/projects/hwloc/ for more detail.

This library is a prerequisite for HPX which I will submit a PR for soon.

[hkaiser]

I tried to create CONTROL and portfile.cmake which downloads the prebuilt binaries and installs those: https://gist.github.com/hkaiser/0d3eb98d8785c6813e296c63b89c945e. This works well except that I see

The following packages will be built and installed:
    hwloc:x86-windows
Building package hwloc:x86-windows...
-- CURRENT_INSTALLED_DIR=D:/Devel/vcpkg/installed/x86-windows
-- DOWNLOADS=D:/Devel/vcpkg/downloads
-- CURRENT_PACKAGES_DIR=D:/Devel/vcpkg/packages/hwloc_x86-windows
-- CURRENT_BUILDTREES_DIR=D:/Devel/vcpkg/buildtrees/hwloc
-- CURRENT_PORT_DIR=D:/Devel/vcpkg/ports/hwloc/.
-- Using cached D:/Devel/vcpkg/downloads/hwloc-win32-build-1.11.7.zip
-- Testing integrity of cached file...
-- Testing integrity of cached file... OK
-- Extracting source D:/Devel/vcpkg/downloads/hwloc-win32-build-1.11.7.zip
-- Extracting done
-- Installing
-- Installing done
-- Performing post-build validation
Detected outdated dynamic CRT in the following files:

    D:/Devel/vcpkg/packages/hwloc_x86-windows/debug/bin/libhwloc-5.dll: msvcrt.dll
    D:/Devel/vcpkg/packages/hwloc_x86-windows/bin/libhwloc-5.dll: msvcrt.dll

To inspect the dll files, use:
    dumpbin.exe /dependents mydllfile.dll
Found 1 error(s). Please correct the portfile:
    D:\Devel\vcpkg\ports\hwloc\portfile.cmake
-- Performing post-build validation done
Error: Building package hwloc:x86-windows failed with: POST_BUILD_CHECKS_FAILED
Please ensure you're using the latest portfiles with `.\vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
  Package: hwloc:x86-windows
  Vcpkg version: 0.0.81-c99983613acb3878eb6f7d9269aaf62eeacd6fe8

Additionally, attach any relevant sections from the log files above.

How can this be solved?

[ras0219-msft]

msvcrt.dll is the extremely venerable CRT installed into system32 by default. It should not be linked by applications [1][2], but unfortunately gcc chooses to link with it when targeting Windows. Therefore, we diagnose this and fail by default.

It is possible for prebuilt libraries that link against msvcrt.dll to work, however they must follow very strict guidelines about their CRT usage -- specifically, they must exercise extreme control over malloc, free, and sharing CRT state over their DLL boundary. Looking over the headers, it seems hwloc does do this (I don't see any functions that expect you to malloc() and then hand over the memory).

Ideally, we would write a simple CMakeLists.txt and rebuild it from source. If that isn't realistically possible (the project experiences high churn that would break it), we can look at adding a policy to disable detection of msvcrt.dll.

[1] https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273/ [2] https://msdn.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx#sectiontoggle2

[hkaiser]

@ras0219-msft AFAIU, hwloc can't be built using Visual Studio and the authors have a handcrafted setup to provide binaries to Windows users which is built around the MINGW tool chain.

Also, we have not run into any CRT issues with this library in HPX so far. The library itself has served very well as a portable hardware abstraction helping with hardware topology analysis, thread affinities, etc. We very much rely on it in HPX.

We'd very much appreciate having a way to suppress the diagnostics from vcpkg without having to patch the sources and I'd be happy to help providing such a functionality. I would however need some guidance for how and where you envision this to be implemented as I have not looked at the sources so far and do not know anything about the tool's architecture..

[hkaiser]

@ras0219 As it turned out adding such a policy is not difficult, see #1144. Also, #1145 demonstrates its use.

[ras0219-msft]

Thanks for both of the PR's, I'll look forward to HPX!