From: Aaron W. L. <aar...@aa...> - 2009-06-23 06:17:24
|
The MinGW.org team is pleased to offer a binary release of GCC 4.4.0. 1. PREREQUISITES This binary release requires a PC with a 32-bit version of Windows, such as Windows 95, Windows NT 4.0, Windows XP, or better. You will need to have an existing MinGW installation that includes at least the following:-- - binutils 2.13 - mingw-runtime 3.13 - w32api 2.2 2. AVAILABILITY This release is available for download from the following URL. https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=241304 To get a complete GCC distribution, download the 'full' file. It includes the DLL prerequisites GMP, libiconv, MPFR, and support for all languages. Note that you still must have the prerequisites listed above to actually compile anything. gcc-full-4.4.0-mingw32-bin.tar.lzma If you do not want to download the entire compiler, you must download the required gmp, mpfr, and pthreads prerequisites, the 'core' bin and dll packages, plus the 'bin' and 'dll' packages of any other languages that you need. GMP Runtime [REQUIRED] gmp-4.2.4-mingw32-dll.tar.gz libiconv Runtime [REQUIRED] libiconv-1.13-mingw32-dll-2.tar.gz MPFR Runtime [REQUIRED] mpfr-2.4.1-mingw32-dll.tar.gz POSIX Threads for Win32 Runtime [REQUIRED] pthreads-w32-2.8.0-mingw32-dll.tar.gz Core (C) [REQUIRED] gcc-core-4.4.0-mingw32-bin.tar.gz gcc-core-4.4.0-mingw32-dll.tar.gz Ada [OPTIONAL] gcc-ada-4.4.0-mingw32-bin.tar.gz gcc-ada-4.4.0-mingw32-dll.tar.gz C++ [OPTIONAL] gcc-c++-4.4.0-mingw32-bin.tar.gz gcc-c++-4.4.0-mingw32-dll.tar.gz Fortran [OPTIONAL] gcc-fortran-4.4.0-mingw32-bin.tar.gz gcc-fortran-4.4.0-mingw32-dll.tar.gz Java [OPTIONAL] gcc-java-4.4.0-mingw32-bin.tar.gz gcc-java-4.4.0-mingw32-dll.tar.gz Objective-C [OPTIONAL] gcc-objc-4.4.0-mingw32-bin.tar.gz gcc-objc-4.4.0-mingw32-dll.tar.gz Be aware that some archive extracters do not preserve read-only attributes of files. If you are installing the Ada component, please check that the files in the /lib/gcc/mingw32/4.2.1-dw2/adainclude and adalib directories are flagged as read-only. This attribute is necessary to prevent them from being deleted when using gnatclean to clean a project. 3. INSTALLATION INSTRUCTIONS Use an archiver of your choice to extract this package over your existing MinGW installation, which is usually located in c:\mingw. This will replace your old GCC version, if any, as the default compiler. To uninstall or return to your previous version, you can extract the version you want over this version, optionally deleting the old files. Alternately, if you do not want to replace your old installation, you can extract to some other directory of your choosing, and add the bin/ subdirectory to your PATH environment variable. 4. NEW FEATURES SINCE MINGW GCC 3.4 Windows-specific:-- - Shared libgcc: If all modules are linked with -shared-libgcc, exceptions can be thrown across DLL boundaries. Note that this is the default for all languages other than C. - Shared libstdc++: Compile with -D_GLIBCXX_DLL and add -lstdc++_s to your link flags to link against a DLL version of libstdc++. - Zero cost exceptions: New exception model Dwarf only has performance penalty when being thrown. The old model, SJLJ, is no longer available. - Thread local storage support: The __thread keyword is honoured. - Translations into your language! See MINGW\share\locale for a list of codes. Set the LANG environment variable to the code of your preferred language. $ export LANG=es $ gcc gcc.exe: no hay ficheros de entrada In general:-- - New language: Java 1.5, using the Eclipse front end - New language: Objective-C++, intended to bridge C++ and Objective-C code - Improved optimisation: SSA optimisation framework, IPA support, autovectorization of loops, new register allocator, new instruction scheduler, and more - Support for some parts of the upcoming new version of C++ - Support for new IA-32 processors and SIMD instruction sets - Support for TR1 and experimental support for the next C++ standard - Fortran language rewritten to support new standards - Improved debugging information: Dwarf-2 debugging is now the default. Make sure to get the latest GDB version for the best debugging experience. - OpenMP support For more information, see <http://gcc.gnu.org/gcc-4.4/>. 5. GENERAL NOTES - Throwing exceptions through foreign frames Previous versions of GCC would blindly unwind through all foreign frames. If these frames did not have valid unwind information, perhaps because they were written in a language that does not have exceptions, program data structures might be left in an incoherent state, leading to mysterious bugs including data loss and program crashes. From now on, GCC will only unwind through frames if it can be determined that the functions understand exceptions. Currently, functions that use either Dwarf-2 EH or SEH are supported. Unfortunately, in i386 versions of Windows, there is no reliable way for the compiler or runtime unwinder to tell if a function supports unwinding with SEH. Consequently, it is necessary to add the seh_aware decorator to the declarations of foreign SEH functions that exceptions might be thrown through. If you intend to throw exceptions through Windows API callbacks, you will need to add __attribute__((seh_aware)) to the declaration of the corresponding API function. This is only a temporary measure, as a future version of w32api from MinGW.org will have some sort of way of adding this annotation automatically. Note that it is not necessary to add this attribute to the callbacks themselves, or any other function definition that is compiled by GCC; it is only necessary for foreign functions. - Dynamic linking with libgcc_s_dw2-1.dll Dynamic linking with libgcc_s_dw2-1.dll is necessary to throw exceptions between different modules, such as between two DLLs or a DLL and an EXE. Consequently, it is the default for all languages other than C. To disable this dynamic linking, use -static-libgcc. To enable this dynamic linking in C, use -shared-libgcc. 6. KNOWN ISSUES - The Java compiler GCJ is somewhat broken. Compiling with -static-libgcj works better than the default of dynamically linking. - libstdc++_s is only partially implemented. - GRAPHITE is not supported due to various bugs. This is being corrected for the next release. 7. CONTACT INFORMATION Bugs: http://www.mingw.org/bugs.shtml General: mingw-users at http://www.mingw.org/lists.shtml |
From: <t6...@gm...> - 2009-06-23 06:49:01
|
Aaron W. LaFramboise wrote: > The MinGW.org team is pleased to offer a binary release of GCC 4.4.0. > Hi, I can't find the patches for the mingw32-gcc compiler for gcc-4.4.0 official source. As for this file gcc-4.4.0-src.tar.bz2 <http://sourceforge.net/project/downloading.php?group_id=2435&filename=gcc-4.4.0-src.tar.bz2&a=10745416> it is unpatched I suppose? It is not inside gcc-4.4.0-mingw32-src.tar.gz in the src directory there was only some key files ... BTW why not use GMP 4.3.1 as it is the latest release. gmp-4.2.4-src.tar.bz2 |
From: Aaron W. L. <aar...@aa...> - 2009-06-23 16:42:34
|
t6...@gm... wrote: > Aaron W. LaFramboise wrote: >> The MinGW.org team is pleased to offer a binary release of GCC 4.4.0. >> > Hi, > I can't find the patches for the mingw32-gcc compiler > for gcc-4.4.0 official source. Thanks for mentioning this. I've released a package that includes the missing packages, gcc-4.4.0-mingw32-src-2.tar.gz. > BTW why not use GMP 4.3.1 as it is the latest release. > gmp-4.2.4-src.tar.bz2 No reason, other than that it doesn't matter very much for GCC's purposes, and this release was known-good. The next MinGW release will update these dependencies. |
From: <t6...@gm...> - 2009-06-23 23:30:32
|
Aaron W. LaFramboise wrote: > Thanks for mentioning this. I've released a package that includes the > missing packages, gcc-4.4.0-mingw32-src-2.tar.gz. > > Thank you for making this release nice work! I've waited a long time for this. |
From: Vincent T. <vt...@un...> - 2009-06-23 06:53:12
|
Hey, > The MinGW.org team is pleased to offer a binary release of GCC 4.4.0. This is a very good news ! Thank you for that huge work. I have a question, though (i've not tested yet): there are more dependencies than with the previous gcc version. Will some of these dependencies (pthread, etc...) will be needed if I distribute a binary compiled with gcc 4.4.0 ? thank you Vincent Torri > 1. PREREQUISITES > > This binary release requires a PC with a 32-bit version of Windows, such > as Windows 95, Windows NT 4.0, Windows XP, or better. > > You will need to have an existing MinGW installation that includes at > least the following:-- > > - binutils 2.13 > - mingw-runtime 3.13 > - w32api 2.2 > > > > 2. AVAILABILITY > > This release is available for download from the following URL. > > https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=241304 > > To get a complete GCC distribution, download the 'full' file. It includes > the DLL prerequisites GMP, libiconv, MPFR, and support for all languages. > Note that you still must have the prerequisites listed above to actually > compile anything. > > gcc-full-4.4.0-mingw32-bin.tar.lzma > > If you do not want to download the entire compiler, you must download the > required gmp, mpfr, and pthreads prerequisites, the 'core' bin and dll > packages, plus the 'bin' and 'dll' packages of any other languages that you > need. > > GMP Runtime [REQUIRED] > gmp-4.2.4-mingw32-dll.tar.gz > > libiconv Runtime [REQUIRED] > libiconv-1.13-mingw32-dll-2.tar.gz > > MPFR Runtime [REQUIRED] > mpfr-2.4.1-mingw32-dll.tar.gz > > POSIX Threads for Win32 Runtime [REQUIRED] > pthreads-w32-2.8.0-mingw32-dll.tar.gz > > Core (C) [REQUIRED] > gcc-core-4.4.0-mingw32-bin.tar.gz > gcc-core-4.4.0-mingw32-dll.tar.gz > > Ada [OPTIONAL] > gcc-ada-4.4.0-mingw32-bin.tar.gz > gcc-ada-4.4.0-mingw32-dll.tar.gz > > C++ [OPTIONAL] > gcc-c++-4.4.0-mingw32-bin.tar.gz > gcc-c++-4.4.0-mingw32-dll.tar.gz > > Fortran [OPTIONAL] > gcc-fortran-4.4.0-mingw32-bin.tar.gz > gcc-fortran-4.4.0-mingw32-dll.tar.gz > > Java [OPTIONAL] > gcc-java-4.4.0-mingw32-bin.tar.gz > gcc-java-4.4.0-mingw32-dll.tar.gz > > Objective-C [OPTIONAL] > gcc-objc-4.4.0-mingw32-bin.tar.gz > gcc-objc-4.4.0-mingw32-dll.tar.gz > > Be aware that some archive extracters do not preserve read-only > attributes of files. If you are installing the Ada component, please > check that the files in the /lib/gcc/mingw32/4.2.1-dw2/adainclude and > adalib directories are flagged as read-only. This attribute is necessary > to prevent them from being deleted when using gnatclean to clean a > project. > > > > 3. INSTALLATION INSTRUCTIONS > > Use an archiver of your choice to extract this package over your > existing MinGW installation, which is usually located in c:\mingw. > > This will replace your old GCC version, if any, as the default compiler. > > To uninstall or return to your previous version, you can extract the > version you want over this version, optionally deleting the old files. > > Alternately, if you do not want to replace your old installation, you > can extract to some other directory of your choosing, and add the bin/ > subdirectory to your PATH environment variable. > > > > 4. NEW FEATURES SINCE MINGW GCC 3.4 > > Windows-specific:-- > > - Shared libgcc: If all modules are linked with -shared-libgcc, > exceptions can be thrown across DLL boundaries. Note that this is > the default for all languages other than C. > > - Shared libstdc++: Compile with -D_GLIBCXX_DLL and add -lstdc++_s to > your link flags to link against a DLL version of libstdc++. > > - Zero cost exceptions: New exception model Dwarf only has performance > penalty when being thrown. The old model, SJLJ, is no longer > available. > > - Thread local storage support: The __thread keyword is honoured. > > - Translations into your language! See MINGW\share\locale for a list of > codes. Set the LANG environment variable to the code of your > preferred language. > > $ export LANG=es > $ gcc > gcc.exe: no hay ficheros de entrada > > In general:-- > > - New language: Java 1.5, using the Eclipse front end > > - New language: Objective-C++, intended to bridge C++ and Objective-C > code > > - Improved optimisation: SSA optimisation framework, IPA support, > autovectorization of loops, new register allocator, new instruction > scheduler, and more > > - Support for some parts of the upcoming new version of C++ > > - Support for new IA-32 processors and SIMD instruction sets > > - Support for TR1 and experimental support for the next C++ standard > > - Fortran language rewritten to support new standards > > - Improved debugging information: Dwarf-2 debugging is now the default. > Make sure to get the latest GDB version for the best debugging > experience. > > - OpenMP support > > For more information, see <http://gcc.gnu.org/gcc-4.4/>. > > > > 5. GENERAL NOTES > > - Throwing exceptions through foreign frames > > Previous versions of GCC would blindly unwind through all foreign frames. > If these frames did not have valid unwind information, perhaps because > they were written in a language that does not have exceptions, program > data structures might be left in an incoherent state, leading to > mysterious bugs including data loss and program crashes. From now on, > GCC will only unwind through frames if it can be determined that the > functions understand exceptions. Currently, functions that use either > Dwarf-2 EH or SEH are supported. > > Unfortunately, in i386 versions of Windows, there is no reliable way > for the compiler or runtime unwinder to tell if a function supports > unwinding with SEH. Consequently, it is necessary to add the seh_aware > decorator to the declarations of foreign SEH functions that exceptions > might be thrown through. > > If you intend to throw exceptions through Windows API callbacks, you > will need to add __attribute__((seh_aware)) to the declaration of the > corresponding API function. This is only a temporary measure, as a > future version of w32api from MinGW.org will have some sort of way of > adding this annotation automatically. Note that it is not necessary to > add this attribute to the callbacks themselves, or any other function > definition that is compiled by GCC; it is only necessary for foreign > functions. > > - Dynamic linking with libgcc_s_dw2-1.dll > > Dynamic linking with libgcc_s_dw2-1.dll is necessary to throw > exceptions between different modules, such as between two DLLs or a > DLL and an EXE. Consequently, it is the default for all languages > other than C. To disable this dynamic linking, use -static-libgcc. > To enable this dynamic linking in C, use -shared-libgcc. > > > > 6. KNOWN ISSUES > > - The Java compiler GCJ is somewhat broken. Compiling with > -static-libgcj works better than the default of dynamically linking. > > - libstdc++_s is only partially implemented. > > - GRAPHITE is not supported due to various bugs. This is being corrected > for the next release. > > > > 7. CONTACT INFORMATION > > Bugs: http://www.mingw.org/bugs.shtml > General: mingw-users at http://www.mingw.org/lists.shtml > > ------------------------------------------------------------------------------ > Are you an open source citizen? Join us for the Open Source Bridge conference! > Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. > Need another reason to go? 24-hour hacker lounge. Register today! > http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. > > Most annoying abuses are: > 1) Top posting > 2) Thread hijacking > 3) HTML/MIME encoded mail > 4) Improper quoting > 5) Improper trimming > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > > -- > Ce message a été vérifié par MailScanner > pour des virus ou des polluriels et rien de > suspect n'a été trouvé. > Message délivré par le serveur de messagerie de l'Université d'Evry. > > |
From: Aaron W. L. <aar...@aa...> - 2009-06-23 16:24:20
|
Vincent Torri wrote: > This is a very good news ! Thank you for that huge work. I have a > question, though (i've not tested yet): there are more dependencies than > with the previous gcc version. Will some of these dependencies (pthread, > etc...) will be needed if I distribute a binary compiled with gcc 4.4.0 ? GMP, MPFR, and libiconv are only needed by the front ends. pthread is needed by programs compiled with OpenMP enabled. Additionally, some language link with DLL forms of the language runtime by default, which can be disabled if desired. |
From: <t6...@gm...> - 2009-06-23 06:55:27
|
Aaron W. LaFramboise wrote: > The MinGW.org team is pleased to offer a binary release of GCC 4.4.0. > Why isn't there any RC or Beta or testing releases before the release... ? Do C++ DLL work in applications such as VLC and Qt4.5.1 ? |
From: Danny S. <dan...@cl...> - 2009-06-23 07:23:39
|
> The MinGW.org team is pleased to offer a binary release of GCC 4.4.0. > > Thanks |
From: Oliver B. <oli...@ae...> - 2009-06-23 09:39:46
|
Hi MinGW.org Team, First of all, thank you very much for bringing GCC 4.4 to the MinGW community! Great work that's highly appreciated! The following question concerns the cross-compile toolkit: do you also plan to release source-tarballs of the GCC 4.4 family so that the "xscripts" can also benefit from the new release? If so, is there already a preliminary ETA? Thanks, Oliver On 23.06.2009 08:16, Aaron W. LaFramboise wrote: > The MinGW.org team is pleased to offer a binary release of GCC 4.4.0. > > > > 1. PREREQUISITES > > This binary release requires a PC with a 32-bit version of Windows, such > as Windows 95, Windows NT 4.0, Windows XP, or better. > > You will need to have an existing MinGW installation that includes at > least the following:-- > > - binutils 2.13 > - mingw-runtime 3.13 > - w32api 2.2 > > > > 2. AVAILABILITY > > This release is available for download from the following URL. > > https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=241304 > > To get a complete GCC distribution, download the 'full' file. It includes > the DLL prerequisites GMP, libiconv, MPFR, and support for all languages. > Note that you still must have the prerequisites listed above to actually > compile anything. > > gcc-full-4.4.0-mingw32-bin.tar.lzma > > If you do not want to download the entire compiler, you must download the > required gmp, mpfr, and pthreads prerequisites, the 'core' bin and dll > packages, plus the 'bin' and 'dll' packages of any other languages that you > need. > > GMP Runtime [REQUIRED] > gmp-4.2.4-mingw32-dll.tar.gz > > libiconv Runtime [REQUIRED] > libiconv-1.13-mingw32-dll-2.tar.gz > > MPFR Runtime [REQUIRED] > mpfr-2.4.1-mingw32-dll.tar.gz > > POSIX Threads for Win32 Runtime [REQUIRED] > pthreads-w32-2.8.0-mingw32-dll.tar.gz > > Core (C) [REQUIRED] > gcc-core-4.4.0-mingw32-bin.tar.gz > gcc-core-4.4.0-mingw32-dll.tar.gz > > Ada [OPTIONAL] > gcc-ada-4.4.0-mingw32-bin.tar.gz > gcc-ada-4.4.0-mingw32-dll.tar.gz > > C++ [OPTIONAL] > gcc-c++-4.4.0-mingw32-bin.tar.gz > gcc-c++-4.4.0-mingw32-dll.tar.gz > > Fortran [OPTIONAL] > gcc-fortran-4.4.0-mingw32-bin.tar.gz > gcc-fortran-4.4.0-mingw32-dll.tar.gz > > Java [OPTIONAL] > gcc-java-4.4.0-mingw32-bin.tar.gz > gcc-java-4.4.0-mingw32-dll.tar.gz > > Objective-C [OPTIONAL] > gcc-objc-4.4.0-mingw32-bin.tar.gz > gcc-objc-4.4.0-mingw32-dll.tar.gz > > Be aware that some archive extracters do not preserve read-only > attributes of files. If you are installing the Ada component, please > check that the files in the /lib/gcc/mingw32/4.2.1-dw2/adainclude and > adalib directories are flagged as read-only. This attribute is necessary > to prevent them from being deleted when using gnatclean to clean a > project. > > > > 3. INSTALLATION INSTRUCTIONS > > Use an archiver of your choice to extract this package over your > existing MinGW installation, which is usually located in c:\mingw. > > This will replace your old GCC version, if any, as the default compiler. > > To uninstall or return to your previous version, you can extract the > version you want over this version, optionally deleting the old files. > > Alternately, if you do not want to replace your old installation, you > can extract to some other directory of your choosing, and add the bin/ > subdirectory to your PATH environment variable. > > > > 4. NEW FEATURES SINCE MINGW GCC 3.4 > > Windows-specific:-- > > - Shared libgcc: If all modules are linked with -shared-libgcc, > exceptions can be thrown across DLL boundaries. Note that this is > the default for all languages other than C. > > - Shared libstdc++: Compile with -D_GLIBCXX_DLL and add -lstdc++_s to > your link flags to link against a DLL version of libstdc++. > > - Zero cost exceptions: New exception model Dwarf only has performance > penalty when being thrown. The old model, SJLJ, is no longer > available. > > - Thread local storage support: The __thread keyword is honoured. > > - Translations into your language! See MINGW\share\locale for a list of > codes. Set the LANG environment variable to the code of your > preferred language. > > $ export LANG=es > $ gcc > gcc.exe: no hay ficheros de entrada > > In general:-- > > - New language: Java 1.5, using the Eclipse front end > > - New language: Objective-C++, intended to bridge C++ and Objective-C > code > > - Improved optimisation: SSA optimisation framework, IPA support, > autovectorization of loops, new register allocator, new instruction > scheduler, and more > > - Support for some parts of the upcoming new version of C++ > > - Support for new IA-32 processors and SIMD instruction sets > > - Support for TR1 and experimental support for the next C++ standard > > - Fortran language rewritten to support new standards > > - Improved debugging information: Dwarf-2 debugging is now the default. > Make sure to get the latest GDB version for the best debugging > experience. > > - OpenMP support > > For more information, see <http://gcc.gnu.org/gcc-4.4/>. > > > > 5. GENERAL NOTES > > - Throwing exceptions through foreign frames > > Previous versions of GCC would blindly unwind through all foreign frames. > If these frames did not have valid unwind information, perhaps because > they were written in a language that does not have exceptions, program > data structures might be left in an incoherent state, leading to > mysterious bugs including data loss and program crashes. From now on, > GCC will only unwind through frames if it can be determined that the > functions understand exceptions. Currently, functions that use either > Dwarf-2 EH or SEH are supported. > > Unfortunately, in i386 versions of Windows, there is no reliable way > for the compiler or runtime unwinder to tell if a function supports > unwinding with SEH. Consequently, it is necessary to add the seh_aware > decorator to the declarations of foreign SEH functions that exceptions > might be thrown through. > > If you intend to throw exceptions through Windows API callbacks, you > will need to add __attribute__((seh_aware)) to the declaration of the > corresponding API function. This is only a temporary measure, as a > future version of w32api from MinGW.org will have some sort of way of > adding this annotation automatically. Note that it is not necessary to > add this attribute to the callbacks themselves, or any other function > definition that is compiled by GCC; it is only necessary for foreign > functions. > > - Dynamic linking with libgcc_s_dw2-1.dll > > Dynamic linking with libgcc_s_dw2-1.dll is necessary to throw > exceptions between different modules, such as between two DLLs or a > DLL and an EXE. Consequently, it is the default for all languages > other than C. To disable this dynamic linking, use -static-libgcc. > To enable this dynamic linking in C, use -shared-libgcc. > > > > 6. KNOWN ISSUES > > - The Java compiler GCJ is somewhat broken. Compiling with > -static-libgcj works better than the default of dynamically linking. > > - libstdc++_s is only partially implemented. > > - GRAPHITE is not supported due to various bugs. This is being corrected > for the next release. > > > > 7. CONTACT INFORMATION > > Bugs: http://www.mingw.org/bugs.shtml > General: mingw-users at http://www.mingw.org/lists.shtml > > ------------------------------------------------------------------------------ > Are you an open source citizen? Join us for the Open Source Bridge conference! > Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. > Need another reason to go? 24-hour hacker lounge. Register today! > http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. > > Most annoying abuses are: > 1) Top posting > 2) Thread hijacking > 3) HTML/MIME encoded mail > 4) Improper quoting > 5) Improper trimming > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Aaron W. L. <aar...@aa...> - 2009-06-23 16:42:12
|
Oliver Bock wrote: > Hi MinGW.org Team, > > First of all, thank you very much for bringing GCC 4.4 to the MinGW > community! Great work that's highly appreciated! > > The following question concerns the cross-compile toolkit: do you also > plan to release source-tarballs of the GCC 4.4 family so that the > "xscripts" can also benefit from the new release? If so, is there > already a preliminary ETA? You can get the patched sources from the packages gcc-4.4.0-src.tar.gz and gcc-4.4.0-mingw32-src-2.tar.gz. These have not yet been made compatible with the cross-compiler scripts, but its an easy enough modification to make if you compare the two scripts. This will be improved in a future version. |
From: Oliver B. <oli...@ae...> - 2009-06-24 08:19:26
|
Hi Aaron, On 23.06.2009 18:42, Aaron W. LaFramboise wrote: >> The following question concerns the cross-compile toolkit: do you also >> plan to release source-tarballs of the GCC 4.4 family so that the >> "xscripts" can also benefit from the new release? If so, is there >> already a preliminary ETA? > > You can get the patched sources from the packages gcc-4.4.0-src.tar.gz > and gcc-4.4.0-mingw32-src-2.tar.gz. > > These have not yet been made compatible with the cross-compiler scripts, > but its an easy enough modification to make if you compare the two > scripts. This will be improved in a future version. Thanks for your feedback! Which "two scripts" are you referring to? Isn't this a question of having suitable "-src" tarballs for all GCC components like they were made available for gcc-3.4.5-20060117-2? Also, does "future version" mean that there will be no xscripts support for the current 4.4.0 release for the time being? Cheers, Oliver |
From: Aaron W. L. <aar...@aa...> - 2009-06-24 15:55:36
|
Oliver Bock wrote: > Which "two scripts" are you referring to? Isn't this a question of > having suitable "-src" tarballs for all GCC components like they were > made available for gcc-3.4.5-20060117-2? Also, does "future version" > mean that there will be no xscripts support for the current 4.4.0 > release for the time being? To clarify, the xscripts has no support for building 4.4.0 at this time. Presumably only relatively minor modifications are necessary, but no-one has done any such modifications. My priority for this release was getting a native compiler out that would set a good direction for future native compilers. I opted not to use xscripts for this release because it was somewhat orthogonal to what I was trying to accomplish. At the moment, xscripts and the native compiler are maintained separately. Splitting source tarballs is something I'm opposed to at this time unless there's a particularly good reason. We already have a ton of packages, and 4.4.1 will have a few more. For the next release, this is certainly something that should be considered, particularly if its just a matter of naming things the right way. I suspect more than this is required, however. If you'd like to work on this, or even just give me an idea of what you think is required to make this work, I'll look into it. |
From: Oliver B. <oli...@ae...> - 2009-06-24 18:22:53
|
On 24.06.2009 17:55, Aaron W. LaFramboise wrote: > Oliver Bock wrote: > >> Which "two scripts" are you referring to? Isn't this a question of >> having suitable "-src" tarballs for all GCC components like they were >> made available for gcc-3.4.5-20060117-2? Also, does "future version" >> mean that there will be no xscripts support for the current 4.4.0 >> release for the time being? > > To clarify, the xscripts has no support for building 4.4.0 at this time. > Presumably only relatively minor modifications are necessary, but > no-one has done any such modifications. > > My priority for this release was getting a native compiler out that > would set a good direction for future native compilers. I opted not to > use xscripts for this release because it was somewhat orthogonal to what > I was trying to accomplish. At the moment, xscripts and the native > compiler are maintained separately. Ok, understood. I wasn't aware of this and I thought xscripts is some kind of an integral part of MinGW nowadays. > Splitting source tarballs is something I'm opposed to at this time > unless there's a particularly good reason. We already have a ton of > packages, and 4.4.1 will have a few more. > > For the next release, this is certainly something that should be > considered, particularly if its just a matter of naming things the right > way. I suspect more than this is required, however. If you'd like to > work on this, or even just give me an idea of what you think is required > to make this work, I'll look into it. Although I use it regularly -- that's why I'm so eager to see 4.4 support :-) -- and also had to dive into its inner workings once, I'm certainly not an expert in this area. I presume Keith is the one who might be able to shed some light on what it takes to do this. I'm willing to help if needed... Best, Oliver |
From: Aaron W. L. <aar...@aa...> - 2009-06-27 19:07:20
|
leledumbo wrote: > Compiling or running java programs still fail. gcj always ends up in: > > undefined reference to 'WinMain@16' (I can make a C program that calls this > function, and it runs happily). Are you using the --main option to GCJ? See <http://gcc.gnu.org/onlinedocs/gcj/Linking.html> for details. > OTOH gij always says: Thank you for you report. gij does seem to be completely broken. I'll look into this. |
From: leledumbo <lel...@ya...> - 2009-06-29 05:08:08
|
> Are you using the --main option to GCJ? See > <http://gcc.gnu.org/onlinedocs/gcj/Linking.html> for details. Oh, my. I thought it should look for the main method automatically (just like other GCC's frontends). Thanks for the info. -- View this message in context: http://www.nabble.com/MinGW-GCC-4.4.0-Released-tp24160566p24248435.html Sent from the MinGW - User mailing list archive at Nabble.com. |
From: John B. <joh...@ho...> - 2009-06-23 11:50:31
|
Aaron W. LaFramboise wrote: > > The MinGW.org team is pleased to offer a binary release of GCC 4.4.0. > Thank you. > > > 1. PREREQUISITES > > This binary release requires a PC with a 32-bit version of Windows, such > as Windows 95, Windows NT 4.0, Windows XP, or better. > Why? What will happen if I try to run it on 64-bit Vista? Regards, Alias John Brown. _________________________________________________________________ Microsoft brings you a new way to search the web. Try Bing™ now http://www.bing.com?form=MFEHPG&publ=WLHMTAG&crea=TEXT_MFEHPG_Core_tagline_try_bing_1x1 |
From: Aaron W. L. <aar...@aa...> - 2009-06-23 16:38:14
|
John Brown wrote: >> This binary release requires a PC with a 32-bit version of Windows, such >> as Windows 95, Windows NT 4.0, Windows XP, or better. >> > > Why? What will happen if I try to run it on 64-bit Vista? Thanks for catching this. This is an oversight in the release notes. The compiler is also known to work as host and target for XP 64 and Vista 64. It should work for Windows 7 64-bit, but this has not been tested. |
From: asm23 <asm...@gm...> - 2009-06-23 13:08:48
|
Thanks for your hard work!!! |
From: Chris S. <ir0...@gm...> - 2009-06-23 13:10:31
|
> The MinGW.org team is pleased to offer a binary release of GCC 4.4.0. Thank you for all your effort getting this out! > - Shared libgcc: If all modules are linked with -shared-libgcc, > exceptions can be thrown across DLL boundaries. Note that this is > the default for all languages other than C. > > - Shared libstdc++: Compile with -D_GLIBCXX_DLL and add -lstdc++_s to > your link flags to link against a DLL version of libstdc++. I'm attempting to run a test build of my app using the shared libstdc++. I believe I've followed the instructions correctly. I added '-D_GLIBCXX_DLL' to the compile command: (example): mingw32-g++ -W -Wall -Wextra -Werror -pedantic -frtti -fexceptions -D_GLIBCXX_DLL -march=i686 -O2 -D EMERGELIB_EXPORTS -c Shutdown.cpp -o ../.objs/Release/emergeLib/Shutdown.o I also added '-lstdc++_s' to the link command: (example): mingw32-g++ -Wl,--subsystem,windows -shared-libgcc -D_GLIBCXX_DLL -s -shared -o ../bin/emergeLib.dll ../.objs/Release/tinyxml/tinystr.o ../.objs/Release/tinyxml/tinyxml.o ../.objs/Release/tinyxml/tinyxmlerror.o ../.objs/Release/tinyxml/tinyxmlparser.o ../.objs/Release/tinyxml/xmltest.o ../.objs/Release/emergeLib/main.o ../.objs/Release/emergeLib/MsgBox.o ../.objs/Release/emergeLib/Shutdown.o ../.objs/Release/emergeLib/emergeLib.res -lshlwapi -lole32 -luuid -lversion -lpsapi -lwinmm -lpowrprof -lgdi32 -lwtsapi32 -lstdc++_s -Wl,--out-implib,../bin/libemergeLib.a \ -Wl,--output-def,../bin/libemergeLib.def -Wl,--enable-auto-image-base But the compiler complains of duplicate definitions of c++ functions in libstdc++_s.a and libstdc++.a. Did I miss something? Chris -- Chris Sutcliffe http://emergedesktop.org |
From: Chris S. <ir0...@gm...> - 2009-06-23 20:32:33
|
> But the compiler complains of duplicate definitions of c++ functions > in libstdc++_s.a and libstdc++.a. Did I miss something? I found the source of the issue, compiling using -O2 somehow links in libstdc++.a. Is there an equivalent optimization option to use the shared libstdc++_s.a? Chris -- Chris Sutcliffe http://emergedesktop.org |
From: Chris S. <ir0...@gm...> - 2009-06-23 20:45:08
|
> > But the compiler complains of duplicate definitions of c++ functions > > in libstdc++_s.a and libstdc++.a. Did I miss something? > > I found the source of the issue, compiling using -O2 somehow links in > libstdc++.a. Is there an equivalent optimization option to use the > shared libstdc++_s.a? My memory is failing... we discussed this already: http://n2.nabble.com/Shared-libstdc%2B%2B-and--O2-produces-multiple-symbol-definition-error-td2167143.html adding -fno-inline fixes the problem (as was pointed out JonY in the above thread). Is this a bug or is there a reason for it? Chris -- Chris Sutcliffe http://emergedesktop.org |
From: Aaron W. L. <aar...@aa...> - 2009-06-24 01:24:04
|
Chris Sutcliffe wrote: >>> But the compiler complains of duplicate definitions of c++ functions >>> in libstdc++_s.a and libstdc++.a. Did I miss something? >> I found the source of the issue, compiling using -O2 somehow links in >> libstdc++.a. Is there an equivalent optimization option to use the >> shared libstdc++_s.a? > > My memory is failing... we discussed this already: > > http://n2.nabble.com/Shared-libstdc%2B%2B-and--O2-produces-multiple-symbol-definition-error-td2167143.html > > adding -fno-inline fixes the problem (as was pointed out JonY in the > above thread). > > Is this a bug or is there a reason for it? I'm not sure, but I'll look into it. Honestly, shared libstdc++-v3 has quite a few issues, and this will never really be right until someone takes the time to solve the underlying problems carefully and get it into FSF GCC. |
From: jujie z. <zhe...@gm...> - 2009-06-23 14:12:20
|
Really good news,finally I can use gcc4 in windows instead of tdm-gcc. On Tue, Jun 23, 2009 at 2:16 PM, Aaron W. LaFramboise < aar...@aa...> wrote: > The MinGW.org team is pleased to offer a binary release of GCC 4.4.0. > > > > 1. PREREQUISITES > > This binary release requires a PC with a 32-bit version of Windows, such > as Windows 95, Windows NT 4.0, Windows XP, or better. > > You will need to have an existing MinGW installation that includes at > least the following:-- > > - binutils 2.13 > - mingw-runtime 3.13 > - w32api 2.2 > > > > 2. AVAILABILITY > > This release is available for download from the following URL. > > > https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=241304 > > To get a complete GCC distribution, download the 'full' file. It includes > the DLL prerequisites GMP, libiconv, MPFR, and support for all languages. > Note that you still must have the prerequisites listed above to actually > compile anything. > > gcc-full-4.4.0-mingw32-bin.tar.lzma > > If you do not want to download the entire compiler, you must download the > required gmp, mpfr, and pthreads prerequisites, the 'core' bin and dll > packages, plus the 'bin' and 'dll' packages of any other languages that you > need. > > GMP Runtime [REQUIRED] > gmp-4.2.4-mingw32-dll.tar.gz > > libiconv Runtime [REQUIRED] > libiconv-1.13-mingw32-dll-2.tar.gz > > MPFR Runtime [REQUIRED] > mpfr-2.4.1-mingw32-dll.tar.gz > > POSIX Threads for Win32 Runtime [REQUIRED] > pthreads-w32-2.8.0-mingw32-dll.tar.gz > > Core (C) [REQUIRED] > gcc-core-4.4.0-mingw32-bin.tar.gz > gcc-core-4.4.0-mingw32-dll.tar.gz > > Ada [OPTIONAL] > gcc-ada-4.4.0-mingw32-bin.tar.gz > gcc-ada-4.4.0-mingw32-dll.tar.gz > > C++ [OPTIONAL] > gcc-c++-4.4.0-mingw32-bin.tar.gz > gcc-c++-4.4.0-mingw32-dll.tar.gz > > Fortran [OPTIONAL] > gcc-fortran-4.4.0-mingw32-bin.tar.gz > gcc-fortran-4.4.0-mingw32-dll.tar.gz > > Java [OPTIONAL] > gcc-java-4.4.0-mingw32-bin.tar.gz > gcc-java-4.4.0-mingw32-dll.tar.gz > > Objective-C [OPTIONAL] > gcc-objc-4.4.0-mingw32-bin.tar.gz > gcc-objc-4.4.0-mingw32-dll.tar.gz > > Be aware that some archive extracters do not preserve read-only > attributes of files. If you are installing the Ada component, please > check that the files in the /lib/gcc/mingw32/4.2.1-dw2/adainclude and > adalib directories are flagged as read-only. This attribute is necessary > to prevent them from being deleted when using gnatclean to clean a > project. > > > > 3. INSTALLATION INSTRUCTIONS > > Use an archiver of your choice to extract this package over your > existing MinGW installation, which is usually located in c:\mingw. > > This will replace your old GCC version, if any, as the default compiler. > > To uninstall or return to your previous version, you can extract the > version you want over this version, optionally deleting the old files. > > Alternately, if you do not want to replace your old installation, you > can extract to some other directory of your choosing, and add the bin/ > subdirectory to your PATH environment variable. > > > > 4. NEW FEATURES SINCE MINGW GCC 3.4 > > Windows-specific:-- > > - Shared libgcc: If all modules are linked with -shared-libgcc, > exceptions can be thrown across DLL boundaries. Note that this is > the default for all languages other than C. > > - Shared libstdc++: Compile with -D_GLIBCXX_DLL and add -lstdc++_s to > your link flags to link against a DLL version of libstdc++. > > - Zero cost exceptions: New exception model Dwarf only has performance > penalty when being thrown. The old model, SJLJ, is no longer > available. > > - Thread local storage support: The __thread keyword is honoured. > > - Translations into your language! See MINGW\share\locale for a list of > codes. Set the LANG environment variable to the code of your > preferred language. > > $ export LANG=es > $ gcc > gcc.exe: no hay ficheros de entrada > > In general:-- > > - New language: Java 1.5, using the Eclipse front end > > - New language: Objective-C++, intended to bridge C++ and Objective-C > code > > - Improved optimisation: SSA optimisation framework, IPA support, > autovectorization of loops, new register allocator, new instruction > scheduler, and more > > - Support for some parts of the upcoming new version of C++ > > - Support for new IA-32 processors and SIMD instruction sets > > - Support for TR1 and experimental support for the next C++ standard > > - Fortran language rewritten to support new standards > > - Improved debugging information: Dwarf-2 debugging is now the default. > Make sure to get the latest GDB version for the best debugging > experience. > > - OpenMP support > > For more information, see <http://gcc.gnu.org/gcc-4.4/>. > > > > 5. GENERAL NOTES > > - Throwing exceptions through foreign frames > > Previous versions of GCC would blindly unwind through all foreign frames. > If these frames did not have valid unwind information, perhaps because > they were written in a language that does not have exceptions, program > data structures might be left in an incoherent state, leading to > mysterious bugs including data loss and program crashes. From now on, > GCC will only unwind through frames if it can be determined that the > functions understand exceptions. Currently, functions that use either > Dwarf-2 EH or SEH are supported. > > Unfortunately, in i386 versions of Windows, there is no reliable way > for the compiler or runtime unwinder to tell if a function supports > unwinding with SEH. Consequently, it is necessary to add the seh_aware > decorator to the declarations of foreign SEH functions that exceptions > might be thrown through. > > If you intend to throw exceptions through Windows API callbacks, you > will need to add __attribute__((seh_aware)) to the declaration of the > corresponding API function. This is only a temporary measure, as a > future version of w32api from MinGW.org will have some sort of way of > adding this annotation automatically. Note that it is not necessary to > add this attribute to the callbacks themselves, or any other function > definition that is compiled by GCC; it is only necessary for foreign > functions. > > - Dynamic linking with libgcc_s_dw2-1.dll > > Dynamic linking with libgcc_s_dw2-1.dll is necessary to throw > exceptions between different modules, such as between two DLLs or a > DLL and an EXE. Consequently, it is the default for all languages > other than C. To disable this dynamic linking, use -static-libgcc. > To enable this dynamic linking in C, use -shared-libgcc. > > > > 6. KNOWN ISSUES > > - The Java compiler GCJ is somewhat broken. Compiling with > -static-libgcj works better than the default of dynamically linking. > > - libstdc++_s is only partially implemented. > > - GRAPHITE is not supported due to various bugs. This is being corrected > for the next release. > > > > 7. CONTACT INFORMATION > > Bugs: http://www.mingw.org/bugs.shtml > General: mingw-users at http://www.mingw.org/lists.shtml > > > ------------------------------------------------------------------------------ > Are you an open source citizen? Join us for the Open Source Bridge > conference! > Portland, OR, June 17-19. Two days of sessions, one day of unconference: > $250. > Need another reason to go? 24-hour hacker lounge. Register today! > > http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. > > Most annoying abuses are: > 1) Top posting > 2) Thread hijacking > 3) HTML/MIME encoded mail > 4) Improper quoting > 5) Improper trimming > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > -- walking on my way. |
From: Joel C. S. <joe...@gm...> - 2009-06-23 14:43:15
|
Aaron W. LaFramboise wrote: > The MinGW.org team is pleased to offer a binary release of GCC 4.4.0. Congratulations! Any idea when the installer’s mingw.ini will be updated to reflect this? —Joel Salomon |
From: Aaron W. L. <aar...@aa...> - 2009-06-23 16:39:33
|
Joel C. Salomon wrote: > Aaron W. LaFramboise wrote: >> The MinGW.org team is pleased to offer a binary release of GCC 4.4.0. > > Congratulations! > > Any idea when the installer’s mingw.ini will be updated to reflect this? Soon. Once the preliminary problems with this release (As you can see, there have already been a few.), it will be added to the default installer. |