Build failes with MSVC about libcpuid HOT 12 CLOSED

Hmm, I'm very unfamiliar with MSVC (never used). Looks like some features are not supported by MSVC, like anonymous structure.

from libcpuid.

The issue is that MSVC doesn't support C99 completely and doesn't allow declaration after executable statement in a block:

			err  = cpu_rdmsr_range(info->handle, pstate, 8, 4, &CpuFid);
			err += cpu_rdmsr_range(info->handle, pstate, 3, 0, &CpuDid);
			const struct { uint64_t did; double divisor; } divisor_t[] = {
				{ 0x0,    1   },
				{ 0x1,    1.5 },
...

Would appreciate if you consider this to make libcpuid cross-platform. As far as I understand this is the intention, since MSVC solution files are provided.

from libcpuid.

Yes, libcpuid is cross-platform, and Windows is supported.
That's some mistake, GCC doesn't complain about it.

from libcpuid.

@"Windows is supported." De-facto it is not, at the moment. I just downloaded the repository and used MSVC project files to compile without any chances.

Would highly appreciate if you would include MSVC compatibility into consideration, as the project is very useful.

GCC is not used on Windows (handicapped MinGW or other funny tricks doesn't count), and MSVC is the mainstream compiler together with Intel compiler on the platform.

Thank you.

from libcpuid.

Thank you for the report. Of course, Windows is supported, and will always be, MSVC is also the primary targeted compiler for that OS, so what you see is indeed a problem with the sources. The reason for this intermittent breakages is that I still haven't set up continuous integration that does Windows builds as well, so such commits can be caught quickly. I've planned to do so, but still haven't got the time for it.

I'll fix the current windows compile issues ASAP.

from libcpuid.

@advanpix - I've pushed a fix that should resolve the MSVC compile issues. Can you try compiling on your side? If the current sources still don't compile, feel free to reopen the issue.

from libcpuid.

Veselin, thank you very much for your quick fix!
Now project compiles fine with MSVC 2010 and Intel Compiler (for Windows).

A.
However I would like to note that now CpuDid is used before its value is set:

	uint64_t CpuFid, CpuDid, CpuDidLSD;  <---
 	const struct { uint64_t did; double divisor; } divisor_t[] = {
 		{ 0x0,    1   },
 		{ 0x1,    1.5 },
 		{ 0x2,    2   },
 		{ 0x3,    3   },
 		{ 0x4,    4   },
 		{ 0x5,    6   },
 		{ 0x6,    8   },
 		{ 0x7,    12  },
 		{ 0x8,    16  },
 		{ CpuDid, 0   },    <---
        };

Previously CpuDid was initialized with cpu_rdmsr_range:

			err += cpu_rdmsr_range(info->handle, pstate, 3, 0, &CpuDid);  <---
 			const struct { uint64_t did; double divisor; } divisor_t[] = {
 				{ 0x0,    1   },
 				{ 0x1,    1.5 },
 				{ 0x2,    2   },
 				{ 0x3,    3   },
 				{ 0x4,    4   },
 				{ 0x5,    6   },
 				{ 0x6,    8   },
 				{ 0x7,    12  },
 				{ 0x8,    16  },
 				{ CpuDid, 0   }, <--
 			};

Let me know if this is correct and intended behavior?

B.
Intel compiler gives following warning:
1>rdmsr.c(899): warning C4244: 'function' : conversion from 'uint64_t' to 'uint32_t', possible loss of data

from libcpuid.

Another question - is there any plans to use CMake for compilation? This would make cross-platform support very easy. As only one script CMakeLists.txt will work on all platforms & compilers.

I plan to use libcpuid in our cross-platform software: https://www.advanpix.com/
After painful experience with all the different compilers & build systems we switched to CMake and never looked back.

Adding CMake to libcpuid would make integration to other projects a breeze and probably would serve it wider distribution.

from libcpuid.

Oh, my bad. Of course, the code was now invalid after my quick fix :) I've pushed a corrected version. The other warning you notice is harmless.

On CMake - I don't have experience with CMake myself, so I wouldn't volunteer to convert the project to CMake. Keep in mind that autotools actually have a lot of features, in our case .so versioning, static builds, create tarball rules etc, and I'm not sure that porting all of this to CMake is really that easy. If you only care about buildability, then yes, having CMake rule files alongside the autotools stuff probably make sense. If you volunteer to do that, just go ahead and send a pull request with the CMake rule files, I'll accept it and keep it up-to date.

from libcpuid.

Thank you for being so quick and responsive.
Does libcpuid have any extra dependencies for external libraries?
I think it is self-contained, but I see some weird stuff like bufferoverflowU.lib in libcpuid\Makefile.x64.

I will check as for writing CMake scripts - probably I will write simple one for easy buildability....

from libcpuid.

Just want to let you know that LIBCPUID+fix compiles & works fine on the following platforms:

• Windows: MSVC 2010
• Windows: Intel C++
• CentOS: GCC 5.3.0
• MacOSX: GCC 5.3.0

We will use the LIBCPUID in next releases of our product with credits & attribution.

Feel free to add our project to the list of projects which utilize LIBCPUID:
Multiprecision Computing Toolbox for MATLAB: https://www.advanpix.com/

from libcpuid.

Yes, libcpuid is self-contained. The real restriction is that it's not really cross-platform in the broadest sense, since it's x86 only.

On your other notes:

• libcpuid\Makefile.x64 is a historic artefact, I need to remove it.
• bufferoverflowU.lib is specific to x64 builds on MSVC, and is always present on that platform, so it's a natural dependency, much like libc.

Thank you for the tests! I've added your project to the list of libcpuid users. Keep up the good work and enjoy!

from libcpuid.