From: Charles W. <cwi...@us...> - 2010-07-22 23:46:56
|
Cesar, you should probably take a look at this thread. I think, in order to fix some possible problems with cross-compiling and sys-roots, the gcc folks are looking at making a change in the default search order of includes. This may or may not affect our (native) compiler. The folks on the thread seem to think that it will, but *we* haven't installed our runtime headers in /usr/local/include in forever, so I'm not sure what the problem is. Anyway, it bears a closer look, so I thought I'd give you a heads-up. http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01670.html -- Chuck -------- Original Message -------- Subject: Re: [patch win32]: fix for PR target/41943 Date: Thu, 22 Jul 2010 16:27:44 +0300 From: Ozkan Sezer To: Richard Guenther CC: Kai Tietz, Danny Smith, Richard Henderson, Dave Korn, gcc-patches-at-gcc-gnu-org >> That's right and therefore I dislike this patch and would prefer to >> have that one Ozkan mentioned already. The issue is that sysroot & >> cross- includes come after gcc's internal header, which is causing the >> pain that it isn't absolutely predicatable, if system-headers are >> reached or not. >> By changing the order of gcc's internal to the end of the include >> chain, it would be solved for all cases. > > Well, I think moving gcc headers to the end of the include chain is > just wrong. ?They are supposed to override host ones (which is > why they are called "fixincludes"). ?Why not fixinclude mingw? > > Richard. > The message that is referred to is this : http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01450.html ... and its subject line is wrong/misleading: The patch contained there (http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01450/do_fixinclude_later.diff) moves the gcc-private headers and not the fixed headers. -- Ozkan |
From: Kai T. <kti...@go...> - 2010-07-23 07:58:02
|
Hi Charles and Ceasar, 2010/7/23 Charles Wilson <cwi...@us...>: > Cesar, you should probably take a look at this thread. I think, in order > to fix some possible problems with cross-compiling and sys-roots, the > gcc folks are looking at making a change in the default search order of > includes. > > This may or may not affect our (native) compiler. The folks on the > thread seem to think that it will, but *we* haven't installed our > runtime headers in /usr/local/include in forever, so I'm not sure what > the problem is. IMHO this will affect you. Therefore I tried to find a different solution on gcc for not touching this, but as we all have to learn here is it a conceptional flaw to install headers in (/usr/local/include = STANDARD_INCLUDE_DIR for gcc). This STANDARD_INCLUDE_DIR is renamed by win32 targets to "/mingw/include". It is a matter of the search order of gcc's preprocessor. So to correct you, you are using this standard_include (I assume without known it is in fact standard_include) for a very long time. Regards, Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | (")_(") him gain world domination |
From: Earnie <ea...@us...> - 2010-07-23 14:37:14
|
Kai Tietz wrote: > Hi Charles and Ceasar, > > 2010/7/23 Charles Wilson<cwi...@us...>: >> Cesar, you should probably take a look at this thread. I think, in order >> to fix some possible problems with cross-compiling and sys-roots, the >> gcc folks are looking at making a change in the default search order of >> includes. >> >> This may or may not affect our (native) compiler. The folks on the >> thread seem to think that it will, but *we* haven't installed our >> runtime headers in /usr/local/include in forever, so I'm not sure what >> the problem is. > > IMHO this will affect you. Therefore I tried to find a different > solution on gcc for not touching this, but as we all have to learn > here is it a conceptional flaw to install headers in > (/usr/local/include = STANDARD_INCLUDE_DIR for gcc). This > STANDARD_INCLUDE_DIR is renamed by win32 targets to "/mingw/include". > It is a matter of the search order of gcc's preprocessor. So to > correct you, you are using this standard_include (I assume without > known it is in fact standard_include) for a very long time. > I think we knew it but because of the relative ../ pathing as is shown in the snippet below we really don't care too much. <snippet> gcc version 3.4.5 (mingw-vista special r3) c:/opt/mingw/bin/../libexec/gcc/mingw32/3.4.5/cc1.exe -quiet -v -iprefix c:\opt\mingw\bin\../lib/gcc/mingw32/3.4.5/ a.c -quiet -dumpbase a.c -auxbase a -version -o C:/DOCUME~1/EARNIE~1/LOCALS~1/Temp/ccD4Nh7q.s ignoring nonexistent directory "c:/opt/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw32/include" ignoring nonexistent directory "/mingw/include" ignoring nonexistent directory "/mingw/include" ignoring nonexistent directory "/mingw/lib/gcc/mingw32/3.4.5/include" ignoring nonexistent directory "/mingw/mingw32/include" ignoring nonexistent directory "/mingw/include" #include "..." search starts here: #include <...> search starts here: c:/opt/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include </snippet> The "c:/opt/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../include" is the default for the Windows GCC but you can't assign such a string to a constant. If you have gcc installed into c:/mingw and your active disk is C: then GCC will find /mingw/include. However, if you active disk is something else it will find the relative directory as it has for me. Maybe this relative path method should be used in *NIX as well to allow GCC to find a non standard install set of headers and libraries. Earnie |
From: Keith M. <kei...@us...> - 2010-07-23 16:34:25
|
On Friday 23 July 2010 00:46:22 Charles Wilson wrote: > Cesar, you should probably take a look at this thread. I think, in > order to fix some possible problems with cross-compiling and > sys-roots, the gcc folks are looking at making a change in the > default search order of includes. > > This may or may not affect our (native) compiler. As Kai has noted, I think it probably will. Notwithstanding, there is a serious issue which needs to be resolved; see below... > The folks on the > thread seem to think that it will, but *we* haven't installed our > runtime headers in /usr/local/include in forever, so I'm not sure > what the problem is. The problem, AIUI, is that to map <MINGW_ROOT>/include into the search path, the GCC build process subverts the use of its local_includedir [*] build time variable, (as specified in a host makefile fragment), which in the normal scenario, for builds on other platforms, would typically be mapped to /usr/local/include. [*] Danny refers to it thus, on our tracker ticket (referenced below), and as LOCAL_INCLUDE_DIR, in this gcc-patches thread... > Anyway, it bears a closer look, so I thought I'd give you a heads-up. > http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01670.html This seems to be related to: https://sf.net/tracker/?func=detail&aid=3011968&group_id=2435&atid=302435 AFAICT, it is only float.h, among *our* headers, which exhibits any serious problem in this respect, although there may also be a related minor issue affecting varargs.h In both of these cases, our mingwrt system headers are designed to co-operate with GCC's own similarly named headers. While I can fully understand Danny's reasoning behind the implementation which he has provided, with all due respect, and apologies, this "solution" may be fundamentally flawed, (as Kai has also noted); it actually *breaks* any correctly configured cross-compiler which relies on mingwrt to furnish system headers. It relies on an adverse placement of mingwrt headers within the GCC include path, when compiling natively on Win32, and this placement is not only contrary to the normal GCC convention in every other operating environment; it is contrary to the placement achieved with a correctly configured cross-compiler, with mingw32 as target. This status quo simply cannot persist. The patch I've attached to the above tracker ticket may be viewed as a partial work around for the problem; however, alone it would not be sufficient -- it would also require a complementary patch to the GCC header. That patch could be implemented upstream, or we could maintain it as a local patch, (which we would obviously prefer to avoid). However, such complementary patching, in two distinct locations and requiring interventions from two distinct maintainers does seem like an undesirable kludge, and if the GCC team can devise a more robust solution, which can provide for searching <MINGW_ROOT>/include, (where <MINGW_ROOT> is deduced at GCC run time, by calling GetModuleFileName() or equivalent, from within the GCC executable itself), with a more conventional search order, then so much the better; we can easily adapt the mingwrt header to co-operate with this, *provided* the GCC solution accommodates the requirement to read (include_next) the complementary header, when it is provided at a later position in the search path than the GCC header. Maybe the ultimate solution would be for GCC to provide an alternative build time variable, representing a path to be searched *after* that mapped by local_includedir, but *before* that of the GCC headers, which could be used when building for a mingw32 target, (or any other with a similar requirement to pre-empt the GCC headers in the system search order), such that the particular co-operative header search order used by mingwrt (at present) can be accommodated, without subverting the usual intent of local_includedir. Perhaps one of you, who has been following the thread on the GCC list, could summarise, copy or link this comment to that thread? (I would do so myself, but since I don't follow the GCC list, to post at this juncture would necessarily break the existing thread). -- Regards, Keith. |
From: Danny S. <dan...@cl...> - 2010-07-24 02:40:13
|
IMHO this will affect you. Therefore I tried to find a different solution on gcc for not touching this, but as we all have to learn here is it a conceptional flaw to install headers in (/usr/local/include = STANDARD_INCLUDE_DIR for gcc). This STANDARD_INCLUDE_DIR is renamed by win32 targets to "/mingw/include". It is a matter of the search order of gcc's preprocessor. So to correct you, you are using this standard_include (I assume without known it is in fact standard_include) for a very long time. I'm testing the obvious xm-mingw32.h patch now. It will mean that mingw.orgs float.h will have to be modified so that it can be <include_next>'ed by gcc's float.h. Fixinclude should be able to do the job. Danny |
From: Keith M. <kei...@us...> - 2010-07-24 08:08:45
|
On Saturday 24 July 2010 03:39:28 Danny Smith wrote: > I'm testing the obvious xm-mingw32.h patch now. It will mean that > mingw.orgs float.h will have to be modified so that it can be > <include_next>'ed by gcc's float.h. Fixinclude should be able to do > the job. For mingw.org's float.h, does the patch I've already proposed, on ticket #3011968, fit the bill? While still retaining suitable backward compatibility for existing builds? If "yes", then we could have that committed right away. -- Regards, Keith. |
From: Danny S. <dan...@cl...> - 2010-07-25 07:03:56
|
----- Original Message ----- From: "Keith Marshall" <kei...@us...> To: <min...@li...> Sent: Saturday, July 24, 2010 8:08 PM Subject: Re: [MinGW-dvlpr] Fwd: Re: [patch win32]: fix for PR target/41943 On Saturday 24 July 2010 03:39:28 Danny Smith wrote: > I'm testing the obvious xm-mingw32.h patch now. It will mean that > mingw.orgs float.h will have to be modified so that it can be > <include_next>'ed by gcc's float.h. Fixinclude should be able to do > the job. For mingw.org's float.h, does the patch I've already proposed, on ticket #3011968, fit the bill? While still retaining suitable backward compatibility for existing builds? If "yes", then we could have that committed right away. Yes. The gcc 4.6 (while (testing_with_native) {...walk away and play in the garden and come back to check then walk away again ...} ;) fixinclude float.h will just do this: -#include_next<float.h> if it sees an old mingwrt float.h Danny -- Regards, Keith. ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ MinGW-dvlpr mailing list Min...@li... https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3026 - Release Date: 07/25/10 06:36:00 |
From: Keith M. <kei...@us...> - 2010-07-29 07:18:41
|
On Sunday 25 July 2010 08:03:42 Danny Smith wrote: > > For mingw.org's float.h, does the patch I've already proposed, on > > ticket #3011968, fit the bill? While still retaining suitable > > backward compatibility for existing builds? If "yes", then we > > could have that committed right away. > > Yes. I've applied it, in CVS. Please check, and confirm that it behaves as expected, with your proposed GCC adjustment. -- Regards, Keith. |