This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
> 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.