Re: [Mingw-w64-public] Include paths, float.h
On Tue, Mar 23, 2010 at 8:48 AM, Ozkan Sezer wrote: > On Tue, Mar 23, 2010 at 2:43 PM, Kai Tietz 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 -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Include paths, float.h
On Tue, Mar 23, 2010 at 9:02 AM, Ozkan Sezer wrote: > On Tue, Mar 23, 2010 at 3:00 PM, NightStrike wrote: >> On Tue, Mar 23, 2010 at 8:48 AM, Ozkan Sezer 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... -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Include paths, float.h
On Tue, Mar 23, 2010 at 9:00 AM, NightStrike wrote: > On Tue, Mar 23, 2010 at 8:48 AM, Ozkan Sezer 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?) -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Include paths, float.h
On Tue, Mar 23, 2010 at 3:00 PM, NightStrike wrote: > On Tue, Mar 23, 2010 at 8:48 AM, Ozkan Sezer 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. -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Include paths, float.h
On Tue, Mar 23, 2010 at 8:48 AM, Ozkan Sezer 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. -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Include paths, float.h
On Tue, Mar 23, 2010 at 2:52 PM, Kai Tietz wrote: > 2010/3/23 Ozkan Sezer : >> On Tue, Mar 23, 2010 at 2:43 PM, Kai Tietz wrote: >>> 2010/3/23 Ozkan Sezer : On Tue, Mar 23, 2010 at 2:17 PM, NightStrike wrote: > On Tue, Mar 23, 2010 at 8:15 AM, Kai Tietz > wrote: >> 2010/3/23 NightStrike : >>> On Tue, Mar 23, 2010 at 12:57 AM, Mook >>> wrote: On Sun, Mar 21, 2010 at 4:22 PM, NightStrike wrote: > On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer > 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///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 -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Include paths, float.h
2010/3/23 Ozkan Sezer :
> On Tue, Mar 23, 2010 at 2:43 PM, Kai Tietz wrote:
>> 2010/3/23 Ozkan Sezer :
>>> On Tue, Mar 23, 2010 at 2:17 PM, NightStrike wrote:
On Tue, Mar 23, 2010 at 8:15 AM, Kai Tietz wrote:
> 2010/3/23 NightStrike :
>> On Tue, Mar 23, 2010 at 12:57 AM, Mook
>> wrote:
>>> On Sun, Mar 21, 2010 at 4:22 PM, NightStrike
>>> wrote:
On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer 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///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
--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Include paths, float.h
On Tue, Mar 23, 2010 at 2:43 PM, Kai Tietz wrote: > 2010/3/23 Ozkan Sezer : >> On Tue, Mar 23, 2010 at 2:17 PM, NightStrike wrote: >>> On Tue, Mar 23, 2010 at 8:15 AM, Kai Tietz wrote: 2010/3/23 NightStrike : > On Tue, Mar 23, 2010 at 12:57 AM, Mook > wrote: >> On Sun, Mar 21, 2010 at 4:22 PM, NightStrike >> wrote: >>> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer 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///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 -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Include paths, float.h
2010/3/23 NightStrike :
> On Tue, Mar 23, 2010 at 12:57 AM, Mook
> wrote:
>> On Sun, Mar 21, 2010 at 4:22 PM, NightStrike wrote:
>>> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer 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
> Mingw-w64-public@lists.sourceforge.net
> 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///include directory
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Include paths, float.h
2010/3/23 Ozkan Sezer :
> On Tue, Mar 23, 2010 at 2:17 PM, NightStrike wrote:
>> On Tue, Mar 23, 2010 at 8:15 AM, Kai Tietz wrote:
>>> 2010/3/23 NightStrike :
On Tue, Mar 23, 2010 at 12:57 AM, Mook
wrote:
> On Sun, Mar 21, 2010 at 4:22 PM, NightStrike
> wrote:
>> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer 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
Mingw-w64-public@lists.sourceforge.net
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///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
--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Include paths, float.h
On Tue, Mar 23, 2010 at 2:17 PM, NightStrike wrote: > On Tue, Mar 23, 2010 at 8:15 AM, Kai Tietz wrote: >> 2010/3/23 NightStrike : >>> On Tue, Mar 23, 2010 at 12:57 AM, Mook >>> wrote: On Sun, Mar 21, 2010 at 4:22 PM, NightStrike wrote: > On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer 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 >>> Mingw-w64-public@lists.sourceforge.net >>> 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///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 -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Include paths, float.h
On Tue, Mar 23, 2010 at 8:15 AM, Kai Tietz wrote: > 2010/3/23 NightStrike : >> On Tue, Mar 23, 2010 at 12:57 AM, Mook >> wrote: >>> On Sun, Mar 21, 2010 at 4:22 PM, NightStrike wrote: On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer 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 >> Mingw-w64-public@lists.sourceforge.net >> 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///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? -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Include paths, float.h
On Tue, Mar 23, 2010 at 12:57 AM, Mook wrote: > On Sun, Mar 21, 2010 at 4:22 PM, NightStrike wrote: >> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] static vs dynamic loading of libgfortran/libstdc++ etc
Hello Brian,
2010/3/23 Prof Brian Ripley :
> The R project (http://www.r-project.org) has been building under
> MinGW-w64 since mid-January. We have ca 2500 extension packages, ca
> 800 of which contain DLLs in C/C++/Fortran/more-than-one-of-those.
>
> In those couple of months the snapshots (at least the i686-mingw ones)
> have gone from dynamic loading of libgfortran/libstdc++ to static
> loading and back again. Was this intentional? We can cope with
> either (but prefer static) but with several hundred DLLs to check and
> an automated build process we could use some consistency -- we have
> already tens and soon to be hundreds of developers who will download a
> snapshot and work on their own extension package.
This switching in behavior is most likely reasoned by seeing the v1.0
builds and our automated 4.5 gcc builds as the same. Shared libstdc++
(and gfortran) are new features of 4.5 gcc, and v1.0 based builds are
using 4.4.x gcc version.
To prevent using shared version you can specify option '-static'.
> We do realize MinGW-w64 is a 'work in progress' project based on
> unreleased versions of GCC. But as we are about to commit to
> production use on a quite large scale, it would be helpful at least to
> know the plans so we can write future-proof documentation for the
> would-be users (where 'future' means 6 months until the next
> documentation release).
Our intention is to support for toolchain the latest three versions.
That means, current head version (bleeding edge), and the latest
releases of the two prior gcc version. We use in general binutils head
for all of our builds.
We have at the moment two branches. The v1.0 branch, which is our
release branch, and trunk/.
At the moment we plan to switch to MS-ABI in name decoration, which is
a long outstanding - but very necessary - step to provide some
inter-operability to VC generated static libraries.
Additional we plan to replace complex math part of crt by our own
version (we are using at the moment the implementation mingw.org
originated by Danny Smith), which has some problems in respect to
ISO-C99 expected results reasoned signness.
Regards,
Kai Tietz
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] static vs dynamic loading of libgfortran/libstdc++ etc
The R project (http://www.r-project.org) has been building under MinGW-w64 since mid-January. We have ca 2500 extension packages, ca 800 of which contain DLLs in C/C++/Fortran/more-than-one-of-those. In those couple of months the snapshots (at least the i686-mingw ones) have gone from dynamic loading of libgfortran/libstdc++ to static loading and back again. Was this intentional? We can cope with either (but prefer static) but with several hundred DLLs to check and an automated build process we could use some consistency -- we have already tens and soon to be hundreds of developers who will download a snapshot and work on their own extension package. We do realize MinGW-w64 is a 'work in progress' project based on unreleased versions of GCC. But as we are about to commit to production use on a quite large scale, it would be helpful at least to know the plans so we can write future-proof documentation for the would-be users (where 'future' means 6 months until the next documentation release). Thank you. Brian Ripley -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
