Re: [Mingw-w64-public] Syber Terrorist, please help!!
This is a technical mailing list, why are you waisting your and our time with discussing political questions on a technical mailing list? Best regards, Wolfgang Am 09.11.13 14:52, schrieb Incongruous: Who are you people? It looks that this is one of those Trojan building groups associated with Google. I would like the list manager to response to this message, Is MinGW a tentacle of Google and its political objectives? My company is an Non-Political support for any country or association that promotes and/or finances war and/or the killing of other human beings. Having a Google associated group as a direct or indirect association to us is unacceptable. Please respond. -Original Message- From: Ray Donnelly Sent: Friday, November 08, 2013 5:46 PM To: mingw-w64-public@lists.sourceforge.net Subject: Re: [Mingw-w64-public] Syber Terrorist, please help!! Please leave and take care that the door doesn't hit you on the way out. On Fri, Nov 8, 2013 at 10:41 PM, Incongruous incongru...@outlook.com wrote: My oh my, you are one of them, aren't you. Wait, what about MinGW, is MinGW a tentacle of Google? -Original Message- From: Ozkan Sezer Sent: Friday, November 08, 2013 3:09 PM To: mingw-w64-public@lists.sourceforge.net Subject: Re: [Mingw-w64-public] Syber Terrorist, please help!! On 11/8/13, Incongruous incongru...@outlook.com wrote: Please help me, a terrorist group calling themselves Google has invaded my computer. Every time I run IE11 it displays the web page of this abusive organization. Is there a way that Microsoft could provide some sort of protection against this kind of threat? Is there a way to stop this organization's political power from terrorizing our work/home computers? Please Microsoft, you are our only hope. Can someone please ban this guy? -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Dr. Glas Wolfgang Geschäftsführung ITEG IT-Engineers GmbH | Conradstraße 5, A-6020 Innsbruck FN 365826f | Handelsgericht Innsbruck | Mobiltelefon: +43 699 12090424 Mail: wolfgang.g...@iteg.at | Web: http://www.iteg.at/team/wglas -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error
Re: [Mingw-w64-public] Syber Terrorist, please help!!
Am 09.11.13 15:24, schrieb Incongruous: Ah! You are one of them!! I am subscribing RIGHT NOW!! There you, go, bye, bye -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/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] General Help needed
Hello Rüdiger, Am 29.11.11 09:02, schrieb dehme...@atg-lm.com: Hello, What we have: a running mingw32 32bit cross compiler on our Linux box. What we need a mingw-64bit cross compiler on our Linux box. We can not use the binaries because of our old Linux system (from 2007 old GLIBC, but we cannot touch this system because of other important software running on it) What distro is running on this box? We are maintaining debian packages of mingw-w64 cross-compilers for debian squeeze and operate cleanroom build services on top of these packages, some infos are available here: https://www.clazzes.org/projects/mingw-debian-packaging/ These packages might well be ported to debian lenny. However, I suggest that you use some sort of chroot/openvz/vituralization approach to operate your build services. mixing production systems and build services is a dangerous thing from tha Q/A point of view. Now we have download the src tar - what to do next? We'd really appreciate if we could join forces to build a enterprise-grade cross-compiler suite on top of Linux. Is there a step by step instruction available? Can we generate 64bit and 32bit from the same source by using different --target options? We build 32bit and 64bit Windows binaries by using a seperate build dir for each target. Best regards, Wolfgang -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] libstdc++ built for and by cross-compiler has no symbols
Am 23.11.11 05:11, schrieb xunxun: 于 2011/11/23 5:51, Ruben Van Boxem 写道: I'm attempting to make Arch user packages for MinGW-w64, but it seems I'm failing miserably. Although I'm using the exact same (more or less) steps as in my Personal build scripts, the cross-compiler's libstdc++ (and probably all other runtime libs) contain no symbols, which makes linking to them useless, i.e. undefined references all over the place. [snip] I'll try an unreleased version of binutils next, see if that automagically makes all my troubles go away :/ You can use nm to see the size and symbols of libstdc++.dll.a, I think it's the dlltool's issue. BTW, you can try binutils 2.22 release. Hi Ruben, We have observed this problem in the 32bit libstdc++ DLL, when using gcc-4.6.2 together with binutils-2.21.1. However, the 64bit libstdc++ DLL was OK. The problem went away by using a recent binutils-2.22.51 weekly snapshot. (We use 2.22.51 as of 2011-11-11, last binary date in the century ;-) It would be nice to receive some explanations on this issue by more eligible person, maybe Kai can tellus, which binutils revision/oatch fixes this problem... Best Regards, Wolfgang -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Custom toolchain build with gcc-4.4.5 (2010-09-14)
On 2010-09-18 18:03, NightStrike wrote: On Sat, Sep 18, 2010 at 11:10 AM, Ozkan Sezer seze...@gmail.com wrote: On Wed, Sep 15, 2010 at 9:49 AM, Ozkan Sezer seze...@gmail.com wrote: [snip] There is an optional small package in them, pr45300.zip, which is an update for the C++ headers cstdio, cstdlib and cwchar, fixing GCC PR libstdc++/45300: their location is different based on which toolchain you are using. Follow the README files to upgrade. Maybe time for a new release entirely? I'd really appreciate a new complete release, because we build the stuff from Ozkan's sources and have no possiblity to patch the stuff at post-build time. (We're building a debian package...) Wolfgang -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Custom toolchain build with gcc-4.4.5 (2010-09-14)
Hello Ozkan, Thanks very much for your new toolchain, we are packaging a lot of libraries and therefore obey a conservative policy for choosing the underlying toolchain ;-) You might call it packagers' fate, however we have a couple of productive packages out there, which build and run very well with gcc-4.4 ;-) Just for clarification: The DDK header seem to be back in your distribution, so I don't have to pull in ddk_test manually, is this right? Another question is whether we will see an all-in-one harmonized binutils/gcc/mingw-w64 package for gcc-4.5.x in the future, maybe some sort of official release or a sezero package? (Mabe you should register a brand for sezero's famous mingw-w64 pacakges ;-) Wolfgang -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Custom toolchain build with gcc-4.4.5 (2010-09-14)
On 2010-09-15 13:45, Ozkan Sezer wrote: On Wed, Sep 15, 2010 at 2:39 PM, JonY jo...@users.sourceforge.net wrote: On 9/15/2010 19:13, Wolfgang Glas wrote: On 2010-09-15 10:50, Ozkan Sezer wrote: On Wed, Sep 15, 2010 at 11:33 AM, Wolfgang Glaswolfgang.g...@ev-i.at wrote: You might call it packagers' fate, however we have a couple of productive packages out there, which build and run very well with gcc-4.4 ;-) Out of curiosity, are those packages failing with newer gcc, or are you just being strict for choosing the compiler version? It took us a hell lot of time to build up a debian repository (http://deb.clazzes.org) with mingw-w64,zlib,libxml,omniorb,libpng,libtiff,qt4 etc. and we're happy that all this stuff plays together well and is stable, where stable means more than having a stable compiler toolchain. So we did not have the time to play with gcc-4.5.x for now. Moreover, it's not so easy to keep up to date with all the different packaging philosophies out there, we have mingw-w64 snapshots, sezero, TDM, dimitij Ledkovs's debian packaging efforts many ways to get confused :-/ Be warned that gcc 4.x.x-4.5.0 ABI is not compatible with future versions. From 4.5.1 and 4.6.x onwards, 64-bit symbols do not have the _ prefix. Binutils CVS (2.20.51 as of writing) is also needed. My 4.4-based builds have backports of those changes. We're already working with the no underscore ABI. However, changing the toolchain means building up all needed libraries from scratch using the new toolchain, so we should never run into any ABI incompatibility issues. We call such a complete new toochain build a new generation, so old projects can rely on and older generation of the toolchain. This way we can guarantee clean room builds of software projects for a substantial maintainance period of 2 or more years. Wolfgang -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Custom toolchain build with gcc-4.4.5 (2010-07-11)
On 2010-07-12 13:25, Ozkan Sezer wrote: On Sun, Jul 11, 2010 at 10:06 PM, Ozkan Sezer seze...@gmail.com wrote: [snip] --- - Wolfgang Glas previously reported that the dllwrap tool is broken. I haven't tested myself to confirm the breakage and not done anything in this build to fix it yet, either. Just uploaded a tiny update package for win64-targeting toolchains fixing this particular issue: sezero_20100711_w64_dllwrap_update.zip Ozkan, I knew that this low-hanging fruit for you and you will fix this thing ;-) I just came across it, because I tried to build zlib using historic makefiles... Wolfgang -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Where has ddk/usbiodef.h gone?
On 2010-06-07 08:52, Ozkan Sezer wrote: On Mon, Jun 7, 2010 at 12:09 AM, Dmitrijs Ledkovs dmitrij.led...@ubuntu.com wrote: On 6 June 2010 12:00, Ozkan Sezer seze...@gmail.com wrote: On Sun, Jun 6, 2010 at 1:37 PM, Wolfgang Glas wolfgang.g...@ev-i.at wrote: Hi all, I'm using GUID_DEVINTERFACE_USB_DEVICE in my windows code, which uses setupapi.dll. This declaration has been in ddk/usbiodef.h as of mingw-w64-gcc-4.4.1 However this header seems to be gone in erecnt versions (I'm currently on sezero gcc-4.4.5-20100527). Morevover I can't find GUID_DEVINTERFACE_USB_DEVICE in any other header. Does anybody have deper insights into this issue? Ragards and TIA, Wolfgang This is a problem in our way of providing ddk headers: We do a svn-link to reactos headers, specifically to their Is the svn-link pinned to a particular revision on the 1.0 branch? It is not. (Stability reproducibility is important for packagers ;-) ) I'd like to double the request for reproducability. From the packagers viewpoint it would be better to stick to a hand-selected (and tested) snapshot of upstream sources. Ozkan, will you provide us with a new snapshot once the missing header problem is sorted out? Best regards, Wolfgang -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] dllwrap broken in recent binutils?
Hi all, I'm currently using sezero's 20100515 distribution and I'm in the works to switch to 20100527. (Great work, sezero, big hands :-) Everything worked fine for 20100515, I even got a qt-4.7 snapshot cross-compiling without any flaws so far. The only problem I encounterd was, that all DLLs linked with dllwrap produce an 'application failed to load properly (0xc412)' windows error. This was tha case for zlib, which I now link using gcc. However, for openssl-0.9.8n I don't have the possibility to switch to gcc linking, because openssl-0.9.8 traditionally used dllwrap. (I know, openssl-1.0.0 is out, but I have lots of software, which has not yet been reviewed for 1.0.0 compatibility, so be patient with me...) Does anbody know, whether dllwrap has recently been fixed in binutils CVS and whether the 20100527 snapshot eventually contains such a fix? TIA and best regards, Wolfgang -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] dllwrap broken in recent binutils?
On 2010-05-30 19:18, Ozkan Sezer wrote: On Sun, May 30, 2010 at 12:29 PM, Wolfgang Glas wolfgang.g...@ev-i.at wrote: The only problem I encounterd was, that all DLLs linked with dllwrap produce an 'application failed to load properly (0xc412)' windows error. This was tha case for zlib, which I now link using gcc. However, for openssl-0.9.8n I don't have the possibility to switch to gcc linking, because openssl-0.9.8 traditionally used dllwrap. (I know, openssl-1.0.0 is out, but I have lots of software, which has not yet been reviewed for 1.0.0 compatibility, so be patient with me...) Does anbody know, whether dllwrap has recently been fixed in binutils CVS and whether the 20100527 snapshot eventually contains such a fix? AFAIK, dllwrap had no recent changes in the sourceware CVS. I'd like to know if it behaves differently with the 2010-05-27 build but I really doubt it would. It might be something with the recent Ozkan, ThX for your reply. FYI, I've managed to link openssl-0.9.8n using gcc in the meanwhile, which works around the problem for me. Honestly, I doubt that dllwrap is of great value for producing new libraries. AFAIK, dllwrap has been used to wrap static libraries, which are given in binary form and do not properly declare dllimport/dllexport in their headers. However, the last usecase can nowadys be established by using gcc -Wl,--dll -shared libmyoldlib.a myoldlib.def -o myoldlib.dll -Wl,--import-lib, libmyoldlib.dll.a so I'm not sure whether we will find any usecase that can solely be established by dllwrap... Anywaxs, tha tool is there and some legacy Makefiles stick to using it, so it should be fixes in the mid term run. Best regards, Wolfgang -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Custom toolchain build with gcc-4.4.5 (2010-05-15)
Hello Ozkan, Many thanks for your efforts, the 2010-05-15 seems to works for me ;-) However, I nedd the attacched patch to compile your current binutils version. This patch fixes three occurrences of sprintf, which is obviously used instead of strcpy. (Causes gcc errors like 'format argument to sprintf is not a string literal...') I think this bug has been introduced by the MSVCRT compatibility patch, which has recently been introduced. Please note, that this is not only a cosmetical fix, because the use of arbitrary input data in sprintf may lead to memory corruption and crashes. (If the input string incidentially contains %s, %d or something the like... So I kindly ask you to apply my patch to binutils Best regards, Wolfgang On 2010-05-15 10:45, Ozkan Sezer wrote: I updated my custom w32/w64 native and cross-compiler build with gcc-4.4 with several backports and fixes from mainstream, and put them under the mingw-w64 sf.net file release system under the subdirectories: - Toolchain sources - Personal Builds, - Toolchains targetting Win32 - Personal Builds and - Toolchains targetting Win64 - Personal Builds Build 2010-05-15: Changes since the previous 2010-05-13 build: - Fixed a major linker issue. Changes since the previous 2010-04-28 build: - The mingw-w64 crt and headers updated to rev. 2373 / 2010-05-13, - Gcc updated to the 4.4.5 prerelease version, svn rev. 159365, - All other software has been updated to the latest available versions as of 2010-05-11 / 22:10 GMT. - Several binutils patches from Doug Semler which introduce import library compatibility with vendor compiler/linker. (See Doug Semler's repository at http://github.com/tpaxatb/buildscripts ) - New included binutils (ld) version fixes a linker symbol underscoring problem. - Enabled shared libobjc and libgfortran dlls. - Fixes for the libobjc dll from Doug Semler. - Gcc updated to 4.4.5-prerelease rev. 159365 to fix several issues. - Fixes for gcc PR/44046 and PR/43953. - Fortran updates from upstream for win32 CONIO support and large file support, along with a mktemp fix. - Mingw-w64 updated to svn revision 2373 to fix several issues, such as a fix for the lack of __lc_codepage symbol in new windows versions, fixes for *time_r macros, updates to GL.h to include windows.h and to ws2tcpip.h to include winsock2.h. - Updated pthreads patch for mingw-w64. - Compatibility Notice: ** No leading underscore ** Unlike the other builds from mingw-w64 up to 2010-04-27, these new win64 targetting toolchains do *not* prepend an undersocore to the symbols and follows the MSVC x64 convention. Therefore, any of the link libraries from previous toolchains are incompatible with the ones created by these new builds. - Note: the install_dir/include path problem of the native builds is not looked into, yet. Maybe in the future builds. Versions: - Common in both cross- and native-toolchains: gcc : svn rev. 159365 (4.4.5 prerelease with many patches) binutils : 2.20.51 (cvs, 2010-05-11 / 22:10 GMT) with some patches. mingw-w64-crt : svn revision 2371 (2010-05-13) mingw-w64-headers : svn revision 2373 (2010-05-13), with a couple of patches. glext headers: 2010-03-17 (from the Khronos Group) pthreads-win32: 2.9.0 (cvs, 2010-02-28 20:00 GMT) with w64 patch applied. In native-toolchains only: gmp : 4.3.2 (with w64 patch applied) mpfr: 2.4.2-p3 mpc : 0.8.1 gdb : 7.1.50 (cvs, 2010-05-11 / 22:10 GMT, with minor w64 patches applied.) make: 3.81.90 (cvs, 2010-02-02 15:20 GMT, with w64 patches applied according to savannah bug items 27809 and 27825, and patched further to kill a horde of compiler warnings) gendef, libmangle: from mingw-w64 svn/trunk File names: --- * Source: - mingw-w64-src_20100515_sezero.tar.gz * Targetting Win64: - mingw-w64-bin_x86_64-mingw_20100515_sezero.zip native compiler toolchain for running on x64-windows host and creating x64-windows binaries. - mingw-w64-bin_i686-mingw_20100515_sezero.zip cross compiler toolchain for running on x86-windows host but creating x64-windows binaries. - mingw-w64-bin_i686-linux_20100515_sezero.tar.gz cross compiler toolchain for running on a i686-linux host and creating x64-windows binaries. - mingw-w64-bin_x86_64-linux_20100515_sezero.tar.gz cross compiler toolchain for running on a x86_64-linux host and creating x64-windows binaries. * Targetting Win32: - mingw-w32-bin_i686-mingw_20100515_sezero.zip native compiler toolchain for running on x86-windows host and creating x86-windows binaries. - mingw-w32-bin_i686-linux_20100515_sezero.tar.gz cross compiler toolchain for running on a i686-linux host and creating x86-windows binaries. - mingw-w32-bin_x86_64-linux_20100515_sezero.tar.gz cross compiler
Re: [Mingw-w64-public] Custom toolchain build with gcc-4.4.5 (2010-05-15)
On 2010-05-16 22:43, Ozkan Sezer wrote: On Sun, May 16, 2010 at 11:03 PM, Wolfgang Glas wolfgang.g...@ev-i.at wrote: [snip] For the next builds, I will include this, thanks. BTW, same effect can also be accomplished by adding a format string to the sprintf call, too. Yes, 'sprintf(dest,%s,src)' is equal to 'strcpy(dest,src)', if that makes your code honestly more readable ;-) -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 gcc-4.4.4 release?
Hi Дмитрий (Dmitrijs), Thank for adding me to the ming-w64 ubuntu group ;-) On 2010-05-05 11:22, Dmitrijs Ledkovs wrote: On 4 May 2010 22:07, Wolfgang Glas wolfgang.g...@ev-i.at wrote: On 2010-05-04 17:34, Dmitrijs Ledkovs wrote: On 4 May 2010 15:25, Wolfgang Glas wolfgang.g...@ev-i.at wrote: On 2010-05-04 15:48, Dmitrijs Ledkovs wrote: On 4 May 2010 13:37, Wolfgang Glas wolfgang.g...@ev-i.at wrote: Summing up, suach an official mingw-w64-gcc-4.4.4 release would be very benefitial to us, although this might cause some extra hazzles. Which languages do you need? I have working debian packages for i686 x86_64 crossing to i686 x86_64 w64 using ubuntu gcc-4.4-source and binutils-source as the base and mingw-w64 trunk tip for crt headers. I have gcc,g++,gcj and gfortran and I have working debian packages for gcc-4.4.1 Actually I just built the packages as decribed in the mingw-w64 WIKI and therefore, I have a gfortran built alongside. Up to now I did not try the fortran compiler... Just compiled a simple test program fir Win32 and win64 and both binaries are functional ;-) Can you please write s simple Fortran programm which will call this: 60 /* GETLOG (LOGIN), g77 intrinsic for retrieving the login name for the 61process. 62CHARACTER(len=*), INTENT(OUT) :: LOGIN */ Program is attached, however it produces the same result on ubuntu karmic-x86_64, Win32 and Win64: 80 bytes of binary garbage. (All compilers are 4.4.1 flavors, under linux I additionally tried 4.3.4) It seems, that these historic g77-intrinsics were only half-way ported to gfortran and produce garbage. Programs, which do not use g77 intrinsics seem to work for my part. (A simple 3x3 matrix inversion test is attached, which works for me under Linux-x64_86, Win32 and Win64 using the mingw-w64-gcc-4.4.1 toolchain. Compile it targetting x86_64-w64-mingw32 and run it there? It should fail you should obtain a stack trace =) Well, fails under all operating systems :( The piece of code above is from libgfortran I don't know how to write fortran =) This is the documentation and from the documentation I crafted my example program. Wher do you host your packages? Maybe we should join our forces in order avoid double work? We maintain a SVN repository for the basic packaging infrastructure and your are welcome to get write access to it. I might as well join any repository on your side, if this solution is more feasible. I don't use SVN generally =) and with your ppa even though it has many softwares build these packages are not policy compliant and I'm intending to take over the debian/ubuntu archives with my packaging ;-) Well, your binutils, mingw-w64-headers and gcc packages look very fine and I don't have any problems with your choice of the underlying source code. Thank you. No worries ;-) Frankly speaking, I'd really like to stick to porting libraries rather than maintaining the compiler and binutils base. So, I'd suggest, that I join your team and make my ported libraries policy compliant and rebase them on your toolchain build. Therefore I kindly beg you to tell me in what respect the packages are non-compliant, so I can address these issues. lintitian -IiX --pedantic *.changes Will have a a few things to say =) OK, I will have a look, once we have binutils and gcc up and running. Overall it's not bad, it's good enough =) I guess I just thought I could do better. I'm not particularly keen on maintaining on libraries but I would love to browse your svn if that is possible. What is the licence of your packaging? Feel free to use it in any way, it's my own work. Intentionally, the packaging license should be the same than the license of the incorporated package, but I don't want to put any restrictions on the packaging beyond the intention that I can get back any derived work, which seems to GPLish, isn't it ? And I want to roughly follow http://fedoraproject.org/wiki/Packaging/MinGW Where cross-compiled binaries get installed into /usr/target/sys-root/mingw I'm personally not a fan of such baroque path', however, it's a decent semi-standard and if you can easily adapt the integrated gcc+mingw-w64-crt build atop of this structure, I will adapt the ported libraries to it. I'm downloading a few of your packages now to see how they are done. With libraries management I was planning to just modify debhelper cdbs and upload the sources from the archive unchanged =) cause I wanted to benefit from all the packaging already done in debian. Well, *many* libraries need mingw-w64 specific patches, sometimes small build system amendments, sometimes patches to the sources themselves, some configure-scripts and makefiles terribly fail to install the stuff into the right directories... So, I think the quest for an automatic porting of debian-sources is too ambitious for the moment, let's solve one problem after the other. If we have working
Re: [Mingw-w64-public] mingw-w64 gcc-4.4.4 release?
On 2010-05-05 16:49, Ozkan Sezer wrote: Can you please write s simple Fortran programm which will call this: 60 /* GETLOG (LOGIN), g77 intrinsic for retrieving the login name for the 61process. 62CHARACTER(len=*), INTENT(OUT) :: LOGIN */ Your getlog.f prints garbage even when compiled for linux. The attached one, however, works just fine. (see testsuite/gfortran.dg/g77_intrinsics_sub.f for several intrinsic tests.) Ozkan, you're right, my program is wrong. It's been a long time since I crafted my last FORTRAN program :-/ I've mistaken an array of character*1 objects for a character*80 objects, sorry. Regards, Wolfgang -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 gcc-4.4.4 release?
On 2010-05-05 17:50, Ozkan Sezer wrote: On Wed, May 5, 2010 at 6:42 PM, Dmitrijs Ledkovs dmitrij.led...@ubuntu.com wrote: On 5 May 2010 16:31, Ozkan Sezer seze...@gmail.com wrote: On Wed, May 5, 2010 at 6:22 PM, Wolfgang Glas wolfgang.g...@ev-i.at wrote: On 2010-05-05 16:49, Ozkan Sezer wrote: Can you please write s simple Fortran programm which will call this: [snip] This is great! Can someone please compile it for 64 bit windows now using w64-gfortran and run it? Cause if that will segfault we have an awesome bug to report about gfortran =) Already tested that before sending. Compiled using my own x86-linux- w64 toolchain, the result runs just fine on w64. (why should it fail?) Runs for me under win32 and win64 using mingw-w64-gcc-4.4.1 as packaged in our clazzes.org ubuntu PPA. Wolfgang -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] mingw-w64 gcc-4.4.4 release?
Hi all, We are sucessfully using mingw-w64-gcc-4.4.1, which turned out to be very stable. Additionally we maintain an ubuntu package archive, which contains many ported C and C++ libraries under https://launchpad.net/~clazzes.org/+archive/ppa Most noteworthy we've managed to build Qt-4.5.3 applications, omniorb-4.1.4 based servers and other fancy things using this approach. Now that gcc-4.4.4 and ubuntu 10.04 lucid lynx are released we'd like to update all theses packages to the newest versions. In order to maintain binary compatibility among the ported libraries it yould be very great to have an official mingw-w64-gcc-4.4.4 release as the foundation for the updated packages. I know of the great work sezero has been untertaking, however the internal structure of his distributions are completely different from mingw-w64-gcc-4.4.1 making it nearly impossible to port our current debian package to his gcc-4.4.4 based builds. Summing up, suach an official mingw-w64-gcc-4.4.4 release would be very benefitial to us, although this might cause some extra hazzles. TIA and best regards, Wolfgang -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 gcc-4.4.4 release?
On 2010-05-04 15:48, Dmitrijs Ledkovs wrote: On 4 May 2010 13:37, Wolfgang Glas wolfgang.g...@ev-i.at wrote: Summing up, suach an official mingw-w64-gcc-4.4.4 release would be very benefitial to us, although this might cause some extra hazzles. Which languages do you need? I have working debian packages for i686 x86_64 crossing to i686 x86_64 w64 using ubuntu gcc-4.4-source and binutils-source as the base and mingw-w64 trunk tip for crt headers. I have gcc,g++,gcj and gfortran and I have working debian packages for gcc-4.4.1 Wher do you host your packages? Maybe we should join our forces in order avoid double work? We maintain a SVN repository for the basic packaging infrastructure and your are welcome to get write access to it. I might as well join any repository on your side, if this solution is more feasible. BTW, why do you use ubuntu gcc-4.4-source and not mingw-w64 published sources? Wolfgang -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 gcc-4.4.4 release?
On 2010-05-04 17:34, Dmitrijs Ledkovs wrote: On 4 May 2010 15:25, Wolfgang Glas wolfgang.g...@ev-i.at wrote: On 2010-05-04 15:48, Dmitrijs Ledkovs wrote: On 4 May 2010 13:37, Wolfgang Glas wolfgang.g...@ev-i.at wrote: Summing up, suach an official mingw-w64-gcc-4.4.4 release would be very benefitial to us, although this might cause some extra hazzles. Which languages do you need? I have working debian packages for i686 x86_64 crossing to i686 x86_64 w64 using ubuntu gcc-4.4-source and binutils-source as the base and mingw-w64 trunk tip for crt headers. I have gcc,g++,gcj and gfortran and I have working debian packages for gcc-4.4.1 Actually I just built the packages as decribed in the mingw-w64 WIKI and therefore, I have a gfortran built alongside. Up to now I did not try the fortran compiler... Just compiled a simple test program fir Win32 and win64 and both binaries are functional ;-) Wher do you host your packages? Maybe we should join our forces in order avoid double work? We maintain a SVN repository for the basic packaging infrastructure and your are welcome to get write access to it. I might as well join any repository on your side, if this solution is more feasible. I don't use SVN generally =) and with your ppa even though it has many softwares build these packages are not policy compliant and I'm intending to take over the debian/ubuntu archives with my packaging ;-) Well, your binutils, mingw-w64-headers and gcc packages look very fine and I don't have any problems with your choice of the underlying source code. Frankly speaking, I'd really like to stick to porting libraries rather than maintaining the compiler and binutils base. So, I'd suggest, that I join your team and make my ported libraries policy compliant and rebase them on your toolchain build. Therefore I kindly beg you to tell me in what respect the packages are non-compliant, so I can address these issues. And hey, isn't all the open source stuff about making things work for the user in a joined effort? BTW, why do you use ubuntu gcc-4.4-source and not mingw-w64 published sources? Otherwise I'll have more resistance getting it included in the archive from security support point of view. No objections here, if the resulting compiler just works and is debian-compliant ;-) Best regards, Wolfgang -- ___ 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] mingw-w64-qt4 packages, binutils fuzz.
JonY schrieb: On 9/14/2009 02:46, Wolfgang Glas wrote: [snip] The mileage up to know is quite mixed, Qt Designer is running well, othe simple Qt examples are crashing by now. For earlier posting I suppose, that these crashes might be caused by bug of the binutils version released together with mingw-w64-src-4.4.0-1. Hi, mingw-w64 is about to release GCC 4.4.2, which contains many needed bugfixes. Hi, AFAIK, a gcc-4.4.2 release of mingw-w64 will take some weeks from now (according to Kai Tietz), so I'd like to help a bit in testing the current CVS version of mingw-w64-headers and newer version of binutils. I was trying to find a download URL for newer binutils, but there seems to be a great confusion about binutils version numbers. The last officially released binutils version is 2.19.1, redhat seems to distribute snapshot with version numbers like 2.19.51. So could somebody please shed more light on the scenery and recommend a last-know-good-for-mingw-w64 binutils source download? Sourceware binutils CVS HEAD is generally stable. Version numbers like 2.20.51 are development snapshots (the HEAD snapshots gets updated daily), while 2.19.1 is a released to the public version. OK, I've found the following recent sourceware binutils packages: binutils-2.19.51.tar.bz22009/09/04 07:4218 057 370 binutils-2.19.90.tar.bz22009/09/10 13:5817 415 613 binutils-2.20.51.tar.bz22009/09/14 07:4118 079 354 Which one should I try in order to get a maximal test coverage for gcc-4.4.2? Will a 2.20.x version needed for mingw-w64-4.4.2 or is 2.20 only needed for a shared libc++ build? Is 2.19.90 nore stable than 2.19.90 ? TIA for guiding me and best regards, Wolfgang -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64-qt4 packages, binutils fuzz.
Kai Tietz schrieb: 2009/9/14 Wolfgang Glas wolfgang.g...@ev-i.at: JonY schrieb: On 9/14/2009 02:46, Wolfgang Glas wrote: [snip] Sourceware binutils CVS HEAD is generally stable. Version numbers like 2.20.51 are development snapshots (the HEAD snapshots gets updated daily), while 2.19.1 is a released to the public version. OK, I've found the following recent sourceware binutils packages: binutils-2.19.51.tar.bz22009/09/04 07:4218 057 370 binutils-2.19.90.tar.bz22009/09/10 13:5817 415 613 binutils-2.20.51.tar.bz22009/09/14 07:4118 079 354 Which one should I try in order to get a maximal test coverage for gcc-4.4.2? Will a 2.20.x version needed for mingw-w64-4.4.2 or is 2.20 only needed for a shared libc++ build? Is 2.19.90 nore stable than 2.19.90 ? to preferred versions of binutils are 2.19.90 and 2.20.x (I assume we will release already with 2.20.x) i Kai, I will then try to augment mingw-w64-gcc-4.4.0-1 with binutils-2.19.90 and current CVS's HEAD of mingw-w64-headers. I will then try to build omniorb/libxml2/qt-4 and give you feedback of my mileage. Does this configuration give you reasonable quality data for you upcoming gcc-4.4.2 based release? Or should I push binutils to 2.20 and try a shared libstdc++ build? Regards, Wolfgang -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64-qt4 packages, binutils fuzz.
Kai Tietz schrieb: 2009/9/14 Wolfgang Glas wolfgang.g...@ev-i.at: Kai Tietz schrieb: 2009/9/14 Wolfgang Glas wolfgang.g...@ev-i.at: JonY schrieb: On 9/14/2009 02:46, Wolfgang Glas wrote: [snip] Sourceware binutils CVS HEAD is generally stable. Version numbers like 2.20.51 are development snapshots (the HEAD snapshots gets updated daily), while 2.19.1 is a released to the public version. OK, I've found the following recent sourceware binutils packages: binutils-2.19.51.tar.bz22009/09/04 07:4218 057 370 binutils-2.19.90.tar.bz22009/09/10 13:5817 415 613 binutils-2.20.51.tar.bz22009/09/14 07:4118 079 354 Which one should I try in order to get a maximal test coverage for gcc-4.4.2? Will a 2.20.x version needed for mingw-w64-4.4.2 or is 2.20 only needed for a shared libc++ build? Is 2.19.90 nore stable than 2.19.90 ? to preferred versions of binutils are 2.19.90 and 2.20.x (I assume we will release already with 2.20.x) i Kai, I will then try to augment mingw-w64-gcc-4.4.0-1 with binutils-2.19.90 and current CVS's HEAD of mingw-w64-headers. I will then try to build omniorb/libxml2/qt-4 and give you feedback of my mileage. Does this configuration give you reasonable quality data for you upcoming gcc-4.4.2 based release? Or should I push binutils to 2.20 and try a shared libstdc++ build? Hi Wolfgang, Well, better build for 4.4.1 instead. This gives us for i?86 better information. The x64 build should be done with 4.4.2 (prerelease), as there were major changes with big impact. As 4.4.2 is nearly stable (some few issues are pending of not that much impact in comparision to 4.4.1), I would say try it with this version better. OK, I will wait for the gcc-4.4-20090915 weekly snapshot, which appears tomorrow and will try to build the whole toolchain together with CVS HEAD of mingw-w64 CRT and headers and binutils-2.20.51. After all this I will give you feedback about the quality of this configuration let's say by Sunday, September 12th. Please expect, that a Qt-4.5.2 build unveils some minor bugs in mingw-w64-headers. From my spotting at CVS HEAD of mingw-w64-headers I expect two or three minor patches, which I will send to you as soon as te whole thing settles down a bit. Regards, Wolfgang -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] mingw-w64-qt4 packages, binutils fuzz.
Hi all, After getting our clazzes.org PPA (https://www.launchpad.net/~clazzes.org/+archive/ppa) seeded with many backported libraries, I was finally able to release a cross-compiled qt-4.5.2 version for win32 and win64. There are a number of patches needed to get the beast compiled, all of these may be found in our svn repository, which may be browsed under http://svn.clazzes.org/svn/mingw-pkg/trunk/mingw-w64-deb The mileage up to know is quite mixed, Qt Designer is running well, othe simple Qt examples are crashing by now. For earlier posting I suppose, that these crashes might be caused by bug of the binutils version released together with mingw-w64-src-4.4.0-1. I was trying to find a download URL for newer binutils, but there seems to be a great confusion about binutils version numbers. The last officially released binutils version is 2.19.1, redhat seems to distribute snapshot with version numbers like 2.19.51. So could somebody please shed more light on the scenery and recommend a last-know-good-for-mingw-w64 binutils source download? Using debian packaging I may easily switch from one binutils version to another and compare the results and will send a report on the stability of the generated packages to the list. TIA and best regards, Wolfgang Glas -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [ANNOUNCE] clazzes.org mingw-w{32, 64} ubuntu packages
Hi all, As summer is fading out I found time to gather all my current porting efforts of open source libraries to mingw-w64 in decent debian packages. The launchpad repository is located at https://www.launchpad.net/~clazzes.org/+archive/ppa where you will find packages of the mingw-w64-4.4.0-1 toolchain together with the following ported open-source libraries targetting Win32 and Win64: - zlib - libpng - gettext/libintl - libxml2 - openssl - libjpeg - omniorb Please let me know about your mileage with the packages so we can fix things as needed an evolve the packages towards a really stable cross-platform development environment. Since my time is limited, any co-workers which come up with new ported libraries and fixes for packages arer very welcome and I will not heistate to open write access to repository for contributors who provide me with valuable additions. Enjoy the packages, Wolfgang -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] cross-compile fail
Matthew Talbert schrieb: Hi Wolfgang, I'm currently building up a debianized cross-compiler toolchain for ubuntu hardy and jaunty. Please consider to use our PPA https://www.launchpad.net/~clazzes.org/+archive/ppa and give us feedback on the toolchain there. I'm currently relying on gcc-4.4.0-1 and will update the packages as needed. Looks promising. Unfortunately, at the moment, I'm trying to create a script that will work on multiple distros, so I still need to figure out how to build this myself. Matthew, You have to download my source deb-packages, unpack them and have a look at debian/rules. There you shuold find all you need to port a package. And never forget to edit changelog. Your are also invited to contribute packages to the PPA ;-) Thanks, I might do that. I'm working with GTK+, and I've been impressed with what OpenSUSE has done with their similar project. It would be great to have as many packages as they do. Having said that, I really don't know much about packaging, so it would be a learning curve for me. Since, GTK+ is heavily autotools based, it should be an easy task to build ported libraries for that. Example packages for this are mingw-w64-libpng and mingw-w64-libxml2. From my experience it is easier to build up a deb-package, because you can try to compile a binary package bedfore you build your source package and send it to a buildbot. lg, Wolfgang -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] cross-compile fail
Andre Heider schrieb: On Tue, Sep 8, 2009 at 8:31 AM, Wolfgang Glaswolfgang.g...@ev-i.at wrote: Hi Matthew, I'm currently building up a debianized cross-compiler toolchain for ubuntu hardy and jaunty. Please consider to use our PPA https://www.launchpad.net/~clazzes.org/+archive/ppa Nice, any plans to add .deb's for karmic? Hi Andre, I have largely automized the upload of the packages. I planned to upload packages for karmic a few days after karmic has been declared stable. Since the cross-compiler is not dependent on any specific operating system facility (it mainly uses libc as runtime dependency), you may very well use jaunty packages under karmic for the time being by adding deb http://ppa.launchpad.net/clazzes.org/ppa/ubuntu jaunty main to sources.list on your karmic installation. Have you already switched to karmic? If, yes, you are a brave man ;-) Please let me know about your mileage with my packages. Maybe I will port some more libraries (libtiff, libmng may be candidates), Qt-4.5.2 is currently in the works, hopefully I will come up with this package in the next days. Regards, Wolfgang -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] gcc-4.4.1 based mingw-w64 release?
Hi all, We appreciate very much the efforts to bring forward the latest and greatest gcc technology to Windows by publishing gcc-4.5 based snapshots ;-) However, since our company is developping Windows software we need to rely on a stable compiler and hence are quite happy with the gcc-4.4 release series for the moment. I've noticed that gcc-4.4.1 has been released quite a while ago, so my question is whether there are plans to release a mingw-w64-4.4.1 tarball in succession to the mingw-w64-4.4.0 tarball. We are really satisfied with the 4.4.0 release and would like to have the upstream bufixes integrated in the stable compiler series at some point in time. If there are no plans and/or no resources to prepare such a tarball, I may as well contribute one. However, I may need some advice on which components I should update. Best regards, Wolfgang -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Further success messages, debian packaging.
Hi all, I recently moved from the 20090307 to the 20090326 snapshot of mingw-w64 and recompiled my whole library stack and finally I managed to get rid of the last few remaining spuriour crashes in 64 bit binaries ;-) Big hands and many thanks to all, who have contributed to this project ;-)) Since there haven't been pushlished any newer snapshots 20090326, I anticipate, that this is related to the gcc-4.4 branch, which has been created on March, 27th and that the next mingw-w64 release we will see is an official gcc-4.4.0 release. For our part, we are using Linux(ubuntu) to cross-compile code for win32 and win64, so we'd like to have debian-packages of all of the mingw-w64 stuff targetting at win32 and win64 as well as debian-packages for all the open source libraries we and others have ported to mingw-w64. I will start creating such debian packages inside a launchpad PPA when gcc-4.4 is available. As this is going to be a mid-sized effort, I invite others to contribute ;-) If someone is interested, please step up, so I can create a new launchpad group and a new group PPA in order to start. As a starting point I'd like to have a copy of the automated build script, which created the snapshot releases. Would it be possible for Kai or some other guy send me the beast vie e-mail? TIA, Wolfgang -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Release policy, relationship to other mingw projects.
NightStrike schrieb:
On Sun, Mar 15, 2009 at 4:14 PM, Wolfgang Glas wolfgang.g...@ev-i.at wrote:
Hi all,
Since we are waiting for gcc-4.4.0 being released by the SC we should take
the
time a think about the way mingw-w64 will be presented to the user once it's
getting more stable. (AFAIK, it *is* already very stable)
Making available nightly snapshots is a fine thing by now, but starting with
gcc-4.4.0 there should be an official mingw-w32 and mingw-w64 release with
releases notes et al.. Otherwise, package maintainers will have a hard time
to
query each user which sends in a bug report for the exact snapshot he or she
is
using.
Given that mingw-w64 is a real improvement about the way the old mingw32
compiler suite is managed, it is not a replacement for all the native Windows
development tools like make, autoconf, sed, awk,... which are provided by
mingw32/msys. So I think that user, who are not interested in
cross-compilation
only, might expect, that the old mingw32/msys tolls will be arranged around
latest and greatest gcc/Windows integration.
Are there any efforts to arrange for such an integration in the near future?
First, I created two new groups:
Toolchains targeting Win64
Toolchains targeting Win32
In each of those groups is a single release, Automated Builds
When gcc 4.4 is released, we will provide an actual release-tested
complete gcc 4.4-based toolchain with a specific binutils version and
a specific mingw-w64/32 version. They will go in this area.
Well, that's very fine ;-) I didn't recognize that Automated Builds is a
subgroup that will be complemented with a release subfolder.
Now, as for a development environment, I have given thought to this.
I would like to be able to provide a complete tarball that contains a
working gnu-ish system. The way that mingw.org packages things is too
confusing for my tastes. However, we have not yet begun to port
things like msys, or to try compiling msys on/for Win64. I personally
feel that the msys environment is sub-par, and if you need that much
in the way of gnu tools, you're better off going with cygwin.
For my part I like the mingw-w64 approach of reducing things to the bare
minimum, which is a compiler plus binutils plus a development environment for
system libraries ver much. And I'm very happy with high-quality cross-compilers
for Linux, because I can now compile my software on a single build machine for
Windows an Linux ;-)
So really, I guess we're open to suggestions for a definite Way Ahead
plan. Perhaps you would like to officially join our project?
Since I'm happy with cross-compilation, I'm not the right one to drive the
development of a Windows-based toolchain. And I have a sever lack of time.
However, thanks for you invitation ;-)
I will try to keep on reporting bugs and providing for testcases as needed.
The main reason for opening this discussion is that I've got the implression,
that there are several small groups (mingw32,cygwin,mingw-w64,fedora mingw) who
are doing very similar work. IMHO it would be very benfitial for the users and
all driving forces behind these projects to get a clear overview of all projects
and to cooperate as much as possible.
E.g, it was a big surprise, that the mingw-w64 is doing such a tremendous work
on a complete x-compilation suite for Win{32,64} and the project is not even
mentioned on well-known websites in the field.
Best regards,
Wolfgang
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] alloca()-Problems, a smoking gun no resolution yet.
Hi all, I've been trying very hard to reduce my alloca() problems and at got stuck with every attempt to isolate the problem. Finally I linked a mildly complex C-program, which crashed before using a handcrafted Makefile and luckily I found out, that the program crashes, when I add a bunch Window's system libraries to the linker command line. (A practice I cowardly copied from another project years ago...) I've uploaded a self-contained (but not small) testcase to our weebserver under http://www.ev-i.at/tmp/mingw_hpgspdf_test.tar.gz The makefile generates two executables: One linked just with the self-generated DLLs and one linked with a long list of windows system libraries. The executable linked with the windows libraries is called hpgspdffile-read-fail.exe and has a different size than the executable hpgspdffile-read.exe linked with just the self-generated libraries. Besides, it has the same runtime dependencies and however it *does* crash right after alloca(), while the other one survives flawlessly. The program reads a PDF-file, interprets it's internal structure and re-serializes the file afterwards. (Should work with any normal PDF-file). This is my debug-session: ** H:\wglas\CC\mingw_hpgspdf_test\bin64gdb-w64 .\hpgspdffile-read-fail.exe GNU gdb 6.7.50.20080109-cvs Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-pc-mingw32... warning: A handler for the OS ABI Cygwin is not built into this configuration of GDB. Attempting to continue with the default i386:x86-64 settings. (gdb) break hpgspdffile.c:1230 Breakpoint 1 at 0x40eead: file hpgspdffile.c, line 1230. (gdb) r H:\wglas\doc\hp\bpl13205.pdf x.pdf Starting program: H:\wglas\CC\mingw_hpgspdf_test\bin64/.\hpgspdffile-read-fail.e xe H:\wglas\doc\hp\bpl13205.pdf x.pdf len=28. value=C:\Program Files (x86)\cdes. prefix=C:\Program Files (x86)\cdes. Opening file H:\wglas\doc\hp\bpl13205.pdf. Reading file H:\wglas\doc\hp\bpl13205.pdf. Breakpoint 1, hpgs_pdf_file_read_xref (pdf=0x3f7720) at hpgspdffile.c:1230 1230hpgspdffile.c: No such file or directory. in hpgspdffile.c (gdb) print tail_data $1 = 0x22fda0 (gdb) print len $2 = (size_t *) 0x22fdb0 (gdb) n Program received signal SIGSEGV, Segmentation fault. 0x07ff7fc52806 in ?? () (gdb) bt #0 0x07ff7fc52806 in ?? () #1 0x07ff7fc4a949 in ?? () #2 0x0003 in ?? () #3 0x0003 in ?? () #4 0x0003 in ?? () #5 0x0033d627 in ?? () #6 0x in ?? () (gdb) q The program is running. Exit anyway? (y or n) y H:\wglas\CC\mingw_hpgspdf_test\bin64 ** Explanation: tail_data is a char-array of size 2048, which has been allocated through alloca(), 'len' is a local variable. The problem her is, that alloca() places tail_data 16 bytes before len, which is far less than the required 2048 bytes... Hopefully, this will bring us one step further in resolving this curious problem. Regards, Wolfgang -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] distraction with gethostbyname with SysWOW64.
FYI,
I've traccked down my problems with running 32bit executables compiled using
mongw-w32-20090307 und Windows Xp x64 (SysWOW64 mode) to a bug in
gethostbyname() in SysWOW64, which is tracked by the forum entry:
http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/521a5524-5a5b-4de1-aec3-e12b93e25dbb/
The attached executable compiled using
i686-pc-mingw32-gcc gethostbynamesample.c -O2 -l ws2_32 -o
bin32/gethostbynamesample.exe
runs under WinXP x86, but crashes under WinXP x64/Server 2003 x64. The bug has
been fixed for Vista x64.
If compiled as a 64bit excutable everything works fine, just as expected ;-)
My question is: Is it possible to put write a workaround for this bug either by
modifying the atrtached test code or by adapting the gcc mingw-w32 toolchain?
TIA,
Wolfgang
#include winsock2.h
#include ws2tcpip.h
#include stdio.h
int main(int argc, char **argv)
{
//-
// Declare and initialize variables
WSADATA wsaData;
int iResult;
DWORD dwError;
int i = 0;
struct hostent *remoteHost;
char *host_name;
struct in_addr addr;
char **pAlias;
// Validate the parameters
if (argc != 2) {
printf(usage: %s ipv4address\n, argv[0]);
printf( or\n);
printf( %s hostname\n, argv[0]);
printf( to return the host\n);
printf( %s 127.0.0.1\n, argv[0]);
printf( to return the IP addresses for a host\n);
printf( %s www.contoso.com\n, argv[0]);
return 1;
}
// Initialize Winsock
iResult = WSAStartup(MAKEWORD(2, 2), wsaData);
if (iResult != 0) {
printf(WSAStartup failed: %d\n, iResult);
return 1;
}
host_name = argv[1];
// If the user input is an alpha name for the host, use gethostbyname()
// If not, get host by addr (assume IPv4)
if (isalpha(host_name[0])) {/* host address is a name */
printf(Calling gethostbyname with %s\n, host_name);
remoteHost = gethostbyname(host_name);
} else {
printf(Calling gethostbyaddr with %s\n, host_name);
addr.s_addr = inet_addr(host_name);
if (addr.s_addr == INADDR_NONE) {
printf(The IPv4 address entered must be a legal address\n);
return 1;
} else
remoteHost = gethostbyaddr((char *) addr, 4, AF_INET);
}
if (remoteHost == NULL) {
dwError = WSAGetLastError();
if (dwError != 0) {
if (dwError == WSAHOST_NOT_FOUND) {
printf(Host not found\n);
return 1;
} else if (dwError == WSANO_DATA) {
printf(No data record found\n);
return 1;
} else {
printf(Function failed with error: %ld\n, dwError);
return 1;
}
}
} else {
printf(Function returned:\n);
printf(\tOfficial name: %s\n, remoteHost-h_name);
for (pAlias = remoteHost-h_aliases; *pAlias != 0; pAlias++) {
printf(\tAlternate name #%d: %s\n, ++i, *pAlias);
}
printf(\tAddress type: );
switch (remoteHost-h_addrtype) {
case AF_INET:
printf(AF_INET\n);
break;
case AF_INET6:
printf(AF_INET6\n);
break;
case AF_NETBIOS:
printf(AF_NETBIOS\n);
break;
default:
printf( %d\n, remoteHost-h_addrtype);
break;
}
printf(\tAddress length: %d\n, remoteHost-h_length);
i = 0;
while (remoteHost-h_addr_list[i] != 0) {
addr.s_addr = *(u_long *) remoteHost-h_addr_list[i++];
printf(\tIP Address #%d: %s\n, i, inet_ntoa(addr));
}
}
return 0;
}
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] distraction with gethostbyname with SysWOW64.
Kai Tietz schrieb: 2009/3/10 Tor Lillqvist t...@iki.fi: My question is: Is it possible to put write a workaround for this bug either by modifying the atrtached test code Use getaddrinfo() instead? Yes, this would be an alternative. I've just seen, that omniORB has an alternative codepath, which uses getaddrinfo(). So I have to recompile using the right #define's and I should get rid of my Pb. At office we ran into the same problem. AFAIK it works on our site, beside that we commonly use it just for the local machine's name (not localhost). The major difference I see between your example and our variant is that we use 2.0 and not 2.2 ( MAKEWORD(2,0); ). Maybe this can help you. Version 2.0 has the same Problem, in fact this is the version used by omniORB-4.1.3 when calling WSAStartup(). The example I posted ist just a paste'n'copy from MSDN, that's why the example rerquests version 2.2 Wolfgang -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
