Menu
▾
▴
[MinGW-notify] [ mingw-Patches-3011968 ] cooperation between gcc's and mingw's float.h
|
From: SF/projects/mingw n. l. <min...@li...> - 2012-06-01 19:45:34
|
Patches item #3011968, was opened at 2010-06-05 23:59 Message generated for change (Comment added) made by earnie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=302435&aid=3011968&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: gcc Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: mark (mabrand) Assigned to: Cesar Strauss (cstrauss) Summary: cooperation between gcc's and mingw's float.h Initial Comment: Both mingw and gcc have a float.h. The mingw version supplements the gcc version, declaring _clear87 and _control87 among other things. The mingw version has an #include_next which is meant to include the gcc version. This works only when the mingw include dir is first in the header search path, which may not be correct. When the header search list is ordered with the mingw include directory after the gcc's, a common symptom is that _clear87 and _control87 are undeclared. A web search for "mingw gcc float.h _clear87" turns up lots of references to this problem, one of which is here: http://bugreports.qt.nokia.com/browse/QTBUG-7576. An easy (and correct?) solution is to move the #include_next<float.h> from the mingw version into the gcc version. The attached patches do this. But I imagine some discussion might be needed. These patches are against tarballs gcc-4.5.0.tar.bz2 and mingwrt-3.18-mingw32-dev.tar.gz. For ease of reference, both patches are attached. ---------------------------------------------------------------------- >Comment By: Earnie Boyd (earnie) Date: 2012-06-01 12:45 Message: A work around with newer versions of GCC may be to use "float.h" instead of <float.h> and specify -iquote/mingw/include on the command line. See http://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html ---------------------------------------------------------------------- Comment By: Totte (tottekarlsson) Date: 2012-06-01 12:24 Message: This problem just hit me when compiling some older version of clapack. When browsing for float.h, there are three (3) float.h under the MinGW install folder (that by itself is in my opinion a problem). In your solution above, you reference the 'gcc-version'. Which one is that? There is one float.h in C:\MinGW\lib\gcc\mingw32\4.6.2\include\c++\tr1 another in C:\MinGW\lib\gcc\mingw32\4.6.2\include and one in C:\MinGW\include Thanks ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2010-06-18 07:09 Message: Hmm. Cross compilers add a new dimension to this. Even our own GCC-3.4.5, when properly configured as a cross compiler, will expect to find the sysroot includes, (which is where the mingwrt headers belong), *after* the GCC specifics. You are quite correct; there *is* an issue to be addressed here, but I'm afraid that your proposed patch is too naive. A correctly configured natively hosted GCC, on Win32 and dependent on mingwrt, *should* expect to find the mingwrt headers first in the search path, while a correctly configured cross hosted GCC, for a mingw32 target, will expect to find the GCC specific headers first. I will accept a patch to mingwrt, which comprehends both requirements; I've attached a suitable candidate. However, that alone will not adequately address the issue; we must rely on Danny or Aaron to champion a complementary adjustment in the GCC supplied float.h, or on Cesar to maintain a local patch, (which I'm sure he will prefer to avoid). > If it weren't for backwards compatibility, > might there be good reasons for reversing > this design decision [natively hosted GCC > expecting mingwrt headers first]? > For example, would there be some > sort of an advantage to having installed > library headers in the more typical > "/usr/include" position after the > gcc directories? I don't think so. As Danny has already pointed out, there is no /usr/include in a standard MS-Windows configuration. Even if you create one, it's location isn't deterministic; (which of an arbitrary number of arbitrarily named device roots owns it)? No, we need a solution which can accommodate a non-deterministic search order. ---------------------------------------------------------------------- Comment By: mark (mabrand) Date: 2010-06-11 03:27 Message: I really appreciate the explanation which has improved my understanding of the subject. Possibly I was led astray by mingw build environments packaged for cross bulding by popular Linux distros. I'm pretty sure that the mingw header directory comes after the gcc ones on at least one of these using gcc 4.4. The other thing that leads astray is gcc's default search order (at least with gcc 4.5.) Perhaps this is what led the distros astray. Is this so clearly wrong that a bug report should be filed with the distro? I'd appreciate your comments on this. Also, I am intrigued by this remark: >The first is the mingwrt header path; the second the upstream target-specific GCC header path. Please don't forget that mingwrt is an essential component of a MinGW GCC installation; as such, it is effectively a *part* of a correctly configured GCC on Win32, and its design has always presumed that its headers will be the first in the system search path. To avoid breaking backward compatibility, for the (I believe significant) corpus of users who continue to rely on GCC-3.4.5 as a production compiler, that design philosophy needs to propagate forward into MinGW GCC-4.x. If it weren't for backwards compatibility, might there be good reasons for reversing this design decision? For example, would there be some sort of an advantage to having installed library headers in the more typical "/usr/include" position after the gcc directories? ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2010-06-10 06:37 Message: > Now mswindows didn't have a standard_includedir (/usr/include) > when mingw32 was first developed. It still doesn't. Thats why, > mingwrt headers are installed in what gcc consider the > local include dir To elaborate further: A critical implication of this is that, besides GCC's own (upstream-sourced) language specific and target specific include paths, there is ONLY ONE include directory, into which the mingwrt developers can install implementation dependent header files, and which is guaranteed to be added to GCC's default system search path; that directory is thus expected to PRECEDE the language and target specifics, in the search order. Past MinGW developers have made design decisions based on a presumption of that search order, and that presumption must now be honoured in perpetuity. A secondary consequence of this is that there is also only one directory into which user added additional headers (and analogously, accompanying libraries) may be installed, such that the compiler can find them automatically; that is one and the same as the directory where mingwrt headers are installed. Thus, project policy has always been to recommend admixture of user added components and MinGW system components in the same locations. That's not a policy to which I personally subscribe, (hence my locally customised specs file), but it is the simplest advice to offer to less sophisticated users, who probably don't want to get down-and-dirty with such local customisation. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2010-06-10 04:59 Message: As you know, the first place that GCC looks for "standard" headers is in the local_includediir. In src/gcc/config/i386/x-mingw32 (the host makefile fragment for mingw32)" # Make local_includedir relative to EXEC_PREFIX # local_includedir=$(libsubdir)/$(unlibsubdir)/..`echo $(exec_prefix) | sed -e 's|^$(prefix)||' -e 's|/[^/]*|/..|g'`/include So regardless of where gcc is installed on a mswindows host, it should be able to find those headers. Now mswindows didn't have a standard_includedir (/usr/include) when mingw32 was first developed. It still doesn't. Thats why, mingwrt headers are installed in what gcc consider the local include dir ---------------------------------------------------------------------- Comment By: mark (mabrand) Date: 2010-06-10 02:42 Message: Thanks for elaborating. > The correct understanding would be that the mingwrt headers are a fundamental part of MinGW GCC itself Given this, what is your view on headers for other installed libraries being in this directory? (It seems strange for a header like zlib.h, normally in "/usr/include", to be there.) ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2010-06-10 02:24 Message: You are referring to documentation which explicitly relates to "a normal Unix system"; MS-Windows32 is not such a system. In all MinGW releases prior to GCC-4.x, (up to GCC-3.4.5), the presumption has always been that the mingwrt headers set up the appropriate preconditions to pre-empt the Win32 specific requirements of the GCC supplied headers. $ gcc -v -c nul.c Reading specs from d:/usr/mingw-3.4.5/bin/../lib/gcc/mingw32/3.4.5/specs ... gcc version 3.4.5 (mingw special) ... #include "..." search starts here: #include <...> search starts here: d:/usr/local/include d:/usr/mingw-3.4.5/bin/../lib/gcc/mingw32/3.4.5/../../../../include d:/usr/mingw-3.4.5/bin/../lib/gcc/mingw32/3.4.5/include End of search list. ... Once again, the d:/usr/local/include is a local specs file customisation, but the other two are the standards set by MinGW GCC-3.4.5 itself; if you canonicalise them, they become: d:/usr/mingw-3.4.5/include d:/usr/mingw-3.4.5/lib/gcc/mingw32/3.4.5/include The first is the mingwrt header path; the second the upstream target-specific GCC header path. Please don't forget that mingwrt is an essential component of a MinGW GCC installation; as such, it is effectively a *part* of a correctly configured GCC on Win32, and its design has always presumed that its headers will be the first in the system search path. To avoid breaking backward compatibility, for the (I believe significant) corpus of users who continue to rely on GCC-3.4.5 as a production compiler, that design philosophy needs to propagate forward into MinGW GCC-4.x. > Do you think the right understanding is actually that the mingwrt headers > directory corresponds to "/usr/local/include"? No. My locally configured d:/usr/local/include would be the equivalent of that. The correct understanding would be that the mingwrt headers are a fundamental part of MinGW GCC itself -- i.e. they *are* GCC headers, within the context of a MinGW installation -- and they are intended to precede the upstream-sourced headers in the GCC system search path. ---------------------------------------------------------------------- Comment By: mark (mabrand) Date: 2010-06-10 01:26 Message: Thanks for your comment Keith. I'm trying to understand your statement, "headers provided by the MinGW runtime package should *always* be the first in the search", in the context of this bit of the GCC docs: http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html <quote> GCC looks in several different places for headers. On a normal Unix system, if you do not instruct it otherwise, it will look for headers requested with #include <file> in: /usr/local/include libdir/gcc/target/version/include /usr/target/include /usr/include </quote> My patch is based on my (admittedly shaky) understanding that the mingw rt headers directory corresponds to "/usr/target/include" or "/usr/include" in the list above, both of which come after the gcc headers. This made sense to me because this is the directory where headers from mingw and mingw-compatible libraries reside. Do you think the right understanding is actually that the mingwrt headers directory corresponds to "/usr/local/include"? ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2010-06-09 04:44 Message: I'm far from convinced that your solution is correct; the headers provided by the MinGW runtime package should *always* be the first in the search path, for a correctly configured compiler installation. IIRC, there were some issues with the first release of MinGW GCC-4.5, (and possibly with earlier GCC-4.x releases), which resulted in a misconfiguration if you installed *anywhere* other than the project's specified default location, (i.e. c:/mingw). That could certainly cause the issue you report. For my own installation, in d:/usr/mingw-4.5.0, I worked around this by adding the missing include path via a locally modified specs file (attached): $ gcc -v -c nul.c Reading specs from d:/usr/mingw-4.5.0/bin/../lib/gcc/mingw32/4.5.0/specs ... ignoring nonexistent directory "c:/mingw/include" ... #include "..." search starts here: #include <...> search starts here: d:/usr/local/include d:/usr/mingw-4.5.0/include d:\usr\mingw-4.5.0\bin\../lib/gcc/mingw32/4.5.0/include d:\usr\mingw-4.5.0\bin\../lib/gcc/mingw32/4.5.0/include-fixed End of search list. ... $ g++ -v -c nul.cpp Reading specs from d:/usr/mingw-4.5.0/bin/../lib/gcc/mingw32/4.5.0/specs ... ignoring nonexistent directory "c:/mingw/include" ... #include "..." search starts here: #include <...> search starts here: d:/usr/local/include d:/usr/mingw-4.5.0/include d:\usr\mingw-4.5.0\bin\../lib/gcc/mingw32/4.5.0/include/c++ d:\usr\mingw-4.5.0\bin\../lib/gcc/mingw32/4.5.0/include/c++/mingw32 d:\usr\mingw-4.5.0\bin\../lib/gcc/mingw32/4.5.0/include/c++/backward d:\usr\mingw-4.5.0\bin\../lib/gcc/mingw32/4.5.0/include d:\usr\mingw-4.5.0\bin\../lib/gcc/mingw32/4.5.0/include-fixed End of search list. ... Note that, in both cases, the d:/usr/local/include is my own local customisation, and d:/usr/mingw-4.5.0/include is the missing path, which the compiler omitted because it expected the non-existent c:/mingw/include instead, and which I've added as a second local customisation, even though it should have been there in the first place. I know the maintainer for MinGW GCC-4.5 (Cesar Strauss) was made aware of this issue; I believe, (but am not certain), that he addressed it in a follow up release. In addition to attaching my locally modified specs file, I have attached (as specs.diff) the output from $ gcc -dumpspecs | diff -u - d:/usr/mingw-4.5.0/lib/gcc/mingw32/4.5.0/specs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=302435&aid=3011968&group_id=2435 |