Re: [Mingw-cross-env-list] Qt 4.7 (help wanted)

[Mark Brand]

> > > I've attached the modified spec file I used, the most important option
> > > is -nostdinc. The only section I changed is the *cpp. I'd didn't get
> > > to figuring out how to generate the file and putting it in the right
> > > spot to be found automatically.
> > That look like a good way to do that, if that's really what should be
> > done. What about my doubts about whether reordering the search path is
> > the correct approach?
> Indeed, this might be the wrong approach. The "#include_next" stuff
> is designed to be used by the _GCC_ headers in
>
>      usr/lib/gcc/i686-pc-mingw32/4.5.0/include/
>
> and _not_ by the _MinGW-runtime_ headers in
>
>      usr/i686-pc-mingw32/include/
>
> So the<float.h>  of the MinGW-runtime took simply the wrong approach.

Sounds right to me.


> 1) Clean Solution
> =================
>
> I think the only "clean" solution is to
>
>      * remove the "#include_next" from MinGW-runtime's<float.h>:
>
>              usr/i686-pc-mingw32/include/float.h
>
>      * add a conditional "#include_next" to GCC's<float.h>:
>
>              usr/lib/gcc/i686-pc-mingw32/4.5.0/include/float.h
>
>        (similar to the "#include_next" mechanism of GCC's<stdint.h>:
>         usr/lib/gcc/i686-pc-mingw32/4.5.0/include/stdint.h)
>
> However, this solution requires changes to GCC as well as MinGW-runtime,
> so whoever wants to solve it should discuss that with both groups.
> I certainly don't have the time for that, but maybe someone else does?

This is what my "diff" from a few posts ago did, except that the  
"#include_next" in GCC's <float.h> is not conditional, but this does not 
matter for us since we only do mingw.

Or, while holding your nose, just swap the 2 float.h files after gcc is 
installed.

> 2) Workaround
> =============
>
> In the meantime, I think the best approach is _not_ to try to "fix"
> that, as any other "solution" won't be real solution to the underlying
> problem. Even worse, such a hack might be mistaken for a proper solution,
> leading others (like us :-)) to think that e.g. modifying the system
> include paths is the way to go.
>
> Instead, we should provide an explicit workaround until the problem
> is really fixed. A workaround should be explicit and non-intrusive.
> So I think it should only affect float.h under Qt, and nothing else.
>
> My favourite approach, if it works, would be:
>
>      * copy MinGW-runtime's<float.h>  to Qt's include/ folder, i.e.:
>
>              usr/i686-pc-mingw32/include/float.h
>              ->
>              tmp-qt/.../.../include/
>
>              ./configure ...
>              $(MAKE) ...
>
> Do you think this is feasible?

It's probably feasible, but so far I think I prefer applying 1) to 
mingw-cross-env installations. The problem seen building Qt is just a 
manifestation of a general problem with float.h/mingw/gcc. It might 
affect packages included or built with mignw-cross-env in the future. 
For all I know it may already affect packages adversely but silently. 
The "clean solution" *must* not break anything, and if it does I would 
rather know about it sooner than later.

The other thing to consider is that other distros are already doing this 
kind of thing.

I expect that this will eventually be sorted out among gcc, mingw, and 
mingw-w64 even without one of us volunteering to coordinate it. :)

-Mark