[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Volker Grabsch
Subject: Re: [Mingw-cross-env-list] Qt 4.7 (help wanted)
Date: Wed, 2 Jun 2010 14:45:48 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Mark Brand <address@hidden> schrieb:
>> #include "..." search starts here:
>> #include<...>  search starts here:
>>   /Users/tonytheodore/dev/mingw-cross-env/usr/i686-pc-mingw32/include
>> /Users/tonytheodore/dev/mingw-cross-env/usr/lib/gcc/i686-pc-mingw32/4.5.0/include
>> /Users/tonytheodore/dev/mingw-cross-env/usr/lib/gcc/i686-pc-mingw32/4.5.0/include-fixed
>> End of search list.
>> 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


and _not_ by the _MinGW-runtime_ headers in


So the <float.h> of the MinGW-runtime took simply the wrong approach.

1) Clean Solution

I think the only "clean" solution is to

    * remove the "#include_next" from MinGW-runtime's <float.h>:


    * add a conditional "#include_next" to GCC's <float.h>:


      (similar to the "#include_next" mechanism of GCC's <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?

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.:


            ./configure ...
            $(MAKE) ...

Do you think this is feasible?


Volker Grabsch
NotJustHosting GbR

reply via email to

[Prev in Thread] Current Thread [Next in Thread]