[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: Mark Brand
Subject: Re: [Mingw-cross-env-list] Qt 4.7 (help wanted)
Date: Wed, 02 Jun 2010 15:08:19 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100527 SUSE/3.1rc1-3.1 Thunderbird/3.1

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.

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


     * 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?

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


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


reply via email to

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