unsupported option '-mwindows' for target 'x86_64-pc-windows-msvc' #631
Comments
|
It should be easy to disable this option when not building with GCC, but it would be nice to have the equivalent option for Clang. Otherwise there's no point in building both lstopo and lstopo-win. |
Clang can be used in "MSVC mode" to build hwloc using autotools. That mode doesn't support -mwindows just like MSVC doesn't. -mwindows is the only difference between lstopo-win and lstopo, so just disable lstopo-win instead of building both identically. Closes open-mpi#631 Signed-off-by: Brice Goglin <Brice.Goglin@inria.fr>
|
@jakirkham Can you try the tarball available at https://ci.inria.fr/hwloc/job/basic/view/change-requests/job/PR-632/ ? It should disable the build of lstopo-win entirely when it finds that the compiler says it's MSVC. |
Clang can be used in "MSVC mode" to build hwloc using autotools. That mode doesn't support -mwindows just like MSVC doesn't. -mwindows is the only difference between lstopo-win and lstopo, so just disable lstopo-win instead of building both identically. Closes open-mpi#631 Signed-off-by: Brice Goglin <Brice.Goglin@inria.fr>
Clang can be used in "MSVC mode" to build hwloc using autotools. That mode doesn't support -mwindows just like MSVC doesn't. Closes open-mpi#631 Signed-off-by: Brice Goglin <Brice.Goglin@inria.fr>
Clang can be used in "MSVC mode" to build hwloc using autotools. That mode doesn't support -mwindows just like MSVC doesn't. -mwindows is the only difference between lstopo-win and lstopo, so just disable lstopo-win instead of building both identically. Closes open-mpi#631 Signed-off-by: Brice Goglin <Brice.Goglin@inria.fr>
|
@jakirkham Did you have a chance to test this? |
Clang can be used in "MSVC mode" to build hwloc using autotools. That mode doesn't support -mwindows just like MSVC doesn't. Closes #631 Signed-off-by: Brice Goglin <Brice.Goglin@inria.fr>
Clang can be used in "MSVC mode" to build hwloc using autotools. That mode doesn't support -mwindows just like MSVC doesn't. -mwindows is the only difference between lstopo-win and lstopo, so just disable lstopo-win instead of building both identically. Closes #631 Signed-off-by: Brice Goglin <Brice.Goglin@inria.fr>
|
@jakirkham I updated the pull request, a tarball is available at https://ci.inria.fr/hwloc/job/basic/view/change-requests/job/PR-632/ |
|
Sorry for the long delay @bgoglin, I just backported #632 on top of 2.11.2 in conda-forge/libhwloc-feedstock#83 and it works like a charm. Thank you very much! |
|
@h-vetinari It's been a long time, I don't remember well what happened, but the second patch breaks lstopo_win_CFLAGS. I don't see why this CFLAGS would need to change in that commit, hence I am just going to revert that part and assume it still works for you since lstopo_win_CFLAGS isn't used anymore in your case. |
Clang can be used in "MSVC mode" to build hwloc using autotools. That mode doesn't support -mwindows just like MSVC doesn't. Closes open-mpi#631 Signed-off-by: Brice Goglin <Brice.Goglin@inria.fr>
Clang can be used in "MSVC mode" to build hwloc using autotools. That mode doesn't support -mwindows just like MSVC doesn't. -mwindows is the only difference between lstopo-win and lstopo, and we already remove -mwindows from lstopo-win if building with MSVC, so just disable lstopo-win instead of building both identically. Closes open-mpi#631 Signed-off-by: Brice Goglin <Brice.Goglin@inria.fr>
What version of hwloc are you using?
Building 2.9.3 from source
Which operating system and hardware are you running on?
Microsoft Windows Server 2022 (
x86_64)Details of the problem
Attempted to build from source with MSVC + Clang, but ran into an issue with the
-mwindowsflag (please see line below):hwloc/utils/lstopo/Makefile.am
Line 63 in fed97f6
Initially thought this might be a Clang bug ( llvm/llvm-project#69964 ), but was advised that the
-mwindowsflag was only intended for MinGW (not MSVC).Additional information
The build script runs this activation script on Windows followed by this shell script using MinGW's
bash+ Clang.Here is the full build log.
The text was updated successfully, but these errors were encountered: