8

I am trying to cross-compile OpenImageIO for 64-bit Windows on Fedora 26 using MinGW. After using yum to retrieve the mingw versions of the dependencies, I ran mingw64-cmake followed by make. However, right away I receive a compile error about stdlib.h not being found.

[  0%] Built target CopyFiles
[  0%] Building CXX object src/libutil/CMakeFiles/OpenImageIO_Util.dir/argparse.cpp.obj
In file included from .../oiio/src/libutil/argparse.cpp:36:0:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
#include_next <stdlib.h>
              ^~~~~~~~~~
compilation terminated.

I have confirmed that stdlib.h is found at least in /usr/include/ and in /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/ where the file giving the compiler error also is located.

Why do I still receive the error stdlib.h: No such file or directory?

Update: I did additional research and learned the following: The preprocessor directive #include_next behaves like the #include directive, except that it specifically excludes the directory of the including file from the paths to be searched for the named file.

This would explain why cstdlib does not find stdlib.h from the same folder. But cstdlib is part of MinGW and not any part of the code I am trying to compile. So I still have no idea what is wrong here or how to fix this error.

Edit: Here is the compiler version info in case it is of any use: https://pastebin.com/PZiXS2fg. This is a fresh install so there shouldn't be anything unusual there, though.

Steve
  • 374
  • 1
  • 4
  • 13
  • Out of curiosity, which `g++` version is included with your `mingw64`? – TriskalJM Jul 24 '17 at 18:32
  • @TriskalJM gcc version 7.1.0 20170502 (Fedora MinGW 7.1.0-1.fc26) – Steve Jul 25 '17 at 11:56
  • Isn't there a `stdlib.h` in your `/usr/x86_64-w64-mingw32/sys-root/mingw/include/` which would be found by `#include_next`? – ssbssa Jul 29 '17 at 15:00
  • @ssbssa there is a `stdlib.h` in the `/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++` folder, but not in the `include` folder. The `c++` folder is also where it should be looking for it. – Steve Jul 30 '17 at 17:48
  • That's not what my `cstdlib` says: `// Need to ensure this finds the C library's not a libstdc++ // wrapper that might already be installed later in the include search path. #define _GLIBCXX_INCLUDE_NEXT_C_HEADERS #include_next ` And the C library's `` should definitely *not* be in the `c++` folder. – ssbssa Jul 30 '17 at 17:52
  • @ssbssa My bad, there IS a `stdlib.h` also in the `/usr/x86_64-w64-mingw32/sys-root/mingw/include` folder. The other `stdlib.h` in `c++` folder is a `C++ compatibility header` according to the comment in the file. Regardless, it seems that neither file is found by the `#include_next`. – Steve Jul 30 '17 at 18:03
  • 1
    Sounds bad. Does it find it if you compile just `#include ` with `g++ -c`, or just `#include ` with `gcc -c`? – ssbssa Jul 30 '17 at 18:13
  • @ssbssa Both of those one-liners seem to compile. – Steve Jul 30 '17 at 18:21
  • Can you add the output of `make VERBOSE=1`, so we will know the full command line options used to compile argparse.cpp? – ssbssa Jul 30 '17 at 18:30
  • @ssbssa [`make VERBOSE=1` output here](https://pastebin.com/mJz2xTN7). From that I just found out that the contents of [CMakeFiles/OpenImageIO_Util.dir/includes_CXX.rsp](https://pastebin.com/Fne5HVEs) might be related to the issue - it seems to contain `-isystem /usr/x86_64-w64-mingw32/sys-root/mingw/include` which contains a copy of `stdlib.h`. Removing this statement gives me [a completely different error](https://pastebin.com/xsAu2zvs) instead. I am looking into whether this is now a completely independent problem. – Steve Jul 30 '17 at 18:42
  • I wonder why those `-isystem` are there at all (both), since those directories should be found automatically by the compiler. – ssbssa Jul 30 '17 at 18:59
  • 1
    @ssbsa I wonder the same. However, removing the `-isystem` from the `CMakeFile` seems to fix the problem. The new error I got afterwards I simply worked around by eliminating the unnecessary Win32-specific defines from `oiio/src/include/OpenImageIO/missing_math.h`. Now there are no more errors and it seems to compile. Thanks for the hints! Still need to figure out where that `-isystem` is coming from and how to fix that without having to directly edit CMakeFiles after cmake and this could be turned into an answer. – Steve Jul 30 '17 at 19:31

2 Answers2

5

I solved it, i can compile again.

The solution (for me) is add to path the variable CPLUS_INCLUDE_PATH and set it to the MinGW c++ include directory, for me: C:\MinGW\lib\gcc\mingw32\6.3.0\include\c++.

I hope it works for you too.

izanbf1803
  • 51
  • 5
1

The use of #include_next appears to cause lots of issues based on my Googling. Try directly including stdlib.h using the following syntax:

-isystem /usr/x86_64-w64-ming32/sys-root/mingw/include/c++

This syntax was added in gcc 6.0 to solve issues with third-party libraries. See here for the approach and reasoning.

Edit: Changed answer to reflect new information about gcc wrapper_headers and #include_next

TriskalJM
  • 2,393
  • 1
  • 19
  • 20
  • Those are GCC configure flags. Are you suggesting to recompile GCC? – Florian Weimer Jul 25 '17 at 08:21
  • I tried running: `mingw64-cmake -DCMAKE_CXX_FLAGS='--with-gxx-include-dir=/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++ --enable-version-specific-runtime-libs'` But I receive: `unrecognized command line option '--with-gxx-include...'` – Steve Jul 25 '17 at 12:21
  • @TriskalJM I added the `-isystem /usr/x86_64-w64-ming32/sys-root/mingw/include/c++ flag`, confirmed with `make -n` that g++ is indeed being run with the flag, and confirmed that `stdlib.h` is in that directory. Still get the exact same error, though. – Steve Jul 26 '17 at 11:57
  • You mentioned two directories that contain a version of `stdlib.h`. Which version is g++ pulling in? – TriskalJM Jul 26 '17 at 13:03
  • @TriskalJM The g++ arguments are as follows: pastebin.com/LHcqqAkr. Full g++ version info here https://pastebin.com/PZiXS2fg. I have the default `--includedir=/usr/include` which is where the other version of `stdlib.h` is. I have a fresh installation of Fedora 26 and newest version of the packages, haven't done any changes which should cause problems. – Steve Jul 26 '17 at 13:21
  • It might be the search order. Does `/usr/include` get included first, or does `/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/`? – TriskalJM Jul 26 '17 at 13:36
  • @TriskalJM I am unsure. As can be seen in the pastebin link above, even without the `-isystem` flag these directories are already included in the g++ configuration with `--includedir` and `with-gxx-include-dir` with the flags in this order. Whether they actually get included in this order I couldn't figure out from the documention. – Steve Jul 30 '17 at 17:45