MinGW g++ doesn't find headers in its own include directory

18,243

Solution I came up with: based on Michael Burr's comment above I ran the compiler with the verbose flag. For some reason, the include directory that is searched is not located in the MinGw root directory, but buried in the lib directory. I expect that this was intended to be fixed with one of the installation scripts, but I either didn't run it correctly or it didn't work on my system. The directory where I needed to add the relevant files is, on my machine,

C:\MinGW\lib\gcc\x86_64-w64-mingw32\4.8.2\include

This is a quick-and-dirty fix. I'm sure that there's a better way, but this got me up and running the quickest.

Share:
18,243

Related videos on Youtube

tjtoml
Author by

tjtoml

I'm an ISMN student at Auburn University. War Eagle!

Updated on June 26, 2022

Comments

  • tjtoml
    tjtoml almost 2 years

    So I recently installed MinGW via the latest version of nuwen's MinGW distribution that includes the boost C++ libraries. Specifically, I was after the scoped_ptr that the boost library provides. However, when I try to include the scoped_ptr (#include <boost/scoped_ptr.hpp>) in my header, the compiler throws
    error: boost/scoped_ptr.hpp: No such file or directory

    Makefile:

    compile:
        g++ -o gen/cavestory src/**.cc 
    run:
        gen/cavestory
    

    Also, I added a back version of SDL to MinGW's include directory under SDL/**. All of the header files are there, I've checked, and the compiler throws a similar error on my include SDL/SDL.h>.

    Things I've tried:
    Every variation of <> and "" in my include statements
    Removing the .h and .hpp
    Setting the compiler flags to specifically search the directories containing the headers with g++ -I

    This code was compiling with an earlier version of MinGW, and the author of the MinGw distrobution specifically states that he changed the g++ compiler options to default to C++11, so I think it's very likely that it's something to do with that. My google-fu has not yeilded results, though.

    • Rapptz
      Rapptz about 10 years
      Your mingw might be getting shadowed.
    • Michael Burr
      Michael Burr about 10 years
      Create an empty empty.c file, then issue the command: gcc -v empty.c. Paste the output into your question. Included in the spew will be the directories that the compiler will search for include file in. Assuming you've installed the nuwen distro into c:\mingw, scoped_ptr.hpp should be in `c:\mingw\include\boost`
    • Michael Aaron Safyan
      Michael Aaron Safyan
      Try "which g++" in the make file to figure out which is getting invoked. By the way, you shouldn't be hard-coding "g++" in your Makefiles. This is bad form. Please see: sites.google.com/site/michaelsafyan/software-engineering/…
  • Michael Burr
    Michael Burr about 10 years
    Ah-ha - I've been running the set_distro_paths.bat script to set the path to MinGW's executables. Little did I know it also adds (or sets) a couple directories, such as c:\mingw\include to the C_INCLUDE_PATH and CPLUS_INCLUDE_PATH environment variables. That's what gets boost and friends. I thought that set_distro_paths.bat only set the path.
  • Michael Burr
    Michael Burr about 10 years
    Also, it's interesting/weird that using the -I option didn't get things working for you. Maybe you specified -I c:\mingw\include\boost instead of just -I c:\mingw\include?
  • tjtoml
    tjtoml about 10 years
    I tried both. I'm now slamming my head against the linker not being able to locate SDL.lib and SDLMain.lib. I'm getting undefined reference to every SDL_* call
  • Michael Burr
    Michael Burr about 10 years
    You might want to post the -v output in your question. Also, keep in mind that since release 11.0, nuwen's MinGW is x64 native (it defaults to building x64 targets - I think that it doesn't even support the -m32 option to build a 32-bit target), so make sure any libraries you're adding to your build are also x64. If you've installed 32-bit SDL libs that could be a reason for undefined references, since some name mangling rules for x86 and x64 are different.