Re: [Mingw-w64-public] [Website] Work on a Download page
2013/5/20 Adrien Nader adr...@notk.org Hi, I've started working on a download page for the website. Currently the download links point directly to the sourceforge file listing but that's not enough for the users to be able to chose the right(tm) download. The page I've done is at: http://notk.org/~adrien/picker.php It's mostly an HTML shim with javascript and a list of toolchain descriptions to generate the page content. The php bit is only there to provide an include directive to easily and cleanly provide a default download list if the user doesn't have JS[1]. As you can see on the page, besides the layout which isn't perfect, the toolchain descriptions are completely wrong. If you maintain such a toolchain and wish to be listed on the download page, please provide me with a toolchain description. The process to update the list on the server is not decided yet but for now, please reply to this email with JS code that creates one or more objects like in http://notk.org/~adrien/toolchains.js . There should also be a way to filter based on compile-time configuration. In particular, the setting for C++ exception matters a lot. I haven't added this yet because I lack visibility about them (how many of them are there in practice?). As such, please also mention such specific settings that you might have for your toolchains and once there is a clearer picture, the code can follow. Don't hesitate to mention anything that may be missing on my page (no, I won't add ponies). For additional reference, here is a page that Jon_Y had done some time ago with a similar goal and a very different implementation: http://mingw-w64.sourceforge.net/picker.php I don't mean this in a bad way, but jon_Y's page seems a lot more direct to me. Perhaps a bit of explanation about what target,host, etc. mean, but pull-down menus seem more intuitive than checkboxes as far as filtering goes. I don't think it is a good idea to keep Linux distro's toolchains on this list. There will be many, and they will continually change and be updated etc. How would you track all these very distro-specific changes? Same with additional software. Traditionally on Windows, this has been provided by the projects themselves, not the toolchain. Unless you have a repo bulging with everything one might need, I don't really see how this could help. To provide some of the info you required: - There are three exception handling mechanisms: sjlj (slowest, both 32 and 64-bit). dw2 (faster, 32-bit only, no exceptions can be thrown accross callbacks), and seh (best, 64-bit only). - There are two libgcc threading variants: win32 and posix. Only the latter allows for the C++11 library's threading to be used. On to the page itself: - I don't think it's a good idea to select on binutils/mingw-w64 trunk versions; some don't use snapshots, information is overkill anyways etc... - Perhaps rename CRT to MinGW-w64 or MinGW-w64 headers and libraries. Just because I'm pedantic about this stuff ;-) How do you plan on updating the picker when e.g. I release a new set of binaries? Cheers, Ruben [1] Actually the JS on that page is incompatible with IE 8 which lacks some JS features that firefox has had since FF 1.5; I'm unable to test the page with IE 8 and it would be great if someone did and reported. -- Adrien Nader -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Fix bug in InterlockedOr
On 5/30/2013 06:45, dw wrote: On 5/24/2013 8:43 PM, dw wrote: I looked at the hand-crafted and the built-in, and they both generate the same code. In the end, I went with the __sync_fetch_and_OP() built-in (attached). The comments above still apply. I'm going to wait for this patch to get committed before sending the next one. It's less confusing that way, although it's taking a little longer than I hoped to get thru them all. If there's anything I can do to help move this along, let me know. Done as trunk r5876. signature.asc Description: OpenPGP digital signature -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Compiling igraph library
Hi List. I'm trying to compile the igraph library using MinGW64, but it's not working, though the 32 bits version compiles well in MinGW. In the source folder of igraph-0.6.5, the command ./configure --prefix=c:/mingw64 CC=x86_64-w64-mingw32-gcc works fine, and this is the final result: GraphML format support -- no GMP library support -- no ... yes Debug -- no Profiling -- no After this, during the make, I got the following error: .libs/libigraph_la-matrix.o: file not recognized: File format not recognized collect2.exe: error: ld returned 1 exit status make[3]: *** [libigraph.la] Error 1 make[3]: Leaving directory '/src/igraph-0.6.5/src' make[2]: *** [all] Error 2 make[2]: Leaving directory '/src/igraph-0.6.5/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/src/igraph-0.6.5' make: *** [all] Error 2 Do you guys have any idea of how to go around this problem? Thanks, *Matheus Viana* *Postdoctoral Research Employee* *Developmental and Cell Biology* *University of California Irvine* * ** * -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Website] Work on a Download page
On Thu, May 30, 2013, Ruben Van Boxem wrote: 2013/5/20 Adrien Nader adr...@notk.org Hi, I've started working on a download page for the website. Currently the download links point directly to the sourceforge file listing but that's not enough for the users to be able to chose the right(tm) download. The page I've done is at: http://notk.org/~adrien/picker.php It's mostly an HTML shim with javascript and a list of toolchain descriptions to generate the page content. The php bit is only there to provide an include directive to easily and cleanly provide a default download list if the user doesn't have JS[1]. As you can see on the page, besides the layout which isn't perfect, the toolchain descriptions are completely wrong. If you maintain such a toolchain and wish to be listed on the download page, please provide me with a toolchain description. The process to update the list on the server is not decided yet but for now, please reply to this email with JS code that creates one or more objects like in http://notk.org/~adrien/toolchains.js . There should also be a way to filter based on compile-time configuration. In particular, the setting for C++ exception matters a lot. I haven't added this yet because I lack visibility about them (how many of them are there in practice?). As such, please also mention such specific settings that you might have for your toolchains and once there is a clearer picture, the code can follow. Don't hesitate to mention anything that may be missing on my page (no, I won't add ponies). For additional reference, here is a page that Jon_Y had done some time ago with a similar goal and a very different implementation: http://mingw-w64.sourceforge.net/picker.php I don't mean this in a bad way, but jon_Y's page seems a lot more direct to me. Perhaps a bit of explanation about what target,host, etc. mean, but pull-down menus seem more intuitive than checkboxes as far as filtering goes. No offense taken. The page I've made tries to show much more information and that comes at the cost of more complexity. There are many many differences between the available toolchains and it's simply impossible to have a proper coverage while keeping everything even remotely exhaustive without adding more things to the page. There is more than half-a-dozen sources of binaries. The page I've linked to is by no mean final however. It clearly needs a frame, i.e. theming, better explanations, ... What is currently there is more like an engine. Fighting javascript's non-existant error reporting along with doing everything through the DOM has taken much more time than theming could need. I don't think it is a good idea to keep Linux distro's toolchains on this list. There will be many, and they will continually change and be updated etc. How would you track all these very distro-specific changes? Same with additional software. Traditionally on Windows, this has been provided by the projects themselves, not the toolchain. Unless you have a repo bulging with everything one might need, I don't really see how this could help. The toolchains of Linux distributions don't change once they're released and I've kept Fedora Rawhide out of the list on purpose. In any case, they cannot change more often than the Automated Builds do and it will be the responsibility of the distribution maintainers to provide the relevant information in a suitable format (more on this below). As for the additional softwares, I strongly believe they matter. C++ makes this even more important because of the incompatible exception handling mechanisms. I've also never enjoyed having to hunt for unreliable prebuilt binaries on tens of websites and software authors don't usually enjoy having to build binaries themselves either (tbh, I've seen reactions vary between disliking it, hating it and despising it). However, I'm open about that: the download page is meant to serve the users. I'll ask people. To provide some of the info you required: - There are three exception handling mechanisms: sjlj (slowest, both 32 and 64-bit). dw2 (faster, 32-bit only, no exceptions can be thrown accross callbacks), and seh (best, 64-bit only). - There are two libgcc threading variants: win32 and posix. Only the latter allows for the C++11 library's threading to be used. Thanks, I completely forgot to mention the exception handling mechanisms. About the threading variants, what is the disadvantage of the posix one? Does it depend on pthreads? On to the page itself: - I don't think it's a good idea to select on binutils/mingw-w64 trunk versions; some don't use snapshots, information is overkill anyways etc... - Perhaps rename CRT to MinGW-w64 or MinGW-w64 headers and libraries. Just because I'm pedantic about this stuff ;-) I'm unsure whether the binutils version should be displayed: I can't remember anything that would make someone strongly prefer one
Re: [Mingw-w64-public] [Website] Work on a Download page
On Thu, May 30, 2013, Baruch Burstein wrote: A check/uncheck all for each section would be useful. You're absolutely right, I'll add something to do this. -- Adrien Nader -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Website] Work on a Download page
2013/5/30 Adrien Nader adr...@notk.org On Thu, May 30, 2013, Ruben Van Boxem wrote: 2013/5/20 Adrien Nader adr...@notk.org Hi, I've started working on a download page for the website. Currently the download links point directly to the sourceforge file listing but that's not enough for the users to be able to chose the right(tm) download. The page I've done is at: http://notk.org/~adrien/picker.php It's mostly an HTML shim with javascript and a list of toolchain descriptions to generate the page content. The php bit is only there to provide an include directive to easily and cleanly provide a default download list if the user doesn't have JS[1]. As you can see on the page, besides the layout which isn't perfect, the toolchain descriptions are completely wrong. If you maintain such a toolchain and wish to be listed on the download page, please provide me with a toolchain description. The process to update the list on the server is not decided yet but for now, please reply to this email with JS code that creates one or more objects like in http://notk.org/~adrien/toolchains.js . There should also be a way to filter based on compile-time configuration. In particular, the setting for C++ exception matters a lot. I haven't added this yet because I lack visibility about them (how many of them are there in practice?). As such, please also mention such specific settings that you might have for your toolchains and once there is a clearer picture, the code can follow. Don't hesitate to mention anything that may be missing on my page (no, I won't add ponies). For additional reference, here is a page that Jon_Y had done some time ago with a similar goal and a very different implementation: http://mingw-w64.sourceforge.net/picker.php I don't mean this in a bad way, but jon_Y's page seems a lot more direct to me. Perhaps a bit of explanation about what target,host, etc. mean, but pull-down menus seem more intuitive than checkboxes as far as filtering goes. No offense taken. The page I've made tries to show much more information and that comes at the cost of more complexity. There are many many differences between the available toolchains and it's simply impossible to have a proper coverage while keeping everything even remotely exhaustive without adding more things to the page. There is more than half-a-dozen sources of binaries. The page I've linked to is by no mean final however. It clearly needs a frame, i.e. theming, better explanations, ... What is currently there is more like an engine. Fighting javascript's non-existant error reporting along with doing everything through the DOM has taken much more time than theming could need. I don't think it is a good idea to keep Linux distro's toolchains on this list. There will be many, and they will continually change and be updated etc. How would you track all these very distro-specific changes? Same with additional software. Traditionally on Windows, this has been provided by the projects themselves, not the toolchain. Unless you have a repo bulging with everything one might need, I don't really see how this could help. The toolchains of Linux distributions don't change once they're released and I've kept Fedora Rawhide out of the list on purpose. In any case, they cannot change more often than the Automated Builds do and it will be the responsibility of the distribution maintainers to provide the relevant information in a suitable format (more on this below). Let's get things straight: the number of Linux distros providing a MinGW-w64 toolchain is only going to keep increasing (currently: Debian+derivatives, Ubuntu+derivatives Fedora+relatives, OpenSUSE, Arch, gentoo, etc...) I don't see any of these have much interest in keeping yet another web page in sync. I'm sure there will be exceptions, but you can't rely on exceptions. Besides, they all have their own package management functions that might advertise mingw-w64 in one way or another depending on a user search. Linux users don't typically use google to find their packages. This whole updating becomes even more undoable when you factor in 3rd party packages, which a distro may or may not provide, and update. I'm just trying to warn you for trying the nigh impossible for IMHO little value. As for the additional softwares, I strongly believe they matter. C++ makes this even more important because of the incompatible exception handling mechanisms. I've also never enjoyed having to hunt for unreliable prebuilt binaries on tens of websites and software authors don't usually enjoy having to build binaries themselves either (tbh, I've seen reactions vary between disliking it, hating it and despising it). I think the regular MinGW(-w64) developer will either be or become quickly accustomed to building all his/her dependencies from source.
Re: [Mingw-w64-public] Mingw-w64-public Digest, Vol 68, Issue 29
Dear Ruben, you can overcome the problem with time.h doing this: After ./configure Open the file Makefile, search for libf2c_la_CFLAGS = Put -DUSE_CLOCK after libf2c_la_CFLAGS = Now it looks like libf2c_la_CFLAGS = -DUSE_CLOCK -DSkip_f2c_Undefs Open igraph-0.6\src\f2c\uninit.c Goto Line 182 or serach for _control87(EM_DENORMAL comment this line /* _control87(EM_DENORMAL . */ Open igraph-0.6\src\f2c\s_paus.c Goto Line 84 or search for pause(); comment this line /* pause(); */ Regarding my problem, I'm now using ./configure --host=x86_64-w64-mingw32, as you said, but there is now another error: ... .libs/libigraph_la-igraph-hrg.o:igraph_hrg.cc:(.eh_frame+0x133): undefined reference to '___gxx_personality_v0' collect2.exe: error: ld returned 1 exit status make[3]: *** [libigraph.la] Error 1 make[3]: Leaving directory '/src/igraph-0.6.5/src' make[2]: *** [all] Error 2 make[2]: Leaving directory '/src/igraph-0.6.5/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/src/igraph-0.6.5' make: *** [all] Error 2 I'm getting crazy with this.. Could you try to compile igraph again by yourself and tell me if you get this working? I'll appreciate that. Many thanks. *Matheus Viana* *Postdoctoral Research Employee* *Developmental and Cell Biology* *University of California Irvine* * ** * 2013/5/30 mingw-w64-public-requ...@lists.sourceforge.net Send Mingw-w64-public mailing list submissions to mingw-w64-public@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/mingw-w64-public or, via email, send a message with subject or body 'help' to mingw-w64-public-requ...@lists.sourceforge.net You can reach the person managing the list at mingw-w64-public-ow...@lists.sourceforge.net When replying, please edit your Subject line so it is more specific than Re: Contents of Mingw-w64-public digest... Today's Topics: 1. Re: [PATCH] Fix bug in InterlockedOr (JonY) 2. Compiling igraph library (Matheus Viana) 3. Re: Compiling igraph library (Ruben Van Boxem) 4. Re: [Website] Work on a Download page (Adrien Nader) -- Message: 1 Date: Thu, 30 May 2013 18:39:23 +0800 From: JonY jo...@users.sourceforge.net Subject: Re: [Mingw-w64-public] [PATCH] Fix bug in InterlockedOr To: mingw-w64-public@lists.sourceforge.net Message-ID: 51a72c5b.4040...@users.sourceforge.net Content-Type: text/plain; charset=iso-8859-1 On 5/30/2013 06:45, dw wrote: On 5/24/2013 8:43 PM, dw wrote: I looked at the hand-crafted and the built-in, and they both generate the same code. In the end, I went with the __sync_fetch_and_OP() built-in (attached). The comments above still apply. I'm going to wait for this patch to get committed before sending the next one. It's less confusing that way, although it's taking a little longer than I hoped to get thru them all. If there's anything I can do to help move this along, let me know. Done as trunk r5876. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 663 bytes Desc: OpenPGP digital signature -- Message: 2 Date: Thu, 30 May 2013 10:21:00 -0700 From: Matheus Viana vian...@gmail.com Subject: [Mingw-w64-public] Compiling igraph library To: mingw-w64-public@lists.sourceforge.net Message-ID: canvnhg_-gjywm9mp306m9mk3fm1lxc3vyzvs5++ew7nzepr...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi List. I'm trying to compile the igraph library using MinGW64, but it's not working, though the 32 bits version compiles well in MinGW. In the source folder of igraph-0.6.5, the command ./configure --prefix=c:/mingw64 CC=x86_64-w64-mingw32-gcc works fine, and this is the final result: GraphML format support -- no GMP library support -- no ... yes Debug -- no Profiling -- no After this, during the make, I got the following error: .libs/libigraph_la-matrix.o: file not recognized: File format not recognized collect2.exe: error: ld returned 1 exit status make[3]: *** [libigraph.la] Error 1 make[3]: Leaving directory '/src/igraph-0.6.5/src' make[2]: *** [all] Error 2 make[2]: Leaving directory '/src/igraph-0.6.5/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/src/igraph-0.6.5' make: *** [all] Error 2 Do you guys have any idea of how to go around this problem? Thanks, *Matheus Viana* *Postdoctoral Research Employee* *Developmental and Cell Biology* *University of California Irvine* * ** * -- next part -- An HTML attachment was scrubbed... -- Message: 3 Date: Thu, 30 May 2013 20:30:03 +0200 From: Ruben Van Boxem vanboxem.ru...@gmail.com Subject: Re: [Mingw-w64-public] Compiling igraph library To:
[Mingw-w64-public] use tdm-gcc to compile wx2.9.4, get i386:x86-64 architecture of input file incompatible error
hello I try to build 32-bit wx2.9.4 with tdm-gcc. My os:windows xp (32bit) 5.1.2600 I download tdm-gcc from http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Installer/tdm64-gcc-4.7.1-3.exe/download I cd wx\build\msw directory and invoke command ../../configure --build=x86_64-w64-mingw32 --host=i686-w64-mingw32 --enable-shared --disable-debug --disable-monolithic --enable-unicode CXXFLAGS=-pipe -m32 fno-keep-inline-dllexport -Os LDFLAGS=-m32 CFLAGS=-m32 I get the error ld.exe: i386:x86-64 architecture of input file `basedll_version_rc.o' is incompatible with i386 output Where is wrong? Another question is if I use mingw32-make,how do I specify --build,--host and --target parameter,such as replace --enable-unicode with UNICODE=1 Thanks -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] use tdm-gcc to compile wx2.9.4, get i386:x86-64 architecture of input file incompatible error
Op 31-mei-2013 05:58 schreef zhangxinghai zxh19750...@163.com het volgende: hello I try to build 32-bit wx2.9.4 with tdm-gcc. My os:windows xp (32bit) 5.1.2600 I download tdm-gcc from http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Installer/tdm64-gcc-4.7.1-3.exe/download I cd wx\build\msw directory and invoke command ../../configure --build=x86_64-w64-mingw32 --host=i686-w64-mingw32 --enable-shared --disable-debug --disable-monolithic --enable-unicode CXXFLAGS=-pipe -m32 fno-keep-inline-dllexport -Os LDFLAGS=-m32 CFLAGS=-m32 I get the error ld.exe: i386:x86-64 architecture of input file `basedll_version_rc.o' is incompatible with i386 output Where is wrong? Another question is if I use mingw32-make,how do I specify --build,--host and --target parameter,such as replace --enable-unicode with UNICODE=1 Thanks It is better to use the same host as build with MSYS, no need confusing the build script into crosscompiling when you're not... Really. For make, you need to check the makefile and the build documentation to see what is possible. Ruben -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
