Le 01/10/2018 à 17:27, Marco Atzeri a écrit : > Am 30.09.2018 um 20:11 schrieb Samuel Thibault: >> Marco Atzeri, le dim. 30 sept. 2018 20:02:59 +0200, a ecrit: >>> also adding a HWLOC_DECLSPEC on the first case distances.c:347 >>> does not solve the issue as the two declaration are not the same. >>> >>> Suggestion ? >> >> Perhaps use hwloc_uint64_t instead of uint64_t in hwloc/distances.c? >> >> Samuel > > Thanks Samuel, > it was that, in more than one place. > > The attached patch allowed the compilation on cygwin64 bit.
hwloc_uint64_t is currently defined to DWORDLONG (worked fine on MinGW and MSVC so far). I'd like to see if there's an easier way to solve this issue by just making that definition compatible for cygwin. > FAIL: test-lstopo.sh > > that seems due to a mix between Cygwin and Windows > > ############ utils/lstopo/test-lstopo.sh.log ############# > > Machine (3665MB total) + Package L#0 > NUMANode L#0 (P#0 3665MB) > L3 L#0 (6144KB) > L2 L#0 (256KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 > PU L#0 (P#0) > PU L#1 (P#1) > L2 L#1 (256KB) + L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 > PU L#2 (P#2) > PU L#3 (P#3) > L2 L#2 (256KB) + L1d L#2 (32KB) + L1i L#2 (32KB) + Core L#2 > PU L#4 (P#4) > PU L#5 (P#5) > L2 L#3 (256KB) + L1d L#3 (32KB) + L1i L#3 (32KB) + Core L#3 > PU L#6 (P#6) > PU L#7 (P#7) > OpenProcess 13220 failed 5: Zugriff verweigert Unfortunately that test script isn't easy to debug in the v2.x branch. If that OpenProcess is where things fail, I assume that the line that fails is "lstopo --ps". On MinGW, that code is ignored because /proc doesn't exist. Does /proc exist on Cygwin? If so, we should just disable that test line on Windows. > > ############################################################ > > And all the : > > FAIL: Intel-Skylake-2xXeon6140.output > FAIL: Intel-Broadwell-2xXeon-E5-2650Lv4.output > FAIL: Intel-Haswell-2xXeon-E5-2680v3.output > FAIL: Intel-IvyBridge-12xXeon-E5-4620v2.output > FAIL: Intel-SandyBridge-2xXeon-E5-2650.output > FAIL: Intel-Westmere-2xXeon-X5650.output > FAIL: Intel-Nehalem-2xXeon-X5550.output > FAIL: Intel-Penryn-4xXeon-X7460.output > FAIL: Intel-Core-2xXeon-E5345.output > FAIL: Intel-KnightsLanding-XeonPhi-7210.output > FAIL: Intel-KnightsCorner-XeonPhi-SE10P.output > FAIL: AMD-17h-Zen-2xEpyc-7451.output > FAIL: AMD-15h-Piledriver-4xOpteron-6348.output > FAIL: AMD-15h-Bulldozer-4xOpteron-6272.output > FAIL: AMD-K10-MagnyCours-2xOpteron-6164HE.output > FAIL: AMD-K10-Istanbul-8xOpteron-8439SE.output > FAIL: AMD-K8-SantaRosa-2xOpteron-2218.output > FAIL: AMD-K8-SledgeHammer-2xOpteron-250.output > FAIL: Zhaoxin-CentaurHauls-ZXD-4600.output > FAIL: Zhaoxin-Shanghai-KaiSheng-ZXC+-FC1081.output > ########################################################### > > But it is not clear to me how these tests should pass. > > The Laptop has a Quad Core I5 These tests use a tarball of the output of the cpuid instruction to emulate calling cpuid on those platforms. Go to tests/hwloc/xml, unpack one of the tarballs, and run "/path/to/utils/lstopo/lstopo -i <path/to/the/extracted/subdir>", you should get more information about what's failing when reading these dumped cpuid outputs. If it doesn't work tests/hwloc/xml/Intel-Skylake-2xXeon6140.output.log will show the difference between the expected and obtained topology when exported to XML. Brice _______________________________________________ hwloc-devel mailing list hwloc-devel@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/hwloc-devel
