RE: [fltk.general] usr/include/math.h: No such file or directory?? [General Use]

[MacArthur, Ian (Leonardo, UK)]

> I'm getting the error usr/include/math.h: No such file or directory
> compiling my small FLTK project on Windows 7 with a GCC compiler 4.81.


With the stock mingw setup, math.h doesn't usually appear at "usr/include/math.h" in the file hierarchy.

From an Msys shell, on my setup (also gcc 4.8.1) I see that at "/mingw/include/math.h" and the "DOS" path is "D:\MinGW\include\math.h" (on my system, for whatever that is worth!)

Note that the compiler usually "knows" a few default paths, and it is customary for the "stock" headers to be found there.
Also, note that the "math.h" found in "/usr/include/" (or other top level path) is quite often not the "real" math.h, but is a stub that leads to the correct math.h being loaded for a given compiler invocation.

But you want to call the stub and let the tools do their "magic", you generally do not want to subvert that by hard coding the "actual" path.



> I know why this is happening but I can't work out how to fix it.

What shell are you using to build your system, how are you invoking the compiler?



> I have included the below which is causing the error.

> #include <math.h>

The compiler ought to find the "correct" file from that, assuming the stock paths are set correctly, and the headers are in place.

(You have installed the win32 API packages and such when you install the compiler?)



> This is in C++ so I want the C++ header not the FLTK one.

The FLTK one should be fine; in essence it just wraps the system one - if it is recursing (which it seems to be) then that is telling us that the compiler did not find the "proper" math.h when it went looking.

Now: On OSX some recursion might be "normal" but on mingw/WinXX it is not - the issue then is where your system headers have gone and why is the compiler not finding them automatically?


> I've tried specifically including it with the below path but still no
> cocktail. I keep getting the above error.

> #include
> "C://mingw//lib//gcc//x86_64-w64-mingw32//5.1.0//include//c++//tr1//math.h"

I very much doubt that is the file you want to include, at least not directly anyway. There ought to be some "higher level" math.h you can include, that would (ultimately) link to that, but only if it needed to.

Anyway, hard coding that path would likely not be a portable option... You could try adding

-I"C://mingw//lib//gcc//x86_64-w64-mingw32//5.1.0//include//c++//tr1"

to your include paths and see if that helps, but it would be better to find out where the "top level" math.h had gone and why the compiler is not finding that anyway.



Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[Greg Ercolano]

On 06/07/16 05:01, MacArthur, Ian (Leonardo, UK) wrote:
> Anyway, hard coding that path would likely not be a portable option... You could try adding
> -I"C://mingw//lib//gcc//x86_64-w64-mingw32//5.1.0//include//c++//tr1"
> to your include paths and see if that helps,

Just an aside; when using front slashes (/) I don't think you'll
need (or want) to double up the slashes. If the C: weren't there,
it'd look too much like a UNC path, which would be bad.

[MacArthur, Ian (Leonardo, UK)]

> It would seem to me that you want
> #include <cmath>
> then if needed, add std:: in front of whatever math routine your are
> calling.

> math.h is deprecated for c++


Meh... While *technically* true, I'm less than convinced it is really a Good Idea.

These days, pretty much *all* (dangerous generalisation) of the stock C system headers have #ifdef _cplus_plus type guards in them to mark the code as extern("C"), and so they work just fine in C++ code.

For the most part, I’d expect that to be (pretty much) all the <cmath> et al do now, but on at least one occasion I have been caught out by a cmath that was trying to be too smart for its own good (or anyone else's, as it turned out.)

The upshot was that the API it exported *did not* match what the underlying C lib did, and weird code errors arose. Very tricky to debug. Painful for all concerned.

Now, that's a rare occurrence, and I have not seen that sort of failure recently, but for me it was a cautionary lesson.

So, my take on this is: use the header that matches the lib, if it is a C-lib, use the C-header. If you need to mark it extern("C") yourself then so be it, but that seldom happens these days.

[MacArthur, Ian (Leonardo, UK)]

> Thing is, typically the compiler should know where to find
> its own include files, so it's kinda weird you have to tell
> it where to look with -I to find compiler include files.
>
> Might be something wrong with your compiler environment there,
> not sure.


Agree: I'd go so far as to say that I'm convinced there must be something wrong with Svet's compiler environment, since this really should Just Work.

[Svets]

Hi Greg and Ian, thanks for your replies.  I think you're both right on this, it's probably something I've done when setting up my compiler environment.  This is a newer PC I'm using so I rebuilt everything (albiet incorrectly in some cases).

I've never had this issue before (especially with FLTK) so I'll just have to back-track a work things out.

Thanks for the help ;)

[MacArthur, Ian (Leonardo, UK)]

> Hi Greg and Ian, thanks for your replies. I think you're both right on
> this, it's probably something I've done when setting up my compiler
> environment. This is a newer PC I'm using so I rebuilt everything
> (albiet incorrectly in some cases).

> I've never had this issue before (especially with FLTK) so I'll just
> have to back-track a work things out.

It has the look of something missing from the compiler installation - can you check that mingw and its supporting environ are set up OK, then see how things fly after that?

[Svets]

Hi Ian,, I think you are right.

Here's the path of the actual math file I'm looking for.

C:\mingw\lib\gcc\x86_64-w64-mingw32\5.1.0\include\c++\tr1\math.h

but I believe the below path is also searched by default by my mingw compiler.

c:/mingw/include

So I'm guessing from this I shouldn't have installed my compiler on the same path as my build environment.  Would that be right?

I always have trouble with these things but if this is right then it will help allot.  

The reason I say this is because there is a math.h file in

c:/mingw/include/FL/math.h

[MacArthur, Ian (Leonardo, UK)]

> Here's the path of the actual math file I'm looking for.

> C:\mingw\lib\gcc\x86_64-w64-mingw32\5.1.0\include\c++\tr1\math.h

No; I really do not think that it is - you should be calling the top-level "system" math.h, never the implementation specific parts.

The top-level math.h should be there to make sure that the "correct" math.h parts are included for the current build config; e.g. if you have multiple compiler personalities for different cross-compilers and so forth.

You should have a file in "/mingw/include/math.h", and that should be the one the compiler finds first.

From there, the compiler may then decide to include various other "math.h" parts from around the installation to pick up all the bits it needs for the current compilation, but you should not need to know the details for that, the compiler should be doing that "right".

You just need to call the "system" math.h and let the tools sort out what they need.
You should not be calling the specific low-level implementation parts.

> but I believe the below path is also searched by default by my mingw
> compiler.

> c:/mingw/include

Are you running from the Msys environment? Is it working right?

For me, all the "system" headers appear at "/mingw/include" (note that there is NO leading drive letter there) and it all Just Works.

From an Msys shell, I do:-

$ ls /mingw/include/math.h
/mingw/include/math.h


That is the file your compiler should be finding.

You can see some of where the compiler tries to look by passing "-v" to gcc when it compiles a file; you get chatter like this:-

$ gcc -v win_version.c -o test.exe
Using built-in specs.
COLLECT_GCC=D:\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=d:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto --enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T
Thread model: win32
gcc version 4.8.1 (GCC)
COLLECT_GCC_OPTIONS='-v' '-o' 'test.exe' '-mtune=generic' '-march=pentiumpro'
d:/mingw/bin/../libexec/gcc/mingw32/4.8.1/cc1.exe -quiet -v -iprefix d:\mingw\bin\../lib/gcc/mingw32/4.8.1/ win_version.c -quiet -dumpbase win_version.c -mtune=generic -march=pentiumpro -auxbase win_version -version -o C:\Users\IAN~1.MAC\AppData\Local\Temp\ccs65yWG.s
GNU C (GCC) version 4.8.1 (mingw32)
compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory "d:/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/include"
ignoring duplicate directory "d:/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/../../../../include"
ignoring duplicate directory "/mingw/include"
ignoring duplicate directory "d:/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/include-fixed"
ignoring duplicate directory "d:/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/../../../../mingw32/include"
ignoring duplicate directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
d:\mingw\bin\../lib/gcc/mingw32/4.8.1/include
d:\mingw\bin\../lib/gcc/mingw32/4.8.1/../../../../include
d:\mingw\bin\../lib/gcc/mingw32/4.8.1/include-fixed
d:\mingw\bin\../lib/gcc/mingw32/4.8.1/../../../../mingw32/include
End of search list.
GNU C (GCC) version 4.8.1 (mingw32)
compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 767202a405449496e68a54c4eee91a28
COLLECT_GCC_OPTIONS='-v' '-o' 'test.exe' '-mtune=generic' '-march=pentiumpro'
d:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/as.exe -v -o C:\Users\IAN~1.MAC\AppData\Local\Temp\ccLgDxdk.o C:\Users\IAN~1.MAC\AppData\Local\Temp\ccs65yWG.s
GNU assembler version 2.24 (mingw32) using BFD version (GNU Binutils) 2.24
COMPILER_PATH=d:/mingw/bin/../libexec/gcc/mingw32/4.8.1/;d:/mingw/bin/../libexec/gcc/;d:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/
LIBRARY_PATH=d:/mingw/bin/../lib/gcc/mingw32/4.8.1/;d:/mingw/bin/../lib/gcc/;d:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/lib/;d:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../
COLLECT_GCC_OPTIONS='-v' '-o' 'test.exe' '-mtune=generic' '-march=pentiumpro'
d:/mingw/bin/../libexec/gcc/mingw32/4.8.1/collect2.exe -Bdynamic -o test.exe d:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../crt2.o d:/mingw/bin/../lib/gcc/mingw32/4.8.1/crtbegin.o -Ld:/mingw/bin/../lib/gcc/mingw32/4.8.1 -Ld:/mingw/bin/../lib/gcc -Ld:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/lib -Ld:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../.. C:\Users\IAN~1.MAC\AppData\Local\Temp\ccLgDxdk.o -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt d:/mingw/bin/../lib/gcc/mingw32/4.8.1/crtend.o


From this, you can see the directories the compiler is looking in to find what it needs.
Your "system" headers should be found in these paths; if they are not, you need to figure out why not and make sure they are installed correctly!

> So I'm guessing from this I shouldn't have installed my compiler on the
> same path as my build environment. Would that be right?

I don't think that is the issue here. This should work.

> I always have trouble with these things but if this is right then it
> will help allot.

> The reason I say this is because there is a math.h file in
> c:/mingw/include/FL/math.h

But that should not matter. If you ask for:-

#include <math.h> // note angle brackets, not quote marks //

Then it should always find "/mingw/include/math.h" before it finds "/mingw/include/FL/math.h", since the first folder is above the second; and there ought to be no problem.

[Svets]

Just letting you know that I looked at my build environment again and could not find the problem.  Soo... I rebuilt my libraries and made sure I prefixed things correctly.  It has somehow mysteriously fixed the problem so you were right..... it was the build environment.   

I can now use math.h without any issues..

Thanks for the help.