> Hartmut Kaiser, le Tue 13 Mar 2012 12:46:05 +0100, a écrit :
> > Trying to use hwloc on a 48 bit core machine (Windows x64) causes
> > problems, though. Any information requests for processing units above
> > number 32 return garbage (see also the attached output of 'lstopo -of
> Ok, so it didn't magically work.
> Unfortunately I have no access to a windows machine with that many cores,
> so I could not test >sizeof(unsigned long) cores detection myself, it's
> thus not very surprising that it does not work.
What do you suggest? (Let me add that I tested the 64bit version of the
Would giving you access to our windows box help?
> > I tried to recompile the library using MSVC which would allow me to
> > debug the issue, but after several hours of tweaking I gave up. As it
> > turns out the code base is everything but portable, which is really
> > unfortunate for a library which is supposed to be cross platform.
> I'm afraid to have to answer that MSVC does everything but respecting
> standards, even when they are more that 10 years old. The hwloc code
> compiles as such on a variety of unix compilers, and we didn't need many
> tweaks for that.
I'm not saying they do. However, it's a widely used compiler and supporting
it is a must for a cross-platform library (IMHO).
But the problems I was seeing were not MSVC specific. It's a proliferation
of arcane (non-POSIX) function use (like strcasecmp, etc.) missing use of
HAVE_UNISTD_H, HAVE_STRINGS_H to wrap non-standard headers, unsafe mixing of
int32<->int64 data types, reliance on int (and other types) having a certain
bit-size, totally unsafe shift operations, wide use of (non-C-standard) gcc
extensions, etc. Should I go on?
> The mingw toolchain saves a lot of such concerns, so I
> can only advise to use it.