Re: [Mingw-w64-public] Problem with ld...
On 7/11/2013 11:21 PM, xunxun wrote: -Wl,--large-address-aware is only for x86 target Thank you. I've removed this option, since my target is x64, and the compile completes successfully. -David C. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
2013/7/10 Jon jon.for...@gmail.com: While the question about what current users are using is already hard to answer, there's IMO a bigger one: What _potential_ users are there that aren't already using mingw-w64 :) I started looking into mingw-w64 maybe a year ago, only to find out that - there's no 'official' installer/ toolchain - there are a whole bunch of 'personal' builds mingw-w64 derived projects - different projects provide a myriad of different gcc versions x architecture x exception handling mechanism x threading library combinations (and again, little hints on what is the 'recommended' configuration for most users). ...SNIP... I do not say that not offering any option is the right way. But there should be something what is default. And the default should be offered as that. It should be much more visible, and available in a click or two from the homepage. And last but not least, the default should not be tagged as a personal build. You should minimize the number of question he needs to answer to get just some compiler to build my program with. To summarize, IMO, mingw-w64, although technically as good as it is, emits bad signals to newcomers. Unfortunately, it has always been repelling for new users and, I believe, it is also the reason why mingw-builds (although also not ideal for sure) succeeded so easily. It simply filled the gap in the demand, which you never attempted to fill. I believe everyone will concur. ...SNIP... In any case we now have the question: what would be official or even advised? This is not a technical issue. It's primarily a mingw-w64 project leadership and simplification challenge. It's not helpful that neither Kai nor JonY has definitively weighed in on whether an official mingw-w64 default toolchain makes sense. Actually, that's not true. Awhile back Kai was very involved with announcing Ruben as the new build release mgr. I interpreted Kai's actions to mean that he felt mingw-w64 needed a maintained, official, easy-to-use default toolchain in addition to the automated testing builds. Well, I assumed I was clear about that already. IMO it is absolutely necessary that we (mingw-w64) are providing an official toolchain-version, which we are recommenting. To be clear here, those toolchain-releases aren't mingw-w64 releases. The mingw-w64 releaes are just releases of our repository, not that of combinations with other ventures. And exactly this might be confusing here for some people. A pre-build toolchain release is always just one variant of a combination using our stuff with other ventures. That makes such releases so hard to be marked as recommented. Nevertheless I agree completely that we have to provide such pre-build toolchains, so that users have an easier access to our work. But interpreting or implying or inferring is not useful. Explicit clarification from Kai and JonY as mingw-w64 leaders is needed. I suspect one reason why this hasn't happened is that both already have too much on their plate and don't want to set the expectation that either will be responsible for implementing and maintaining an official toolchain like JonY appears (aweome) to be doing at http://cygwin.mirrors.pair.com/release/gcc4/ The old speak-up-and-get-stuck-with-it paradox ;) That's OK, and is why I believe the first step needs to be Kai/JonY saying (a) The mingw-w64 project needs an official, easy-to-use toolchain, (b) Neither of us have the bandwidth to implement/maintain it, and (c) We're actively looking for a new committer to take on this role. If this is going to happen and be sustainable, we need your help. a) yes, b) yes (we need people in charge for that and doing this reliable), c) yes, we are actual in discussion with mingw-builds venture to go together (and/or co-operate more closely). Or say The current situation is fine; mingw-w64 doesn't need an official toolchain. No, we should provide Windows native pre-build toolchain Either way, make things crystal clear. If an official toolchain is important to mingw-w64 and someone has the passion and time to take on the release mgr, the next step is rutheless simplification. For example, take Ruben's existing build infrastructure and morph a baseline version (non buildbot automated) into the mingw-w64 repo. As a strawman to kick about, is the following a good value-add first step? What else can be removed? 1) Build cross (Linux hosted) and non-cross (Windows hosted) on Linux as is currently done. Add build-on-Windows support via MSYS/MSYS2 later. And OS X hosted even later. 2) Keep existing C, C++, Fortran, Obj-C, and Obj-C++ language support. 3) Keep existing mingw32-make and python enabled GDB support. 4) Provide single target 32 and 64-bit compilers for only GCC 4.8.1 using Win32 threading with SEH or SJLJ. Other variants later. 5) Release binaries to
Re: [Mingw-w64-public] End of rubenvb builds
On Fri, 12 Jul 2013 19:43:04 +0200 Kai Tietz ktiet...@googlemail.com wrote: 2013/7/10 Jon jon.for...@gmail.com: While the question about what current users are using is already hard to answer, there's IMO a bigger one: What _potential_ users are there that aren't already using mingw-w64 :) I started looking into mingw-w64 maybe a year ago, only to find out that - there's no 'official' installer/ toolchain - there are a whole bunch of 'personal' builds mingw-w64 derived projects - different projects provide a myriad of different gcc versions x architecture x exception handling mechanism x threading library combinations (and again, little hints on what is the 'recommended' configuration for most users). ...SNIP... I do not say that not offering any option is the right way. But there should be something what is default. And the default should be offered as that. It should be much more visible, and available in a click or two from the homepage. And last but not least, the default should not be tagged as a personal build. You should minimize the number of question he needs to answer to get just some compiler to build my program with. To summarize, IMO, mingw-w64, although technically as good as it is, emits bad signals to newcomers. Unfortunately, it has always been repelling for new users and, I believe, it is also the reason why mingw-builds (although also not ideal for sure) succeeded so easily. It simply filled the gap in the demand, which you never attempted to fill. I believe everyone will concur. ...SNIP... In any case we now have the question: what would be official or even advised? This is not a technical issue. It's primarily a mingw-w64 project leadership and simplification challenge. It's not helpful that neither Kai nor JonY has definitively weighed in on whether an official mingw-w64 default toolchain makes sense. Actually, that's not true. Awhile back Kai was very involved with announcing Ruben as the new build release mgr. I interpreted Kai's actions to mean that he felt mingw-w64 needed a maintained, official, easy-to-use default toolchain in addition to the automated testing builds. Well, I assumed I was clear about that already. IMO it is absolutely necessary that we (mingw-w64) are providing an official toolchain-version, which we are recommenting. To be clear here, those toolchain-releases aren't mingw-w64 releases. The mingw-w64 releaes are just releases of our repository, not that of combinations with other ventures. And exactly this might be confusing here for some people. A pre-build toolchain release is always just one variant of a combination using our stuff with other ventures. That makes such releases so hard to be marked as recommented. Nevertheless I agree completely that we have to provide such pre-build toolchains, so that users have an easier access to our work. But interpreting or implying or inferring is not useful. Explicit clarification from Kai and JonY as mingw-w64 leaders is needed. I suspect one reason why this hasn't happened is that both already have too much on their plate and don't want to set the expectation that either will be responsible for implementing and maintaining an official toolchain like JonY appears (aweome) to be doing at http://cygwin.mirrors.pair.com/release/gcc4/ The old speak-up-and-get-stuck-with-it paradox ;) That's OK, and is why I believe the first step needs to be Kai/JonY saying (a) The mingw-w64 project needs an official, easy-to-use toolchain, (b) Neither of us have the bandwidth to implement/maintain it, and (c) We're actively looking for a new committer to take on this role. If this is going to happen and be sustainable, we need your help. a) yes, b) yes (we need people in charge for that and doing this reliable), c) yes, we are actual in discussion with mingw-builds venture to go together (and/or co-operate more closely). Or say The current situation is fine; mingw-w64 doesn't need an official toolchain. No, we should provide Windows native pre-build toolchain Fantastic. These days I don't get to contribute to OSS as much as I'd like, but if it would be useful, I'll carve out time to test/provide feedback on any toolchain build tool you and the mingw-builds team come up with. I'm fixated by easy-to-use port-like build automation tools that do the typical cycle of download - verify - patch - configure - build - stage - package and am continuously toying with one of my own little monsters for building common libs with mingw-w64: https://github.com/jonforums/buildlets So, I'm curious on what you guys are building and would like to help, even if it's just easy-of-use testing of the build tool. Jon --- Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat.
Re: [Mingw-w64-public] [Patch] InterlockedIncrement/Decrement etc
2013/7/11 dw limegreenso...@yahoo.com: 1) Move these functions to intrin-impl.h: _InterlockedIncrement16, _InterlockedDecrement16, _InterlockedCompareExchange16, _InterlockedIncrement, _InterlockedDecrement, _InterlockedExchange, _InterlockedExchangeAdd, _InterlockedCompareExchange, _InterlockedIncrement64, _InterlockedDecrement64, _InterlockedExchangeAdd64, _InterlockedExchange64, _InterlockedCompareExchange64, _InterlockedExchangePointer, _InterlockedCompareExchangePointer 2) Change these functions to use builtins instead of inline asm. 3) Remove non-underscore and __stdcall versions of these functions from intrinsics\*.c 4) For x86 versions of InterlockedCompareExchange, InterlockedCompareExchange64, InterlockedDecrement, InterlockedExchange, InterlockedExchangeAdd, InterlockedIncrement, use macro to map to intrinsics instead of using kernel32.dll (as MS does). dw -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public Looks fine to me. Thanks, Kai -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] What is mingw-w64-libraries/pseh?
I'm doing more work on the intrinsics. While checking to see what my changes will affect, I noticed that (mingw-w64-libraries\pseh\src\i386\framebased-gcchack.c) is using __readfsdword and __writefsdword. These functions will gp fault if called on x64. Is this code intended to be x86 specific? dw -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] What is mingw-w64-libraries/pseh?
The pseh lib is 32 bit only. seh on 64 bit is different and btw supported by gcc :) Am 12.07.2013 20:33 schrieb dw limegreenso...@yahoo.com: I'm doing more work on the intrinsics. While checking to see what my changes will affect, I noticed that (mingw-w64-libraries\pseh\src\i386\framebased-gcchack.c) is using __readfsdword and __writefsdword. These functions will gp fault if called on x64. Is this code intended to be x86 specific? dw -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] What is mingw-w64-libraries/pseh?
The pseh lib is 32 bit only. seh on 64 bit is different and btw supported by gcc :) I was hoping you'd say that. That means I don't have to try to change any of it. Thanks for the info. dw -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
