On Fri, Oct 9, 2009 at 1:17 PM, Ozkan Sezer <seze...@gmail.com> wrote:
> On Fri, Oct 9, 2009 at 8:00 PM, NightStrike <nightstr...@gmail.com> wrote:
>> On Fri, Oct 9, 2009 at 12:54 PM, Ozkan Sezer <seze...@gmail.com> wrote:
>>> On Fri, Oct 9, 2009 at 5:22 PM, Kai Tietz <ktiet...@googlemail.com> wrote:
>>>> Hello Wolfgang,
>>>>
>>>> 2009/10/4 Wolfgang Glas <wolfgang.g...@ev-i.at>:
>>>>> Hello Kia,
>>>>>
>>>>> Thanks for applying ;-)
>>>>>
>>>>> I found some time to think about the remaining problems, which you were
>>>>> unable
>>>>> to push upstream like float.h, stddef.h header clash between
>>>>> mingw-w64-crt and
>>>>> gcc or making -mms-bitfields default. IMHO I would be best to maintain a
>>>>> small
>>>>> set of patches to gcc, which should be applied to a gcc tarball before
>>>>> building.
>>>>>
>>>>> This solution is not very elegant, but it might help to convince the gcc
>>>>> developers, that a patch, which is useful to many users should be applied
>>>>> to the
>>>>> mainline dispite all concerns...
>>>>
>>>> To prepare such a patch and provide it as optional could be a way to
>>>> solve this. But the experience has shown that such patches don't
>>>> getting applied to mainline. So I have here some concerns about such a
>>>> approach.
>>>>
>>>> Kai
>>>>
>>>> --
>>>> | (\_/) This is Bunny. Copy and paste
>>>> | (='.'=) Bunny into your signature to help
>>>> | (")_(") him gain world domination
>>>
>>> Another way would be adding a mingw_branch to gcc branches svn.
>>> Patches even applied upstream are being neglected and does not
>>> get reviewed for backporting to 4.4-stable by the maintainers
>>> these days. So, it may serve both for such backports, as well
>>> as for features which are being approached with reservations,
>>> such as stddef.h & co.
>>
>> Creating our own gcc branch to support backports is definitely not
>> where we want to go. If someone goes through the trouble of
>> backporting, the patches do get accepted. It's just that people
>> generally don't do it. If you can find the time to put ti into some
>> mingw special gcc branch, then it can go into 4.4 upstream.
>>
>
> See:
> http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02202.html
> http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00317.html
>
> .. and remember that 4.4 is frozen at RC state.
I didn't say it would be instant :)
>> We do NOT want to be like mingw.org in this area -- **at all**.
>>
>
> Read what I said. I suggesed a branch at gcc.gnu.org. If
> you don't like that, either, well, I disagree.
Yes, I realize that. But a release branch at gcc is really not the
way to go with this. The real issue is in restoring our connections
so that things are addressed in a timely fashion.
Having two separate release branches, one that's special cased to a
specific subset of targets, is just creating more dichotomy where it
need not exist.
Now that I am back, I will talk to the gcc maintainers to try to
address the real underlying issue.
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
