BUG: Order of OS detection macros (for Windows) seems faulty #24761

mahge · 2023-09-20T19:58:04Z

Describe the issue:

The order of these OS detection macros might make Win64 and MinGW unreachable.

Lines 22 to 27 in 07db5be

    
           #elif defined(_WIN32) || defined(__WIN32__) || defined(WIN32) 
        
               #define NPY_OS_WIN32 
        
           #elif defined(_WIN64) || defined(__WIN64__) || defined(WIN64) 
        
               #define NPY_OS_WIN64 
        
           #elif defined(__MINGW32__) || defined(__MINGW64__) 
        
               #define NPY_OS_MINGW

According to Microsoft documentation the macros are defined as follows:

_WIN32 Defined as 1 when the compilation target is 32-bit ARM, 64-bit ARM, x86, or x64. Otherwise, undefined.
_WIN64 Defined as 1 when the compilation target is 64-bit ARM or x64. Otherwise, undefined.

Essentially _WIN32 is defined on 32 bit as well as 64 bit setups. _WIN64 is defined on 64 bit Windows only. This means the first check

#elif defined(_WIN32) || defined(__WIN32__) || defined(WIN32) 
     #define NPY_OS_WIN32

will succeed and the numpy OS will be defined as NPY_OS_WIN32 on 64-bit ARM or x64 Windows.

On top of that, MinGW compilers follow the same rule. So _WIN32 is defined, say on 32 bit as well as 64 bit MinGW64 gcc/clang while _WIN64 is defined for 64 bit compilations only.

Although I can not find a definite documentation for the MinGW64 compiler macros, as far as I can tell this is the state of these macros:

64 bit MinGW compilers define `_MINGW32__`, `__MINGW64__`, `_WIN32`, and `_WIN64`.
32 bit MinGW compilers define `__MINGW32__`, and `_WIN32`.
64 bit MSVC compilation defines `_WIN32` and  `_WIN64`.
32 bit MSVC compilation defines `_WIN32`.

Therefore, on 32 bit or 64 bit Windows or MinGW, the OS check will always say that the OS is NPY_OS_WIN32. This might be fine for most use cases (especially since the macros do not seem to be used in many places) but it is also not what is intended.

With MinGW's 64-bit UCRT64 gcc, for example, this causes compilation failure because the OS is defined as NPY_OS_WIN32 and this causes this check

#ifndef F2PY_THREAD_LOCAL_DECL
#if defined(_MSC_VER)
#define F2PY_THREAD_LOCAL_DECL __declspec(thread)
#elif defined(NPY_OS_MINGW)
#define F2PY_THREAD_LOCAL_DECL __thread
#elif defined(__STDC_VERSION__) \
      && (__STDC_VERSION__ >= 201112L) \
      && !defined(__STDC_NO_THREADS__) \
      && (!defined(__GLIBC__) || __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ > 12)) \
      && !defined(NPY_OS_OPENBSD) && !defined(NPY_OS_HAIKU)
/* __STDC_NO_THREADS__ was first defined in a maintenance release of glibc 2.12,
   see https://lists.gnu.org/archive/html/commit-hurd/2012-07/msg00180.html,
   so `!defined(__STDC_NO_THREADS__)` may give false positive for the existence
   of `threads.h` when using an older release of glibc 2.12
   See gh-19437 for details on OpenBSD */
#include <threads.h>
#define F2PY_THREAD_LOCAL_DECL thread_local
#elif defined(__GNUC__) \
      && (__GNUC__ > 4 || (__GNUC__ == 4 && (__GNUC_MINOR__ >= 4)))
#define F2PY_THREAD_LOCAL_DECL __thread
#endif
#endif

in the generated files when using f2py to assume threads.h is available. Compilation fails because it is not available.

Reproduce the code example:

Unfortunately I do not have a simple example to reproduce this. I am also not very familiar with numpy or f2py as much as I would like. I came across it while fixing things in a bigger project. 

On the other hand it should be easier to reproduce for someone who know what they are doing and have access to MYSY's UCRT64 environment. Even if that is not possible one can possible figure out what the results might be by looking at the relevant section in npy_os.h and the reported predefined macro status.

Error message:

msys/tmp/tmp1rhc293t/src.mingw_x86_64_ucrt-3.11/curvif_simplifiedmodule.c:87:10: fatal error: threads.h: No such file or directory
   87 | #include <threads.h>
      |          ^~~~~~~~~~~
compilation terminated.

Runtime information:

$> f2py

Version:     1.25.2
numpy Version: 1.25.2
Requires:    Python 3.5 or higher.
License:     NumPy license (see LICENSE.txt in the NumPy source code)
Copyright 1999 - 2011 Pearu Peterson all rights reserved.
https://web.archive.org/web/20140822061353/http://cens.ioc.ee/projects/f2py2e

Context for the issue:

No response

The text was updated successfully, but these errors were encountered:

- The order should be `__MINGW32__/__MINGW64__`, then `_WIN64`, and then `_WIN32`. 64 bit MinGW compilers define `_MINGW32__`, `__MINGW64__`, `_WIN32`, and `_WIN64`. 32 bit MinGW compilers define `__MINGW32__`, and `_WIN32`. 64 bit MSVC compilation defines `_WIN32` and `_WIN64`. 32 bit MSVC compilation defines `_WIN32`. - Fixes numpy#24761.

mahge · 2023-09-20T20:11:39Z

I have added a simple PR for it in #24762. Please feel free to fix it in your own way if it is not adequate. The OS detection can use a bit more adjustments and additions.

mattip · 2023-09-21T04:56:30Z

I am a bit confused why this has not come up before. I see the snippet you reproduced with the include <threads.h> comes from f2py here in f2py, is this not compiled into tests? Or maybe the rtools mingw we use for fortran compilation does not use the right runtime to hit the bug?

@HaoZeke as the last one to touch that file in #20884 do you have any insights?

mahge · 2023-09-21T07:41:05Z

I am a bit confused why this has not come up before.

My guess is that some of the other conditions in the check

#elif defined(__STDC_VERSION__) \
      && (__STDC_VERSION__ >= 201112L) \
      && !defined(__STDC_NO_THREADS__) \
      && (!defined(__GLIBC__) || __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ > 12)) \
      && !defined(NPY_OS_OPENBSD) && !defined(NPY_OS_HAIKU)
/* __STDC_NO_THREADS__ was first defined in a maintenance release of glibc 2.12,
   see https://lists.gnu.org/archive/html/commit-hurd/2012-07/msg00180.html,
   so `!defined(__STDC_NO_THREADS__)` may give false positive for the existence
   of `threads.h` when using an older release of glibc 2.12
   See gh-19437 for details on OpenBSD */
#include <threads.h>
#define F2PY_THREAD_LOCAL_DECL thread_local

were not satisfied (for most, this is probably due to requesting __STDC_VERSION__ >= 201112L). This meant the check probably got satisfied by the next check

#elif defined(__GNUC__) \
      && (__GNUC__ > 4 || (__GNUC__ == 4 && (__GNUC_MINOR__ >= 4)))
#define F2PY_THREAD_LOCAL_DECL __thread

which, coincidentally, has the same effect as NPY_OS_MINGW being defined anyway. Considering this last check was for gcc > 4.4, it is likely it was satisfied by most platforms by the time the change was made.

In MinGW UCRT64¨s gcc-13 case, I can see we have __STDC_VERSION__ >= 201112L satisfied. Maybe that is the reason why it popped up now. I am guessing the explicit check for MinGW environments was made to address this issue.

- there is a small bug in numpy's f2yc which does not detect MinGW environments as it is supposed to. See: numpy/numpy#24761 - This make file is used for MinGW only. So we can just define the variable without any other checks being needed. This also needs a CMake configuration or at least the Makefile should be improved a bit.

- There is a small bug in numpy's f2yc which does not detect MinGW environments as it is supposed to. See: numpy/numpy#24761 - This make file is used for MinGW only. So we can just define the variable without any other checks being needed. This also needs a CMake configuration or at least the Makefile should be improved a bit.

- There is a small bug in numpy's f2yc which does not detect MinGW environments as it is supposed to. See: numpy/numpy#24761 - This Makefile is used for MinGW only. So we can just define the variable without any other checks being needed.

HaoZeke · 2023-09-21T10:13:09Z

I am a bit confused why this has not come up before. I see the snippet you reproduced with the include <threads.h> comes from f2py here in f2py, is this not compiled into tests? Or maybe the rtools mingw we use for fortran compilation does not use the right runtime to hit the bug?

@HaoZeke as the last one to touch that file in #20884 do you have any insights?

As I recall, the changes were to go from hand-crafted macros to the ones used in the rest of NumPy, and wouldn't have handled / caught this bug.

HaoZeke · 2023-09-21T10:14:54Z

FWIW a lot of the macro logic in f2py can be simplified with meson configuration files once that becomes the default, but that's a separate issue :)

carlkl · 2023-09-21T10:27:39Z

predefined macros, look here: https://github.com/cpredef/predef

carlkl · 2023-09-21T10:51:29Z

Sorry for my ignorance, What is the purpose of NPY_OS_MINGW within numpy?

Do we also want to differentiate between mingw32 and mingw-w64 toolchain? The mingw32 toolchain is the now obsolet precedessor of mingw-w64 and should issue a warning IMHO.

Do we want to differentiate between 32-bit and 64-bit version of the mingw-w64 toolchain?

Do we need to check the gcc version and/or the version of the mingw-w64 headers used, to ensure a minimum of features / issue a warning?

mahge · 2023-09-21T15:40:13Z

Do we also want to differentiate between mingw32 and mingw-w64 toolchain? The mingw32 toolchain is the now obsolet precedessor of mingw-w64 and should issue a warning IMHO.

Do we want to differentiate between 32-bit and 64-bit version of the mingw-w64 toolchain?

I think it is more of differentiating Windows (as in MSVC) vs MinGW-w64 compilers rather than detecting the architecture. At least that seems to be the intention. Of course it does not hurt if the detection also figures out the architecture when possible. The purpose of NPY_OS_MINGW seems to be identifying that we are on Windows but using one of the MinGW-w64 compilers. The definition OS/compiler gets a bit mixed up when refereeing to MSYS/MinGW environments.

Of course these OS/platform/compiler detections are never really exhaustive and get fixed/built-up overtime. It all depends on if numpy uses some features of a specific combination of these OS/platform/compiler variants.

mahge · 2023-09-21T16:07:38Z

FWIW a lot of the macro logic in f2py can be simplified with meson configuration files once that becomes the default, but that's a separate issue :)

I am not sure if it helps that much in this specific case. The configuration tools like Mason and CMake will give you the macros needed sure. However that will not save you from the fact that _WIN32 will be defined for 64 bit Windows compilations with MSVC or MinGW-w64 compilers. It is by design. We just have to pick and choose how we use those macros.

CMake used to have a module called WriteCompilerDetectionHeader that tried to help in detecting different compilers by generating a header file that can be included by the project. Unfortunately, they have now deprecated it. Maybe Meson does a good job at it.

The CMake generated compiler detection header will look something like this. It is probably an overkill but can also be a good starting point if you want to be as exhaustive as possible.

numpy_compiler_detection.h

// This is a generated file. Do not edit!

#ifndef NUMPY_COMPILER_DETECTION_H
#define NUMPY_COMPILER_DETECTION_H

#ifdef __cplusplus
#define NUMPY_COMPILER_IS_Comeau 0
#define NUMPY_COMPILER_IS_Intel 0
#define NUMPY_COMPILER_IS_PathScale 0
#define NUMPY_COMPILER_IS_Embarcadero 0
#define NUMPY_COMPILER_IS_Borland 0
#define NUMPY_COMPILER_IS_Watcom 0
#define NUMPY_COMPILER_IS_OpenWatcom 0
#define NUMPY_COMPILER_IS_SunPro 0
#define NUMPY_COMPILER_IS_HP 0
#define NUMPY_COMPILER_IS_Compaq 0
#define NUMPY_COMPILER_IS_zOS 0
#define NUMPY_COMPILER_IS_XLClang 0
#define NUMPY_COMPILER_IS_XL 0
#define NUMPY_COMPILER_IS_VisualAge 0
#define NUMPY_COMPILER_IS_PGI 0
#define NUMPY_COMPILER_IS_Cray 0
#define NUMPY_COMPILER_IS_TI 0
#define NUMPY_COMPILER_IS_Fujitsu 0
#define NUMPY_COMPILER_IS_GHS 0
#define NUMPY_COMPILER_IS_SCO 0
#define NUMPY_COMPILER_IS_ARMCC 0
#define NUMPY_COMPILER_IS_AppleClang 0
#define NUMPY_COMPILER_IS_ARMClang 0
#define NUMPY_COMPILER_IS_Clang 0
#define NUMPY_COMPILER_IS_GNU 0
#define NUMPY_COMPILER_IS_MSVC 0
#define NUMPY_COMPILER_IS_ADSP 0
#define NUMPY_COMPILER_IS_IAR 0
#define NUMPY_COMPILER_IS_MIPSpro 0

#if defined(__COMO__)
#undef NUMPY_COMPILER_IS_Comeau
#define NUMPY_COMPILER_IS_Comeau 1

#elif defined(__INTEL_COMPILER) || defined(__ICC)
#undef NUMPY_COMPILER_IS_Intel
#define NUMPY_COMPILER_IS_Intel 1

#elif defined(__PATHCC__)
#undef NUMPY_COMPILER_IS_PathScale
#define NUMPY_COMPILER_IS_PathScale 1

#elif defined(__BORLANDC__) && defined(__CODEGEARC_VERSION__)
#undef NUMPY_COMPILER_IS_Embarcadero
#define NUMPY_COMPILER_IS_Embarcadero 1

#elif defined(__BORLANDC__)
#undef NUMPY_COMPILER_IS_Borland
#define NUMPY_COMPILER_IS_Borland 1

#elif defined(__WATCNUMPY__) && __WATCNUMPY__ < 1200
#undef NUMPY_COMPILER_IS_Watcom
#define NUMPY_COMPILER_IS_Watcom 1

#elif defined(__WATCNUMPY__)
#undef NUMPY_COMPILER_IS_OpenWatcom
#define NUMPY_COMPILER_IS_OpenWatcom 1

#elif defined(__SUNPRO_CC)
#undef NUMPY_COMPILER_IS_SunPro
#define NUMPY_COMPILER_IS_SunPro 1

#elif defined(__HP_aCC)
#undef NUMPY_COMPILER_IS_HP
#define NUMPY_COMPILER_IS_HP 1

#elif defined(__DECCXX)
#undef NUMPY_COMPILER_IS_Compaq
#define NUMPY_COMPILER_IS_Compaq 1

#elif defined(__IBMCPP__) && defined(__COMPILER_VER__)
#undef NUMPY_COMPILER_IS_zOS
#define NUMPY_COMPILER_IS_zOS 1

#elif defined(__ibmxl__) && defined(__clang__)
#undef NUMPY_COMPILER_IS_XLClang
#define NUMPY_COMPILER_IS_XLClang 1

#elif defined(__IBMCPP__) && !defined(__COMPILER_VER__) && __IBMCPP__ >= 800
#undef NUMPY_COMPILER_IS_XL
#define NUMPY_COMPILER_IS_XL 1

#elif defined(__IBMCPP__) && !defined(__COMPILER_VER__) && __IBMCPP__ < 800
#undef NUMPY_COMPILER_IS_VisualAge
#define NUMPY_COMPILER_IS_VisualAge 1

#elif defined(__PGI)
#undef NUMPY_COMPILER_IS_PGI
#define NUMPY_COMPILER_IS_PGI 1

#elif defined(_CRAYC)
#undef NUMPY_COMPILER_IS_Cray
#define NUMPY_COMPILER_IS_Cray 1

#elif defined(__TI_COMPILER_VERSION__)
#undef NUMPY_COMPILER_IS_TI
#define NUMPY_COMPILER_IS_TI 1

#elif defined(__FUJITSU) || defined(__FCC_VERSION) || defined(__fcc_version)
#undef NUMPY_COMPILER_IS_Fujitsu
#define NUMPY_COMPILER_IS_Fujitsu 1

#elif defined(__ghs__)
#undef NUMPY_COMPILER_IS_GHS
#define NUMPY_COMPILER_IS_GHS 1

#elif defined(__SCO_VERSION__)
#undef NUMPY_COMPILER_IS_SCO
#define NUMPY_COMPILER_IS_SCO 1

#elif defined(__ARMCC_VERSION) && !defined(__clang__)
#undef NUMPY_COMPILER_IS_ARMCC
#define NUMPY_COMPILER_IS_ARMCC 1

#elif defined(__clang__) && defined(__apple_build_version__)
#undef NUMPY_COMPILER_IS_AppleClang
#define NUMPY_COMPILER_IS_AppleClang 1

#elif defined(__clang__) && defined(__ARMCOMPILER_VERSION)
#undef NUMPY_COMPILER_IS_ARMClang
#define NUMPY_COMPILER_IS_ARMClang 1

#elif defined(__clang__)
#undef NUMPY_COMPILER_IS_Clang
#define NUMPY_COMPILER_IS_Clang 1

#elif defined(__GNUC__) || defined(__GNUG__)
#undef NUMPY_COMPILER_IS_GNU
#define NUMPY_COMPILER_IS_GNU 1

#elif defined(_MSC_VER)
#undef NUMPY_COMPILER_IS_MSVC
#define NUMPY_COMPILER_IS_MSVC 1

#elif defined(__VISUALDSPVERSION__) || defined(__ADSPBLACKFIN__) || defined(__ADSPTS__) || defined(__ADSP21000__)
#undef NUMPY_COMPILER_IS_ADSP
#define NUMPY_COMPILER_IS_ADSP 1

#elif defined(__IAR_SYSTEMS_ICC__) || defined(__IAR_SYSTEMS_ICC)
#undef NUMPY_COMPILER_IS_IAR
#define NUMPY_COMPILER_IS_IAR 1

#endif

#if NUMPY_COMPILER_IS_GNU

  #if !((__GNUC__ * 100 + __GNUC_MINOR__) >= 404)
    #error Unsupported compiler version
  #endif

  #if defined(__GNUC__)
    #define NUMPY_COMPILER_VERSION_MAJOR (__GNUC__)
  #else
    #define NUMPY_COMPILER_VERSION_MAJOR (__GNUG__)
  #endif
  #if defined(__GNUC_MINOR__)
    #define NUMPY_COMPILER_VERSION_MINOR (__GNUC_MINOR__)
  #endif
  #if defined(__GNUC_PATCHLEVEL__)
    #define NUMPY_COMPILER_VERSION_PATCH (__GNUC_PATCHLEVEL__)
  #endif

#elif NUMPY_COMPILER_IS_Clang

  #if !(((__clang_major__ * 100) + __clang_minor__) >= 301)
    #error Unsupported compiler version
  #endif

  #define NUMPY_COMPILER_VERSION_MAJOR (__clang_major__)
  #define NUMPY_COMPILER_VERSION_MINOR (__clang_minor__)
  #define NUMPY_COMPILER_VERSION_PATCH (__clang_patchlevel__)

  #if defined(_MSC_VER)
    /* _MSC_VER = VVRR */
    #define NUMPY_SIMULATE_VERSION_MAJOR (_MSC_VER / 100)
    #define NUMPY_SIMULATE_VERSION_MINOR (_MSC_VER % 100)
  #endif

#elif NUMPY_COMPILER_IS_MSVC

  #if !(_MSC_VER >= 1600)
    #error Unsupported compiler version
  #endif

  /* _MSC_VER = VVRR */
  #define NUMPY_COMPILER_VERSION_MAJOR (_MSC_VER / 100)
  #define NUMPY_COMPILER_VERSION_MINOR (_MSC_VER % 100)
  #if defined(_MSC_FULL_VER)
    #if _MSC_VER >= 1400
      /* _MSC_FULL_VER = VVRRPPPPP */
      #define NUMPY_COMPILER_VERSION_PATCH (_MSC_FULL_VER % 100000)
    #else
      /* _MSC_FULL_VER = VVRRPPPP */
      #define NUMPY_COMPILER_VERSION_PATCH (_MSC_FULL_VER % 10000)
    #endif
  #endif
  #if defined(_MSC_BUILD)
    #define NUMPY_COMPILER_VERSION_TWEAK (_MSC_BUILD)
  #endif

#else
  #error Unsupported compiler
#endif

#endif

#endif

DimitriPapadopoulos · 2023-09-22T10:11:09Z

Please retire WIN32 and WIN64 in the process, keeping _WIN32 and _WIN64 of course. As far as I can understand and according to QM Bites: Understand Windows OS Identification Preprocessor Macros:

_WIN32 and _WIN64 are defined by the compiler,
WIN32 and WIN64 are defined by the user, to indicate whatever the user chooses them to indicate. They mean 32-bit and 64-bit Windows compilation by convention only.

* BUG: Fix order of Windows OS detection macros. - The order should be `__MINGW32__/__MINGW64__`, then `_WIN64`, and then `_WIN32`. 64 bit MinGW compilers define `_MINGW32__`, `__MINGW64__`, `_WIN32`, and `_WIN64`. 32 bit MinGW compilers define `__MINGW32__`, and `_WIN32`. 64 bit MSVC compilation defines `_WIN32` and `_WIN64`. 32 bit MSVC compilation defines `_WIN32`. - Fixes #24761. * Adjust the structure slightly and add comments. - This is better than just relying on the order of evaluation in the whole chain. Once Windows is detected (`_WIN32`), handle the possible known Windows environments separately. * Remove check for non-standard macros. - `WIN32`, `__WIN32__`, `WIN64`, `__WIN64__` are not standard macros defined by Window compilers. It should be enough to check for `_WIN32` and `_WIN64` alone.

* BUG: Fix order of Windows OS detection macros. - The order should be `__MINGW32__/__MINGW64__`, then `_WIN64`, and then `_WIN32`. 64 bit MinGW compilers define `_MINGW32__`, `__MINGW64__`, `_WIN32`, and `_WIN64`. 32 bit MinGW compilers define `__MINGW32__`, and `_WIN32`. 64 bit MSVC compilation defines `_WIN32` and `_WIN64`. 32 bit MSVC compilation defines `_WIN32`. - Fixes numpy#24761. * Adjust the structure slightly and add comments. - This is better than just relying on the order of evaluation in the whole chain. Once Windows is detected (`_WIN32`), handle the possible known Windows environments separately. * Remove check for non-standard macros. - `WIN32`, `__WIN32__`, `WIN64`, `__WIN64__` are not standard macros defined by Window compilers. It should be enough to check for `_WIN32` and `_WIN64` alone.

- There is a small bug in numpy's f2yc which does not detect MinGW environments as it is supposed to. See: numpy/numpy#24761 - This Makefile is used for MinGW only. So we can just define the variable without any other checks being needed.

* [WIP] Use UCRT64 instead of MINGW64 * [WIP] Use UCRT64 instead of MINGW64 * [WIP] OMedit can simulate models with UCRT64 * Use MSYSTEM_PREFIX for MSYS environment - Updating submodules * Runtime dependencies for OMEdit - Install QT5 plugins - Install runtime dependencies (mainly qt) using CMake install * [WIP] Build OMEdit with UCRT64 and MINGW64 CMake I hope... * Fixing const char* * UCRT64 compiling with Makefiles.omdev.mingw * Fix Cmake check OMDEv on Linux * Compile OMSimulator with gcc only (on Windows) * revert MetaModelicaDev examples * Use System_openModelicaPlatform in OMEdit for msys * Fixing OMSI CMake command * Changing linking of libbfd for OMEdit * Improving cpp build, but it still failes * Fix om_curl for clang * Fixing cpp CMake bug * [WIP] remove TLM from build * Revert all metamodelica changes * Updating Readme for MINGW64 and UCRT64 * Adding missing environment variable * Revert change: Use C:\OMDev\tools\msys * Try finding gdb from OMEdit * Fixes for MINGW64 * Fixing MINGW64 C++ Makefile build * update the Windows MinGW build job to use UCRT64 * limit the msys2 execution on w3 computer that has Msys2/UTRC64 installed * quote cmd /c build*.bat as sh translates it to a c:\ * circumvent msys2 transforming /c to c:\ * $(where cmake) doesn't seem to work * set OMDEVMSYS in OMCompiler Makefile.omdev.mingw * add missing quote * echo some info on make variables * attempt to get rid of OMDEVMSYS * add the files missed in the previous commit * geez * resolve conflict with mater * use 996OMDEV windows path instead of C:\OMDev which is msys style * remember the original OMDEV and use it for MSVC * attempt to fix saving of original OMDEV * Revert "attempt to fix saving of original OMDEV" This reverts commit 80c7f54. * OMDEV_ESCAPED is not an environment variable. - The variable is set locally in the CMake file. Attempt to evaluate it as an environment variable will just return an empty value. * Tell boost we do not want to use its CMake config files. - If MSVC, we do not want to use MSYS/MingGW installed boost's CMake config files for locating Boost We have a manually provided boost already specified using BOOST_ROOT. - This is essentially saying we do not want any help from boost itself in finding its libraries and setup. Let CMake do it alone the old way by just finding the files it knows. - The reason this might be happening now is that we have a more recent boost installed in UCRT which knows and tries to help CMake in finding it. For MSVC we do not want that help because we do not want to use the installed boost. * IF MSVC use the Lapack from OMDev. Otherwise use from MinGW. - MSVC version of Lapack, just like Boost, is shipped by OMDev along separately (not from the MSYS/MinGW packages). Use that for MSVC. * Do not set BOOST_PATH_MSVC without checking VS version. - I am not sure how this all works together. It is not the easiest thing to follow. Too many duplications and redundancies. This might not fix the latest issue where we try to use a path where the value of $(OMDEV) variable has not been subsituted yet. It is probably because it was set as $$(OMDEV). In any case first try to cleanup things and see where it actually picks the value to use for BOOST_PATH_MSVC. * Run the getMSVCversion to set the BOOST_PATH_MSVC. - Make runtimeCPPmsvcinstall_old depend on getMSVCversion. We need the BOOST_PATH_MSVC variable set. Hopefully this works(?) * Fix handling of Boost and apack for OMSICpp too. * Define NPY_OS_MINGW for OMSens on Windows/MinGW. - There is a small bug in numpy's f2yc which does not detect MinGW environments as it is supposed to. See: numpy/numpy#24761 - This Makefile is used for MinGW only. So we can just define the variable without any other checks being needed. * Test the CMake based build on ucrt labeled machines. - For this PR (until it is merged and everything has settled down) the one machine that has ucrt support is labled `omdev-ucrt`. Use only that machine to test the CMake built too. * ucrt's `libbfd` depends on libsframe and `libzstd`. - ucrt version of `libbfd` depends on `libsframe` and `libzstd` in addition to `libiberity`. Add those libraries to the linking. * Updating OMOptim, README * - change the MinGW to UCRT in Jenkinsfile and add new labels on github so we can handle them differently - fix OMSens issues and update OMOptim - get rid of OMDEV_MSYS as is not really needed and is good to keep it simple * update OMOptim sumbodule and remove OMDEV_MSYS everywhere * adapt to new ucrt labels and parameters * do not copy unnecessary files * remove msvc runtimes targets from all-runtimes * properly name stuff * Fixing CMake builds, adding OMSens - Adding CMakeLists to OMSens - Workaround in OMEdit CMake to run install multiple times - Removing TODOs * update OMSens * Adding more runtime dependencies * put back the OMPython stuff * partially adapt the python infrastructure * fix missing tab * add the missing dlls for OMEdit and omc * forgot to remove conflict markup * updáted OMSimulator * some minor updates * OMEdit fixes for msys2-ucrt64 - fix the crash reporting to properly activate the handler - add a "Crash Test" button to About dialog for easy crash testing --------- Co-authored-by: Adrian Pop <[email protected]> Co-authored-by: Mahder Gebremedhin <[email protected]>

mahge added the 00 - Bug label Sep 20, 2023

mahge mentioned this issue Sep 20, 2023

BUG: Fix order of Windows OS detection macros. #24762

Merged

mahge mentioned this issue Sep 21, 2023

Define NPY_OS_MINGW on Windows/MinGW. OpenModelica/OMSens#28

Merged

rgommers added the component: numpy.f2py label Sep 21, 2023

charris closed this as completed in #24762 Sep 23, 2023

charris mentioned this issue Sep 26, 2023

BUG: Fix order of Windows OS detection macros. #24813

Merged

rgommers added this to the 1.26.1 release milestone Apr 18, 2024

rgommers mentioned this issue Apr 19, 2024

BLD: default to C17 rather than C99 scipy/scipy#20515

Merged

This was referenced Nov 8, 2024

BLD: threads.h with MacOS 14.x ARM + gcc 14.2.0 scipy/scipy#21830

Closed

BUG: f2py threads.h on MacOS 14.x may need a shim? #27718

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

BUG: Order of OS detection macros (for Windows) seems faulty #24761

BUG: Order of OS detection macros (for Windows) seems faulty #24761

mahge commented Sep 20, 2023 •

edited

Loading

mahge commented Sep 20, 2023 •

edited

Loading

Uh oh!

mattip commented Sep 21, 2023

Uh oh!

mahge commented Sep 21, 2023 •

edited

Loading

Uh oh!

HaoZeke commented Sep 21, 2023

Uh oh!

HaoZeke commented Sep 21, 2023

Uh oh!

carlkl commented Sep 21, 2023

Uh oh!

carlkl commented Sep 21, 2023

Uh oh!

mahge commented Sep 21, 2023

Uh oh!

mahge commented Sep 21, 2023 •

edited

Loading

Uh oh!

DimitriPapadopoulos commented Sep 22, 2023

Uh oh!

Uh oh!

BUG: Order of OS detection macros (for Windows) seems faulty #24761

BUG: Order of OS detection macros (for Windows) seems faulty #24761

Comments

mahge commented Sep 20, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Describe the issue:

Reproduce the code example:

Error message:

Runtime information:

Context for the issue:

mahge commented Sep 20, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mattip commented Sep 21, 2023

Uh oh!

mahge commented Sep 21, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

HaoZeke commented Sep 21, 2023

Uh oh!

HaoZeke commented Sep 21, 2023

Uh oh!

carlkl commented Sep 21, 2023

Uh oh!

carlkl commented Sep 21, 2023

Uh oh!

mahge commented Sep 21, 2023

Uh oh!

mahge commented Sep 21, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DimitriPapadopoulos commented Sep 22, 2023

Uh oh!

mahge commented Sep 20, 2023 •

edited

Loading

mahge commented Sep 20, 2023 •

edited

Loading

mahge commented Sep 21, 2023 •

edited

Loading

mahge commented Sep 21, 2023 •

edited

Loading