Re: [Mingw-w64-public] WIA UUIDs for mingw-w64-crt.
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 -- 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
Re: [Mingw-w64-public] WIA UUIDs for mingw-w64-crt.
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. We do NOT want to be like mingw.org in this area -- **at all**. -- 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
Re: [Mingw-w64-public] WIA UUIDs for mingw-w64-crt.
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
Re: [Mingw-w64-public] WIA UUIDs for mingw-w64-crt.
On Fri, Oct 9, 2009 at 8:21 PM, NightStrike nightstr...@gmail.com wrote: 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 :) Bravo. It will be put behind a thousand times and at that time gcc-4.5 will be the current stable with its own bugs which will be fixed in 4.6 but being neglected for backporting, a.s.o. Do you see my point at all? 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
Re: [Mingw-w64-public] WIA UUIDs for mingw-w64-crt.
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... Wolfgang Kai Tietz schrieb: Hello Wolfgang, 2009/10/3 Wolfgang Glas wolfgang.g...@ev-i.at: Hi all, We have recently compiled a Win32-app using mingw-w64, which uses the WIA (Windows Image Acquisition) API. The headder files in mingw-w64-headers are fine and the app compiled without any flaws. However, UUIDs for the WIA interfaces et al. are missing in lbuuid.a, so we gathered them and made an addition to libuuid.a So, I'd like the attached source file to be integrated in mingw-w64-crt/libsrc (don't forget to add the file to Makefile.am...). TIA, Wolfgang Thanks for the patch. Some of those GUIDs are missing, so we are glad about any updates here. I applied it to trunk and branch at revision1445 1446. Cheers, Kai -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] WIA UUIDs for mingw-w64-crt.
Hello Wolfgang, 2009/10/3 Wolfgang Glas wolfgang.g...@ev-i.at: Hi all, We have recently compiled a Win32-app using mingw-w64, which uses the WIA (Windows Image Acquisition) API. The headder files in mingw-w64-headers are fine and the app compiled without any flaws. However, UUIDs for the WIA interfaces et al. are missing in lbuuid.a, so we gathered them and made an addition to libuuid.a So, I'd like the attached source file to be integrated in mingw-w64-crt/libsrc (don't forget to add the file to Makefile.am...). TIA, Wolfgang Thanks for the patch. Some of those GUIDs are missing, so we are glad about any updates here. I applied it to trunk and branch at revision1445 1446. Cheers, Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
