From: Dave C. <dav...@gm...> - 2010-03-21 20:42:50
|
Hello, I'm having a little trouble with the include paths used by mingw-w64 and was hoping for some insight... I have this chunk of code compiling correctly under the normal mingw system, but have some problems with include search paths with the w64 version... As far as I can tell, it's just pulling in the wrong version of float.h? but since it's system include paths, I'm not entirely sure how to get it to use the right paths.... After inspecting the header it looks like this is an MS specific feature, thus the reason it's not in the normal GCC header. I'm actually trying to compile a larger linear-algebra library, but it wants the MS specifics when it's being compiled on a MS box. Trivial source code, error messages and debug output are below... Thoughts? Thanks, -d #include <float.h> int main(int argc, char* argv) { long i = _EM_DENORMAL; return(0); } $ gcc -c test.c test.c: In function 'main': test.c:5:11: error: '_EM_DENORMAL' undeclared (first use in this function) test.c:5:11: error: (Each undeclared identifier is reported only once test.c:5:11: error: for each function it appears in.) $ gcc -M -c test.c test.o: test.c \ c:\msys\system64\bin-4.5.0\../lib/gcc/x86_64-w64-mingw32/4.5.0/include/float.h $ cat /c/msys/system64/lib/gcc/x86_64-w64-mingw32/4.5.0/include/float.h | grep EM_DENORMAL <nothing is output> There is a different header that has what I'm looking for: $ cat /c/msys/system64/x86_64-w64-mingw32/include/float.h | grep EM_DENORMAL #define _EM_DENORMAL 0x00080000 |
From: Ozkan S. <se...@gm...> - 2010-03-21 21:20:46
|
On Sun, Mar 21, 2010 at 10:42 PM, Dave Camarillo <dav...@gm...> wrote: > Hello, I'm having a little trouble with the include paths used by mingw-w64 > and was hoping for some insight... I have this chunk of code compiling > correctly under the normal mingw system, but have some problems with include > search paths with the w64 version... As far as I can tell, it's just pulling > in the wrong version of float.h? but since it's system include paths, I'm > not entirely sure how to get it to use the right paths.... After inspecting > the header it looks like this is an MS specific feature, thus the reason > it's not in the normal GCC header. I'm actually trying to compile a larger > linear-algebra library, but it wants the MS specifics when it's being > compiled on a MS box. Trivial source code, error messages and debug output > are below... > > Thoughts? > > > Thanks, > -d > > #include <float.h> > int main(int argc, char* argv) { > long i = _EM_DENORMAL; > return(0); > } > > > $ gcc -c test.c > test.c: In function 'main': > test.c:5:11: error: '_EM_DENORMAL' undeclared (first use in this function) > test.c:5:11: error: (Each undeclared identifier is reported only once > test.c:5:11: error: for each function it appears in.) > > > $ gcc -M -c test.c > test.o: test.c \ > c:\msys\system64\bin-4.5.0\../lib/gcc/x86_64-w64-mingw32/4.5.0/include/float.h Just delete this particular one from your installation ... > > > $ cat /c/msys/system64/lib/gcc/x86_64-w64-mingw32/4.5.0/include/float.h | > grep EM_DENORMAL > <nothing is output> > > > There is a different header that has what I'm looking for: > > $ cat /c/msys/system64/x86_64-w64-mingw32/include/float.h | grep EM_DENORMAL > #define _EM_DENORMAL 0x00080000 ... and this will be included by your source, instead. For some reason yet unknown to me, the gcc-provided headers have priority over the system provided headers and float.h is especially problematic: Not installing or deleting it is the solution, at least for now. -- Ozkan |
From: Dave C. <dav...@gm...> - 2010-03-22 15:52:49
|
Thanks Ozkan, that did the trick... the linear algebra libs now compile and work as expected... thanks, -dave On Sun, Mar 21, 2010 at 2:20 PM, Ozkan Sezer <se...@gm...> wrote: > On Sun, Mar 21, 2010 at 10:42 PM, Dave Camarillo > <dav...@gm...> wrote: > > Hello, I'm having a little trouble with the include paths used by > mingw-w64 > > and was hoping for some insight... I have this chunk of code compiling > > correctly under the normal mingw system, but have some problems with > include > > search paths with the w64 version... As far as I can tell, it's just > pulling > > in the wrong version of float.h? but since it's system include paths, I'm > > not entirely sure how to get it to use the right paths.... After > inspecting > > the header it looks like this is an MS specific feature, thus the reason > > it's not in the normal GCC header. I'm actually trying to compile a > larger > > linear-algebra library, but it wants the MS specifics when it's being > > compiled on a MS box. Trivial source code, error messages and debug > output > > are below... > > > > Thoughts? > > > > > > Thanks, > > -d > > > > #include <float.h> > > int main(int argc, char* argv) { > > long i = _EM_DENORMAL; > > return(0); > > } > > > > > > $ gcc -c test.c > > test.c: In function 'main': > > test.c:5:11: error: '_EM_DENORMAL' undeclared (first use in this > function) > > test.c:5:11: error: (Each undeclared identifier is reported only once > > test.c:5:11: error: for each function it appears in.) > > > > > > $ gcc -M -c test.c > > test.o: test.c \ > > > c:\msys\system64\bin-4.5.0\../lib/gcc/x86_64-w64-mingw32/4.5.0/include/float.h > > Just delete this particular one from your installation ... > > > > > > > $ cat /c/msys/system64/lib/gcc/x86_64-w64-mingw32/4.5.0/include/float.h | > > grep EM_DENORMAL > > <nothing is output> > > > > > > There is a different header that has what I'm looking for: > > > > $ cat /c/msys/system64/x86_64-w64-mingw32/include/float.h | grep > EM_DENORMAL > > #define _EM_DENORMAL 0x00080000 > > ... and this will be included by your source, instead. > > For some reason yet unknown to me, the gcc-provided headers > have priority over the system provided headers and float.h is > especially problematic: Not installing or deleting it is the solution, > at least for now. > > -- > Ozkan > |
From: NightStrike <nig...@gm...> - 2010-03-21 23:22:55
|
On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer <se...@gm...> wrote: > For some reason yet unknown to me, the gcc-provided headers > have priority over the system provided headers and float.h is > especially problematic: Not installing or deleting it is the solution, > at least for now. If gcc headers didn't take priority, then fixincludes wouldn't work. The real question is why gcc forces changes to system headers instead of working with system headers. |
From: Doug S. <dou...@gm...> - 2010-03-21 23:41:15
|
On Sun, 21 Mar 2010 19:22:48 NightStrike wrote: > On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer <se...@gm...> wrote: > > For some reason yet unknown to me, the gcc-provided headers > > have priority over the system provided headers and float.h is > > especially problematic: Not installing or deleting it is the solution, > > at least for now. > > If gcc headers didn't take priority, then fixincludes wouldn't work. > > The real question is why gcc forces changes to system headers instead > of working with system headers. > Does gcc even necessarily have the system headers available to it on a clean system during a build? I don't think so...which means that gcc may not know about the system headers when it runs through the stage of installation... In other words, for it to even work with the system headers, the system headers have to be installed correctly before you do the first make install-gcc during a bootstrap... (and I know the one howto build doc says install the headers first, but unfortunately building the toolchain does not fail if you do NOT do this...) |
From: NightStrike <nig...@gm...> - 2010-03-22 00:51:12
|
On Sun, Mar 21, 2010 at 7:41 PM, Doug Semler <dou...@gm...> wrote: > On Sun, 21 Mar 2010 19:22:48 NightStrike wrote: >> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer <se...@gm...> wrote: >> > For some reason yet unknown to me, the gcc-provided headers >> > have priority over the system provided headers and float.h is >> > especially problematic: Not installing or deleting it is the solution, >> > at least for now. >> >> If gcc headers didn't take priority, then fixincludes wouldn't work. >> >> The real question is why gcc forces changes to system headers instead >> of working with system headers. >> > > Does gcc even necessarily have the system headers available to it on a clean > system during a build? I don't think so...which means that gcc may not know > about the system headers when it runs through the stage of installation... > > In other words, for it to even work with the system headers, the system > headers have to be installed correctly before you do the first make install-gcc > during a bootstrap... > > (and I know the one howto build doc says install the headers first, but > unfortunately building the toolchain does not fail if you do NOT do this...) > Building the toolchain does in fact fail. Just, not at the all-gcc stage (the bootstrapping stage). Do a make all-gcc. When it finishes, do "make all". It'll die immediately asking for a valid sysroot. |
From: Ozkan S. <se...@gm...> - 2010-03-22 08:07:13
|
On Mon, Mar 22, 2010 at 2:51 AM, NightStrike <nig...@gm...> wrote: > On Sun, Mar 21, 2010 at 7:41 PM, Doug Semler <dou...@gm...> wrote: >> On Sun, 21 Mar 2010 19:22:48 NightStrike wrote: >>> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer <se...@gm...> wrote: >>> > For some reason yet unknown to me, the gcc-provided headers >>> > have priority over the system provided headers and float.h is >>> > especially problematic: Not installing or deleting it is the solution, >>> > at least for now. >>> >>> If gcc headers didn't take priority, then fixincludes wouldn't work. >>> >>> The real question is why gcc forces changes to system headers instead >>> of working with system headers. >>> >> >> Does gcc even necessarily have the system headers available to it on a clean >> system during a build? I don't think so...which means that gcc may not know >> about the system headers when it runs through the stage of installation... >> >> In other words, for it to even work with the system headers, the system >> headers have to be installed correctly before you do the first make install-gcc >> during a bootstrap... >> >> (and I know the one howto build doc says install the headers first, but >> unfortunately building the toolchain does not fail if you do NOT do this...) >> > > Building the toolchain does in fact fail. Just, not at the all-gcc > stage (the bootstrapping stage). Do a make all-gcc. When it > finishes, do "make all". It'll die immediately asking for a valid > sysroot. > Building with the --with-sysroot option makes the toolchain nicely relocatable, but we have this issue of gcc-provided headers having priority over the system provided headers. (and also the problem with the native toolchains that the <rootdir>/include directory not being used for the header search, too.) AFAIK, mingw.org doesn't build with sysroot option, and they don't have the problem specified in this thread, however that method of build seems to result in some relocation issues as in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42886 The current situation of gcc on this thing is a big 'Ouch'.. |
From: Doug S. <dou...@gm...> - 2010-03-22 15:24:16
|
On Sun, Mar 21, 2010 at 8:51 PM, NightStrike <nig...@gm...> wrote: > On Sun, Mar 21, 2010 at 7:41 PM, Doug Semler <dou...@gm...> wrote: >> On Sun, 21 Mar 2010 19:22:48 NightStrike wrote: >>> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer <se...@gm...> wrote: >>> > For some reason yet unknown to me, the gcc-provided headers >>> > have priority over the system provided headers and float.h is >>> > especially problematic: Not installing or deleting it is the solution, >>> > at least for now. >>> >>> If gcc headers didn't take priority, then fixincludes wouldn't work. >>> >>> The real question is why gcc forces changes to system headers instead >>> of working with system headers. >>> >> >> Does gcc even necessarily have the system headers available to it on a clean >> system during a build? I don't think so...which means that gcc may not know >> about the system headers when it runs through the stage of installation... >> >> In other words, for it to even work with the system headers, the system >> headers have to be installed correctly before you do the first make install-gcc >> during a bootstrap... >> >> (and I know the one howto build doc says install the headers first, but >> unfortunately building the toolchain does not fail if you do NOT do this...) >> > > Building the toolchain does in fact fail. Just, not at the all-gcc > stage (the bootstrapping stage). Do a make all-gcc. When it > finishes, do "make all". It'll die immediately asking for a valid > sysroot. > No, what I meant is that you don't have to go in the order specified in the how-to-build if you don't build a sysroot configuration (you do if you build a sysroot configuration). In other words, the system includes do not (strictly) have to be available until the target library phase when building non sysrooted...which means that even *IF* fixincludes were to be run on the mingw target (which it doesn't look like it is, by the way) and told to pick up the system headers during the build-gcc phase, it may not necessarily do so. It's how I (used to) build the toolchain in tree with no mulitilib and a couple other tweaks (yes, it is possible). I don't personally like the sysroot option myself, especially because it insists that it wants to be in <sysroot>/mingw/include (why?!?!)...But that still doesn't fix this little "issue" The whole sysroot/build-sysroot/fixincludes logic is, in the words of the Unfrozen Caveman Lawyer, "Frightening and Confusing" :) Oh, by the way, stdarg.h suffers the same problem in that it uses gcc's version and doesn't pick up mingw's version... |
From: Kai T. <kti...@go...> - 2010-03-22 15:29:08
|
2010/3/22 Doug Semler <dou...@gm...>: > On Sun, Mar 21, 2010 at 8:51 PM, NightStrike <nig...@gm...> wrote: >> On Sun, Mar 21, 2010 at 7:41 PM, Doug Semler <dou...@gm...> wrote: >>> On Sun, 21 Mar 2010 19:22:48 NightStrike wrote: >>>> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer <se...@gm...> wrote: >>>> > For some reason yet unknown to me, the gcc-provided headers >>>> > have priority over the system provided headers and float.h is >>>> > especially problematic: Not installing or deleting it is the solution, >>>> > at least for now. >>>> >>>> If gcc headers didn't take priority, then fixincludes wouldn't work. >>>> >>>> The real question is why gcc forces changes to system headers instead >>>> of working with system headers. >>>> >>> >>> Does gcc even necessarily have the system headers available to it on a clean >>> system during a build? I don't think so...which means that gcc may not know >>> about the system headers when it runs through the stage of installation... >>> >>> In other words, for it to even work with the system headers, the system >>> headers have to be installed correctly before you do the first make install-gcc >>> during a bootstrap... >>> >>> (and I know the one howto build doc says install the headers first, but >>> unfortunately building the toolchain does not fail if you do NOT do this...) >>> >> >> Building the toolchain does in fact fail. Just, not at the all-gcc >> stage (the bootstrapping stage). Do a make all-gcc. When it >> finishes, do "make all". It'll die immediately asking for a valid >> sysroot. >> > > No, what I meant is that you don't have to go in the order specified > in the how-to-build if you don't build a sysroot configuration (you do > if you build a sysroot configuration). In other words, the system > includes do not (strictly) have to be available until the target > library phase when building non sysrooted...which means that even *IF* > fixincludes were to be run on the mingw target (which it doesn't look > like it is, by the way) and told to pick up the system headers during > the build-gcc phase, it may not necessarily do so. It's how I (used > to) build the toolchain in tree with no mulitilib and a couple other > tweaks (yes, it is possible). I don't personally like the sysroot > option myself, especially because it insists that it wants to be in > <sysroot>/mingw/include (why?!?!)...But that still doesn't fix this > little "issue" > > The whole sysroot/build-sysroot/fixincludes logic is, in the words of > the Unfrozen Caveman Lawyer, "Frightening and Confusing" :) > > Oh, by the way, stdarg.h suffers the same problem in that it uses > gcc's version and doesn't pick up mingw's version... Yeah, float.h, stdarg.h, and stddef.h having the same issue. And btw mm_malloc.h is badly incompatible to VC's definition. Additionally there are some (horrible) issues about *intrin.h of gcc and it is therefore strictly recommented to use our intrin.h to fix those issues. Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | (")_(") him gain world domination |
From: Mook <moo...@gm...> - 2010-03-23 04:57:45
|
On Sun, Mar 21, 2010 at 4:22 PM, NightStrike <nig...@gm...> wrote: > On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer <se...@gm...> wrote: >> For some reason yet unknown to me, the gcc-provided headers >> have priority over the system provided headers and float.h is >> especially problematic: Not installing or deleting it is the solution, >> at least for now. > > If gcc headers didn't take priority, then fixincludes wouldn't work. > > The real question is why gcc forces changes to system headers instead > of working with system headers. FWIW, I believe this is set in gcc/cppdefaults.c [1] but I haven't been able to come up with a patch that I don't hate yet. If something can be done, it would probably involve defining INCLUDE_DEFAULTS in config/i386/mingw-w64.h somehow, but the temporary workaround I have (#define PREFIX_INCLUDE_DIR TOOL_INCLUDE_DIR) breaks non-sysroot prefix builds, so that's not useful. Mostly sending this just so the mailing list archive can help remember this for me ;) [1] http://gcc.gnu.org/viewcvs/trunk/gcc/cppdefault.c?view=markup#l44 -- Mook |
From: NightStrike <nig...@gm...> - 2010-03-23 12:08:34
|
On Tue, Mar 23, 2010 at 12:57 AM, Mook <moo...@gm...> wrote: > On Sun, Mar 21, 2010 at 4:22 PM, NightStrike <nig...@gm...> wrote: >> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer <se...@gm...> wrote: >>> For some reason yet unknown to me, the gcc-provided headers >>> have priority over the system provided headers and float.h is >>> especially problematic: Not installing or deleting it is the solution, >>> at least for now. >> >> If gcc headers didn't take priority, then fixincludes wouldn't work. >> >> The real question is why gcc forces changes to system headers instead >> of working with system headers. > > FWIW, I believe this is set in gcc/cppdefaults.c [1] but I haven't > been able to come up with a patch that I don't hate yet. If something > can be done, it would probably involve defining INCLUDE_DEFAULTS in > config/i386/mingw-w64.h somehow, but the temporary workaround I have > (#define PREFIX_INCLUDE_DIR TOOL_INCLUDE_DIR) breaks non-sysroot > prefix builds, so that's not useful. > > Mostly sending this just so the mailing list archive can help remember > this for me ;) > > [1] http://gcc.gnu.org/viewcvs/trunk/gcc/cppdefault.c?view=markup#l44 > > -- > Mook > The real fix is to sync what gcc wants with what we have, with appropriate changes on both sides. |
From: Kai T. <kti...@go...> - 2010-03-23 12:45:58
|
2010/3/23 NightStrike <nig...@gm...>: > On Tue, Mar 23, 2010 at 12:57 AM, Mook > <moo...@gm...> wrote: >> On Sun, Mar 21, 2010 at 4:22 PM, NightStrike <nig...@gm...> wrote: >>> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer <se...@gm...> wrote: >>>> For some reason yet unknown to me, the gcc-provided headers >>>> have priority over the system provided headers and float.h is >>>> especially problematic: Not installing or deleting it is the solution, >>>> at least for now. >>> >>> If gcc headers didn't take priority, then fixincludes wouldn't work. >>> >>> The real question is why gcc forces changes to system headers instead >>> of working with system headers. >> >> FWIW, I believe this is set in gcc/cppdefaults.c [1] but I haven't >> been able to come up with a patch that I don't hate yet. If something >> can be done, it would probably involve defining INCLUDE_DEFAULTS in >> config/i386/mingw-w64.h somehow, but the temporary workaround I have >> (#define PREFIX_INCLUDE_DIR TOOL_INCLUDE_DIR) breaks non-sysroot >> prefix builds, so that's not useful. >> >> Mostly sending this just so the mailing list archive can help remember >> this for me ;) >> >> [1] http://gcc.gnu.org/viewcvs/trunk/gcc/cppdefault.c?view=markup#l44 >> >> -- >> Mook >> > > The real fix is to sync what gcc wants with what we have, with > appropriate changes on both sides. > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Mingw-w64-public mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > We (Ozkan and I) already tried to push necessary changes to gcc. But well, people love their POSIX stuff and dislike even an include next here. Problem is also that mingw.org don't provide those headers in their CRT at all, so a change here as to be runtime-specific, which messes things a bit (include of _mingw.h and checking for runtime). Best solution is (as work-around) to remove those headers from gcc's /lib/gcc/<target>/<version>/include directory Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | (")_(") him gain world domination |
From: NightStrike <nig...@gm...> - 2010-03-23 12:18:52
|
On Tue, Mar 23, 2010 at 8:15 AM, Kai Tietz <kti...@go...> wrote: > 2010/3/23 NightStrike <nig...@gm...>: >> On Tue, Mar 23, 2010 at 12:57 AM, Mook >> <moo...@gm...> wrote: >>> On Sun, Mar 21, 2010 at 4:22 PM, NightStrike <nig...@gm...> wrote: >>>> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer <se...@gm...> wrote: >>>>> For some reason yet unknown to me, the gcc-provided headers >>>>> have priority over the system provided headers and float.h is >>>>> especially problematic: Not installing or deleting it is the solution, >>>>> at least for now. >>>> >>>> If gcc headers didn't take priority, then fixincludes wouldn't work. >>>> >>>> The real question is why gcc forces changes to system headers instead >>>> of working with system headers. >>> >>> FWIW, I believe this is set in gcc/cppdefaults.c [1] but I haven't >>> been able to come up with a patch that I don't hate yet. If something >>> can be done, it would probably involve defining INCLUDE_DEFAULTS in >>> config/i386/mingw-w64.h somehow, but the temporary workaround I have >>> (#define PREFIX_INCLUDE_DIR TOOL_INCLUDE_DIR) breaks non-sysroot >>> prefix builds, so that's not useful. >>> >>> Mostly sending this just so the mailing list archive can help remember >>> this for me ;) >>> >>> [1] http://gcc.gnu.org/viewcvs/trunk/gcc/cppdefault.c?view=markup#l44 >>> >>> -- >>> Mook >>> >> >> The real fix is to sync what gcc wants with what we have, with >> appropriate changes on both sides. >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Mingw-w64-public mailing list >> Min...@li... >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >> > > We (Ozkan and I) already tried to push necessary changes to gcc. But > well, people love their POSIX stuff and dislike even an include next > here. Problem is also that mingw.org don't provide those headers in > their CRT at all, so a change here as to be runtime-specific, which > messes things a bit (include of _mingw.h and checking for runtime). > Best solution is (as work-around) to remove those headers from gcc's > /lib/gcc/<target>/<version>/include directory That's hardly "best". We need to try again, and get GCC to listen. I don't care about mingw.org... we can do something vendor-specific for that. But I do care about having GCC do a fixincludes on our headers, that we then revert. That's just plain stupid. Who's the GCC maintainer that we need to hit over the head? |
From: Ozkan S. <se...@gm...> - 2010-03-23 12:33:38
|
On Tue, Mar 23, 2010 at 2:17 PM, NightStrike <nig...@gm...> wrote: > On Tue, Mar 23, 2010 at 8:15 AM, Kai Tietz <kti...@go...> wrote: >> 2010/3/23 NightStrike <nig...@gm...>: >>> On Tue, Mar 23, 2010 at 12:57 AM, Mook >>> <moo...@gm...> wrote: >>>> On Sun, Mar 21, 2010 at 4:22 PM, NightStrike <nig...@gm...> wrote: >>>>> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer <se...@gm...> wrote: >>>>>> For some reason yet unknown to me, the gcc-provided headers >>>>>> have priority over the system provided headers and float.h is >>>>>> especially problematic: Not installing or deleting it is the solution, >>>>>> at least for now. >>>>> >>>>> If gcc headers didn't take priority, then fixincludes wouldn't work. >>>>> >>>>> The real question is why gcc forces changes to system headers instead >>>>> of working with system headers. >>>> >>>> FWIW, I believe this is set in gcc/cppdefaults.c [1] but I haven't >>>> been able to come up with a patch that I don't hate yet. If something >>>> can be done, it would probably involve defining INCLUDE_DEFAULTS in >>>> config/i386/mingw-w64.h somehow, but the temporary workaround I have >>>> (#define PREFIX_INCLUDE_DIR TOOL_INCLUDE_DIR) breaks non-sysroot >>>> prefix builds, so that's not useful. >>>> >>>> Mostly sending this just so the mailing list archive can help remember >>>> this for me ;) >>>> >>>> [1] http://gcc.gnu.org/viewcvs/trunk/gcc/cppdefault.c?view=markup#l44 >>>> >>>> -- >>>> Mook >>>> >>> >>> The real fix is to sync what gcc wants with what we have, with >>> appropriate changes on both sides. >>> >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> Mingw-w64-public mailing list >>> Min...@li... >>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >>> >> >> We (Ozkan and I) already tried to push necessary changes to gcc. But >> well, people love their POSIX stuff and dislike even an include next >> here. Problem is also that mingw.org don't provide those headers in >> their CRT at all, so a change here as to be runtime-specific, which >> messes things a bit (include of _mingw.h and checking for runtime). >> Best solution is (as work-around) to remove those headers from gcc's >> /lib/gcc/<target>/<version>/include directory > > That's hardly "best". We need to try again, and get GCC to listen. > > I don't care about mingw.org... we can do something vendor-specific > for that. But I do care about having GCC do a fixincludes on our My first suggestion *was* vendor specific which disabled those three headers' installation by gcc: http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01034.html The thread went some time and then get lost, feel free to revive it if you want. The solution in that initial post above is what I already use in my personal builds and it works. > headers, that we then revert. That's just plain stupid. > > Who's the GCC maintainer that we need to hit over the head? -- Ozkan |
From: Kai T. <kti...@go...> - 2010-03-23 12:43:23
|
2010/3/23 Ozkan Sezer <se...@gm...>: > On Tue, Mar 23, 2010 at 2:17 PM, NightStrike <nig...@gm...> wrote: >> On Tue, Mar 23, 2010 at 8:15 AM, Kai Tietz <kti...@go...> wrote: >>> 2010/3/23 NightStrike <nig...@gm...>: >>>> On Tue, Mar 23, 2010 at 12:57 AM, Mook >>>> <moo...@gm...> wrote: >>>>> On Sun, Mar 21, 2010 at 4:22 PM, NightStrike <nig...@gm...> wrote: >>>>>> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer <se...@gm...> wrote: >>>>>>> For some reason yet unknown to me, the gcc-provided headers >>>>>>> have priority over the system provided headers and float.h is >>>>>>> especially problematic: Not installing or deleting it is the solution, >>>>>>> at least for now. >>>>>> >>>>>> If gcc headers didn't take priority, then fixincludes wouldn't work. >>>>>> >>>>>> The real question is why gcc forces changes to system headers instead >>>>>> of working with system headers. >>>>> >>>>> FWIW, I believe this is set in gcc/cppdefaults.c [1] but I haven't >>>>> been able to come up with a patch that I don't hate yet. If something >>>>> can be done, it would probably involve defining INCLUDE_DEFAULTS in >>>>> config/i386/mingw-w64.h somehow, but the temporary workaround I have >>>>> (#define PREFIX_INCLUDE_DIR TOOL_INCLUDE_DIR) breaks non-sysroot >>>>> prefix builds, so that's not useful. >>>>> >>>>> Mostly sending this just so the mailing list archive can help remember >>>>> this for me ;) >>>>> >>>>> [1] http://gcc.gnu.org/viewcvs/trunk/gcc/cppdefault.c?view=markup#l44 >>>>> >>>>> -- >>>>> Mook >>>>> >>>> >>>> The real fix is to sync what gcc wants with what we have, with >>>> appropriate changes on both sides. >>>> >>>> ------------------------------------------------------------------------------ >>>> Download Intel® Parallel Studio Eval >>>> Try the new software tools for yourself. Speed compiling, find bugs >>>> proactively, and fine-tune applications for parallel performance. >>>> See why Intel Parallel Studio got high marks during beta. >>>> http://p.sf.net/sfu/intel-sw-dev >>>> _______________________________________________ >>>> Mingw-w64-public mailing list >>>> Min...@li... >>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >>>> >>> >>> We (Ozkan and I) already tried to push necessary changes to gcc. But >>> well, people love their POSIX stuff and dislike even an include next >>> here. Problem is also that mingw.org don't provide those headers in >>> their CRT at all, so a change here as to be runtime-specific, which >>> messes things a bit (include of _mingw.h and checking for runtime). >>> Best solution is (as work-around) to remove those headers from gcc's >>> /lib/gcc/<target>/<version>/include directory >> >> That's hardly "best". We need to try again, and get GCC to listen. >> >> I don't care about mingw.org... we can do something vendor-specific >> for that. But I do care about having GCC do a fixincludes on our > > My first suggestion *was* vendor specific which disabled > those three headers' installation by gcc: > http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01034.html > The thread went some time and then get lost, feel free > to revive it if you want. The solution in that initial post above > is what I already use in my personal builds and it works. > >> headers, that we then revert. That's just plain stupid. >> >> Who's the GCC maintainer that we need to hit over the head? > > -- > Ozkan > It is the use of USER, right? This is fine at the moment, but I dislike it as we then have to maintain changes of gcc within our headers. What's about using fixinclude here? See gcc's bug-tracker 40722 item, where HJ uses this to fix _rotl/_rolr issue. Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | (")_(") him gain world domination |
From: Ozkan S. <se...@gm...> - 2010-03-23 12:48:32
|
On Tue, Mar 23, 2010 at 2:43 PM, Kai Tietz <kti...@go...> wrote: > 2010/3/23 Ozkan Sezer <se...@gm...>: >> On Tue, Mar 23, 2010 at 2:17 PM, NightStrike <nig...@gm...> wrote: >>> On Tue, Mar 23, 2010 at 8:15 AM, Kai Tietz <kti...@go...> wrote: >>>> 2010/3/23 NightStrike <nig...@gm...>: >>>>> On Tue, Mar 23, 2010 at 12:57 AM, Mook >>>>> <moo...@gm...> wrote: >>>>>> On Sun, Mar 21, 2010 at 4:22 PM, NightStrike <nig...@gm...> wrote: >>>>>>> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer <se...@gm...> wrote: >>>>>>>> For some reason yet unknown to me, the gcc-provided headers >>>>>>>> have priority over the system provided headers and float.h is >>>>>>>> especially problematic: Not installing or deleting it is the solution, >>>>>>>> at least for now. >>>>>>> >>>>>>> If gcc headers didn't take priority, then fixincludes wouldn't work. >>>>>>> >>>>>>> The real question is why gcc forces changes to system headers instead >>>>>>> of working with system headers. >>>>>> >>>>>> FWIW, I believe this is set in gcc/cppdefaults.c [1] but I haven't >>>>>> been able to come up with a patch that I don't hate yet. If something >>>>>> can be done, it would probably involve defining INCLUDE_DEFAULTS in >>>>>> config/i386/mingw-w64.h somehow, but the temporary workaround I have >>>>>> (#define PREFIX_INCLUDE_DIR TOOL_INCLUDE_DIR) breaks non-sysroot >>>>>> prefix builds, so that's not useful. >>>>>> >>>>>> Mostly sending this just so the mailing list archive can help remember >>>>>> this for me ;) >>>>>> >>>>>> [1] http://gcc.gnu.org/viewcvs/trunk/gcc/cppdefault.c?view=markup#l44 >>>>>> >>>>>> -- >>>>>> Mook >>>>>> >>>>> >>>>> The real fix is to sync what gcc wants with what we have, with >>>>> appropriate changes on both sides. >>>>> >>>> >>>> We (Ozkan and I) already tried to push necessary changes to gcc. But >>>> well, people love their POSIX stuff and dislike even an include next >>>> here. Problem is also that mingw.org don't provide those headers in >>>> their CRT at all, so a change here as to be runtime-specific, which >>>> messes things a bit (include of _mingw.h and checking for runtime). >>>> Best solution is (as work-around) to remove those headers from gcc's >>>> /lib/gcc/<target>/<version>/include directory >>> >>> That's hardly "best". We need to try again, and get GCC to listen. >>> >>> I don't care about mingw.org... we can do something vendor-specific >>> for that. But I do care about having GCC do a fixincludes on our >> >> My first suggestion *was* vendor specific which disabled >> those three headers' installation by gcc: >> http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01034.html >> The thread went some time and then get lost, feel free >> to revive it if you want. The solution in that initial post above >> is what I already use in my personal builds and it works. >> >>> headers, that we then revert. That's just plain stupid. >>> >>> Who's the GCC maintainer that we need to hit over the head? >> >> -- >> Ozkan >> > > It is the use of USER, right? This is fine at the moment, but I Yes, the USER_H mechanism. > dislike it as we then have to maintain changes of gcc within our > headers. What's about using fixinclude here? See gcc's bug-tracker > 40722 item, where HJ uses this to fix _rotl/_rolr issue. I can't understand, how can a fixinclude fix this thing?? > > Kai -- Ozkan |
From: Doug S. <dou...@gm...> - 2010-03-23 13:39:53
|
On Tue, Mar 23, 2010 at 8:48 AM, Ozkan Sezer <se...@gm...> wrote: > On Tue, Mar 23, 2010 at 2:43 PM, Kai Tietz <kti...@go...> wrote: >> >> It is the use of USER, right? This is fine at the moment, but I > > Yes, the USER_H mechanism. > >> dislike it as we then have to maintain changes of gcc within our >> headers. What's about using fixinclude here? See gcc's bug-tracker >> 40722 item, where HJ uses this to fix _rotl/_rolr issue. > > I can't understand, how can a fixinclude fix this thing?? > I don't either. My impression was that fixincludes "fixed" system headers that were not compatible with gcc's expectations... I would have thought a better solution would be to do something like what is done for limits.h or stdint.h, which is to wrap the system header(s) from gcc's header set with include_nexts |
From: Kai T. <kti...@go...> - 2010-03-23 12:52:44
|
2010/3/23 Ozkan Sezer <se...@gm...>: > On Tue, Mar 23, 2010 at 2:43 PM, Kai Tietz <kti...@go...> wrote: >> 2010/3/23 Ozkan Sezer <se...@gm...>: >>> On Tue, Mar 23, 2010 at 2:17 PM, NightStrike <nig...@gm...> wrote: >>>> On Tue, Mar 23, 2010 at 8:15 AM, Kai Tietz <kti...@go...> wrote: >>>>> 2010/3/23 NightStrike <nig...@gm...>: >>>>>> On Tue, Mar 23, 2010 at 12:57 AM, Mook >>>>>> <moo...@gm...> wrote: >>>>>>> On Sun, Mar 21, 2010 at 4:22 PM, NightStrike <nig...@gm...> wrote: >>>>>>>> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer <se...@gm...> wrote: >>>>>>>>> For some reason yet unknown to me, the gcc-provided headers >>>>>>>>> have priority over the system provided headers and float.h is >>>>>>>>> especially problematic: Not installing or deleting it is the solution, >>>>>>>>> at least for now. >>>>>>>> >>>>>>>> If gcc headers didn't take priority, then fixincludes wouldn't work. >>>>>>>> >>>>>>>> The real question is why gcc forces changes to system headers instead >>>>>>>> of working with system headers. >>>>>>> >>>>>>> FWIW, I believe this is set in gcc/cppdefaults.c [1] but I haven't >>>>>>> been able to come up with a patch that I don't hate yet. If something >>>>>>> can be done, it would probably involve defining INCLUDE_DEFAULTS in >>>>>>> config/i386/mingw-w64.h somehow, but the temporary workaround I have >>>>>>> (#define PREFIX_INCLUDE_DIR TOOL_INCLUDE_DIR) breaks non-sysroot >>>>>>> prefix builds, so that's not useful. >>>>>>> >>>>>>> Mostly sending this just so the mailing list archive can help remember >>>>>>> this for me ;) >>>>>>> >>>>>>> [1] http://gcc.gnu.org/viewcvs/trunk/gcc/cppdefault.c?view=markup#l44 >>>>>>> >>>>>>> -- >>>>>>> Mook >>>>>>> >>>>>> >>>>>> The real fix is to sync what gcc wants with what we have, with >>>>>> appropriate changes on both sides. >>>>>> >>>>> >>>>> We (Ozkan and I) already tried to push necessary changes to gcc. But >>>>> well, people love their POSIX stuff and dislike even an include next >>>>> here. Problem is also that mingw.org don't provide those headers in >>>>> their CRT at all, so a change here as to be runtime-specific, which >>>>> messes things a bit (include of _mingw.h and checking for runtime). >>>>> Best solution is (as work-around) to remove those headers from gcc's >>>>> /lib/gcc/<target>/<version>/include directory >>>> >>>> That's hardly "best". We need to try again, and get GCC to listen. >>>> >>>> I don't care about mingw.org... we can do something vendor-specific >>>> for that. But I do care about having GCC do a fixincludes on our >>> >>> My first suggestion *was* vendor specific which disabled >>> those three headers' installation by gcc: >>> http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01034.html >>> The thread went some time and then get lost, feel free >>> to revive it if you want. The solution in that initial post above >>> is what I already use in my personal builds and it works. >>> >>>> headers, that we then revert. That's just plain stupid. >>>> >>>> Who's the GCC maintainer that we need to hit over the head? >>> >>> -- >>> Ozkan >>> >> >> It is the use of USER, right? This is fine at the moment, but I > > Yes, the USER_H mechanism. > >> dislike it as we then have to maintain changes of gcc within our >> headers. What's about using fixinclude here? See gcc's bug-tracker >> 40722 item, where HJ uses this to fix _rotl/_rolr issue. > > I can't understand, how can a fixinclude fix this thing?? It could add the include pattern to those headers. Did I got here something wrong? (a fix-include can be target-specific as shown in HJ's code). Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | (")_(") him gain world domination |
From: Ozkan S. <se...@gm...> - 2010-03-23 12:57:21
|
On Tue, Mar 23, 2010 at 2:52 PM, Kai Tietz <kti...@go...> wrote: > 2010/3/23 Ozkan Sezer <se...@gm...>: >> On Tue, Mar 23, 2010 at 2:43 PM, Kai Tietz <kti...@go...> wrote: >>> 2010/3/23 Ozkan Sezer <se...@gm...>: >>>> On Tue, Mar 23, 2010 at 2:17 PM, NightStrike <nig...@gm...> wrote: >>>>> On Tue, Mar 23, 2010 at 8:15 AM, Kai Tietz <kti...@go...> wrote: >>>>>> 2010/3/23 NightStrike <nig...@gm...>: >>>>>>> On Tue, Mar 23, 2010 at 12:57 AM, Mook >>>>>>> <moo...@gm...> wrote: >>>>>>>> On Sun, Mar 21, 2010 at 4:22 PM, NightStrike <nig...@gm...> wrote: >>>>>>>>> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer <se...@gm...> wrote: >>>>>>>>>> For some reason yet unknown to me, the gcc-provided headers >>>>>>>>>> have priority over the system provided headers and float.h is >>>>>>>>>> especially problematic: Not installing or deleting it is the solution, >>>>>>>>>> at least for now. >>>>>>>>> >>>>>>>>> If gcc headers didn't take priority, then fixincludes wouldn't work. >>>>>>>>> >>>>>>>>> The real question is why gcc forces changes to system headers instead >>>>>>>>> of working with system headers. >>>>>>>> >>>>>>>> FWIW, I believe this is set in gcc/cppdefaults.c [1] but I haven't >>>>>>>> been able to come up with a patch that I don't hate yet. If something >>>>>>>> can be done, it would probably involve defining INCLUDE_DEFAULTS in >>>>>>>> config/i386/mingw-w64.h somehow, but the temporary workaround I have >>>>>>>> (#define PREFIX_INCLUDE_DIR TOOL_INCLUDE_DIR) breaks non-sysroot >>>>>>>> prefix builds, so that's not useful. >>>>>>>> >>>>>>>> Mostly sending this just so the mailing list archive can help remember >>>>>>>> this for me ;) >>>>>>>> >>>>>>>> [1] http://gcc.gnu.org/viewcvs/trunk/gcc/cppdefault.c?view=markup#l44 >>>>>>>> >>>>>>>> -- >>>>>>>> Mook >>>>>>>> >>>>>>> >>>>>>> The real fix is to sync what gcc wants with what we have, with >>>>>>> appropriate changes on both sides. >>>>>>> >>>>>> >>>>>> We (Ozkan and I) already tried to push necessary changes to gcc. But >>>>>> well, people love their POSIX stuff and dislike even an include next >>>>>> here. Problem is also that mingw.org don't provide those headers in >>>>>> their CRT at all, so a change here as to be runtime-specific, which >>>>>> messes things a bit (include of _mingw.h and checking for runtime). >>>>>> Best solution is (as work-around) to remove those headers from gcc's >>>>>> /lib/gcc/<target>/<version>/include directory >>>>> >>>>> That's hardly "best". We need to try again, and get GCC to listen. >>>>> >>>>> I don't care about mingw.org... we can do something vendor-specific >>>>> for that. But I do care about having GCC do a fixincludes on our >>>> >>>> My first suggestion *was* vendor specific which disabled >>>> those three headers' installation by gcc: >>>> http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01034.html >>>> The thread went some time and then get lost, feel free >>>> to revive it if you want. The solution in that initial post above >>>> is what I already use in my personal builds and it works. >>>> >>>>> headers, that we then revert. That's just plain stupid. >>>>> >>>>> Who's the GCC maintainer that we need to hit over the head? >>>> >>>> -- >>>> Ozkan >>>> >>> >>> It is the use of USER, right? This is fine at the moment, but I >> >> Yes, the USER_H mechanism. >> >>> dislike it as we then have to maintain changes of gcc within our >>> headers. What's about using fixinclude here? See gcc's bug-tracker >>> 40722 item, where HJ uses this to fix _rotl/_rolr issue. >> >> I can't understand, how can a fixinclude fix this thing?? > > It could add the include pattern to those headers. Did I got here > something wrong? > (a fix-include can be target-specific as shown in HJ's code). > Hmm, well, I'd like to see such a patch hopefully fixing all problems with float.h, stddef.h and stdarg.h... > Kai > -- Ozkan |
From: NightStrike <nig...@gm...> - 2010-03-23 13:00:20
|
On Tue, Mar 23, 2010 at 8:48 AM, Ozkan Sezer <se...@gm...> wrote: > I can't understand, how can a fixinclude fix this thing?? As I understand it, our headers are already being fixincluded. It's fixincludes that causes GCC to override us. That means that there's stuff in our headers that GCC doesn't like. |
From: Doug S. <dou...@gm...> - 2010-03-23 13:05:30
|
On Tue, Mar 23, 2010 at 9:00 AM, NightStrike <nig...@gm...> wrote: > On Tue, Mar 23, 2010 at 8:48 AM, Ozkan Sezer <se...@gm...> wrote: >> I can't understand, how can a fixinclude fix this thing?? > > As I understand it, our headers are already being fixincluded. It's > fixincludes that causes GCC to override us. That means that there's > stuff in our headers that GCC doesn't like. I thought right now fixincludes isn't being run on mingw targets (it does nothing)...if you look at the mkfixinc.sh script, the targets are skipped (which was part of HJ's patch that was mentioned) (Or am I behind the trunk too far?) |
From: Ozkan S. <se...@gm...> - 2010-03-23 13:02:28
|
On Tue, Mar 23, 2010 at 3:00 PM, NightStrike <nig...@gm...> wrote: > On Tue, Mar 23, 2010 at 8:48 AM, Ozkan Sezer <se...@gm...> wrote: >> I can't understand, how can a fixinclude fix this thing?? > > As I understand it, our headers are already being fixincluded. It's > fixincludes that causes GCC to override us. That means that there's > stuff in our headers that GCC doesn't like. > No, absolutely not. Can't you see what is already in your own fixinclude directory in your installation? The problem is with the headers installed by gcc by default. |
From: Doug S. <dou...@gm...> - 2010-03-23 13:10:15
|
On Tue, Mar 23, 2010 at 9:02 AM, Ozkan Sezer <se...@gm...> wrote: > On Tue, Mar 23, 2010 at 3:00 PM, NightStrike <nig...@gm...> wrote: >> On Tue, Mar 23, 2010 at 8:48 AM, Ozkan Sezer <se...@gm...> wrote: >>> I can't understand, how can a fixinclude fix this thing?? >> >> As I understand it, our headers are already being fixincluded. It's >> fixincludes that causes GCC to override us. That means that there's >> stuff in our headers that GCC doesn't like. >> > > No, absolutely not. Can't you see what is already > in your own fixinclude directory in your installation? > The problem is with the headers installed by gcc > by default. > I'll have to look, but it seems to me that that for it to work, the system headers must be available during the all-gcc step of a cross-compiler, wouldn't they, because fixincludes I believe is run right after the compiler is built during that step... |