[Mingw-w64-public] TDM-GCC 4.9.2 released

[John E. / TDM]

Greetings!


=== TDM-GCC 4.9.2 is now available! ===


TDM-GCC is a native binary distribution of the GCC compiler for Windows.
It targets 64-bit Windows (x86_64-w64-mingw32), or 32-bit Windows
(i686-w64-mingw32, i686-pc-mingw32), and is mostly compatible with MinGW
and MinGW-w64. More information and an easy-to-use Windows installer and
updater are available at <http://tdm-gcc.tdragon.net/>.


* With thanks to the MinGW-Builds maintainers for maintaining patch
lists, libatomic and gnatdll are now included.
* Since the 4.8.1 release, TDM-GCC uses POSIX-style threading in the
GCC runtime libraries, based on the "winpthreads" library. It includes
patches to incorporate static winpthreads compilation with a shared
memory region, so your programs won't rely on a pthreads DLL but can
still share thread handles among DLLs and EXEs.
* As always, TDM-GCC includes a few other patches to make it more
"Windows-friendly": default static runtime linkage, full toolchain
relocatability, coexisting 64-bit and 32-bit DLLs, and the
oft-decried-yet-ever-useful shared-memory exception mechanism, among
others. See the README for details.
* Remember to use the "-fno-keep-inline-dllexport" flag to fix memory
usage problems when linking DLLs with a large number of inline functions
(such as wxWidgets).
You can choose between the classic TDM 32-bit edition and the *TDM64*
edition. The TDM64 edition is based on the MinGW-w64 runtime API and the
x86_64-w64-mingw32 GCC target, and can create both 32-bit and 64-bit
code, with the "-m32"/"-m64" compiler flags. Please never mix 32-bit
object files (.o), libraries (.a), DLLs or EXEs with 64-bit versions,
and don't report it as a bug if you inadvertently do.


Alongside the GCC 4.9.2 packages are binary packages of the MinGW-w64
runtime (based on Git v3.x branch, 2011-11-30 /
41cf52b46006658ad17c39ee06ce0adece2ce7bf), binutils (2.24.51 snapshot
20140703), and gdb (7.8.1). TDM-GCC includes support for C, C++,
Fortran, Objective-C/C++, and Ada, as well as support for LTO and the
OpenMP multithreading extensions.


Cheers,
John E. / TDM

[Greg Jung]

Hi John,
If you would indulge my questions, I am intrigued by the advice re:
"-fno-keep-inline-dllexport"
flag
because it mentions wxWidgets which I am trying to incorporate into an
already-large program.
Do you know what problem it addresses, is it needed to unclutter a
namespace? Also regarding
TDM, how many hooks into the windows registry does it maintain? I
un-installed a TDM from a previous system and was dismayed at what seemed
like 2,000 entries in the registry wind-down - am I hallucinating that?

Post by John E. / TDM
Greetings!
=== TDM-GCC 4.9.2 is now available! ===
TDM-GCC is a native binary distribution of the GCC compiler for Windows.
It targets 64-bit Windows (x86_64-w64-mingw32), or 32-bit Windows
(i686-w64-mingw32, i686-pc-mingw32), and is mostly compatible with MinGW
and MinGW-w64. More information and an easy-to-use Windows installer and
updater are available at <http://tdm-gcc.tdragon.net/>.
* With thanks to the MinGW-Builds maintainers for maintaining patch
lists, libatomic and gnatdll are now included.
* Since the 4.8.1 release, TDM-GCC uses POSIX-style threading in the
GCC runtime libraries, based on the "winpthreads" library. It includes
patches to incorporate static winpthreads compilation with a shared
memory region, so your programs won't rely on a pthreads DLL but can
still share thread handles among DLLs and EXEs.
* As always, TDM-GCC includes a few other patches to make it more
"Windows-friendly": default static runtime linkage, full toolchain
relocatability, coexisting 64-bit and 32-bit DLLs, and the
oft-decried-yet-ever-useful shared-memory exception mechanism, among
others. See the README for details.
* Remember to use the "-fno-keep-inline-dllexport" flag to fix memory
usage problems when linking DLLs with a large number of inline functions
(such as wxWidgets).
You can choose between the classic TDM 32-bit edition and the *TDM64*
edition. The TDM64 edition is based on the MinGW-w64 runtime API and the
x86_64-w64-mingw32 GCC target, and can create both 32-bit and 64-bit
code, with the "-m32"/"-m64" compiler flags. Please never mix 32-bit
object files (.o), libraries (.a), DLLs or EXEs with 64-bit versions,
and don't report it as a bug if you inadvertently do.
Alongside the GCC 4.9.2 packages are binary packages of the MinGW-w64
runtime (based on Git v3.x branch, 2011-11-30 /
41cf52b46006658ad17c39ee06ce0adece2ce7bf), binutils (2.24.51 snapshot
20140703), and gdb (7.8.1). TDM-GCC includes support for C, C++,
Fortran, Objective-C/C++, and Ada, as well as support for LTO and the
OpenMP multithreading extensions.
Cheers,
John E. / TDM
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Mingw-w64-public mailing list
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[K. Frank]

Hi Greg!

I can attempt tp answer your question about
-fno-keep-inline-dllexport.

Post by Greg Jung
Hi John,
"-fno-keep-inline-dllexport" flag
because it mentions wxWidgets which I am trying to incorporate into an
already-large program.
Do you know what problem it addresses, is it needed to unclutter a
namespace?

I've used -fno-keep-inline-dllexport when building Qt with mingw-w64.

The issue was that I would run out of memory when linking QtGui.dll
(or maybe QtCore.dll or maybe both). The link process would use
in excess of 3 GB. Running the build with -fno-keep-inline-dllexport
made in possible for me to build Qt on a 4 GB machine. Linking the
dll was still memory intensive, but less. I think when using
-fno-keep-inline-dllexport the linking step took 2+ GB of memory.

Post by Greg Jung
From John's comment I assume something similar is going on with

wxWidgets.


Good luck.


K. Frank

Post by Greg Jung
...

Post by John E. / TDM
Greetings!
=== TDM-GCC 4.9.2 is now available! ===
...
* Remember to use the "-fno-keep-inline-dllexport" flag to fix memory
usage problems when linking DLLs with a large number of inline functions
(such as wxWidgets).
...
Cheers,
John E. / TDM

[John E. / TDM]

Post by Greg Jung
Hi John,
"-fno-keep-inline-dllexport" flag
because it mentions wxWidgets which I am trying to incorporate into an
already-large program.
Do you know what problem it addresses, is it needed to unclutter a
namespace?

Hi Greg,

GCC versions before 4.5 didn't emit class member functions into DLLs if
they were declared with the "inline" keyword. This tended not to be a
problem, because their full definition is available and inlinable to any
user of the class. But as of 4.5 GCC was changed to match Microsoft
Visual C/C++ behavior by also emitting said functions into the DLL.

The more inline class member functions, the more memory it takes to link
the DLL. wxWidgets grew big enough that when the 4.5 change came around,
suddenly there were too many inline class member functions to fit in
link-time memory, and the linker would fail.

The "-fno-keep-inline-dllexport" option reverts to pre-4.5 behavior by
not emitting inline class member functions into a DLL, allowing software
like wxWidgets (monolithic) to link successfully. The only downsides to
using it are that it breaks Microsoft compatibility (almost always not a
problem with C++), and that you can't take the address in the DLL of one
of said functions (which you shouldn't be doing anyway for inlines).

Post by Greg Jung
Also regarding
TDM, how many hooks into the windows registry does it maintain? I
un-installed a TDM from a previous system and was dismayed at what
seemed like 2,000 entries in the registry wind-down - am I
hallucinating that?

You are. The TDM-GCC installer intentionally avoids the registry like
the plague. All is done through file magic. :)

-John E. / TDM

[Ruben Van Boxem]

Post by John E. / TDM

Post by Greg Jung
Hi John,
"-fno-keep-inline-dllexport" flag
because it mentions wxWidgets which I am trying to incorporate into an
already-large program.
Do you know what problem it addresses, is it needed to unclutter a
namespace?

Hi Greg,
GCC versions before 4.5 didn't emit class member functions into DLLs if
they were declared with the "inline" keyword. This tended not to be a
problem, because their full definition is available and inlinable to any
user of the class. But as of 4.5 GCC was changed to match Microsoft
Visual C/C++ behavior by also emitting said functions into the DLL.
The more inline class member functions, the more memory it takes to link
the DLL. wxWidgets grew big enough that when the 4.5 change came around,
suddenly there were too many inline class member functions to fit in
link-time memory, and the linker would fail.
The "-fno-keep-inline-dllexport" option reverts to pre-4.5 behavior by
not emitting inline class member functions into a DLL, allowing software
like wxWidgets (monolithic) to link successfully. The only downsides to
using it are that it breaks Microsoft compatibility (almost always not a
problem with C++), and that you can't take the address in the DLL of one
of said functions (which you shouldn't be doing anyway for inlines).

In my never-ending war on misconceptions regarding C++:
1. inline does not tell your compiler to inline. It is merely a hint and
the fact that some compilers take it as a serious hint is a coincidence.
Nothing in the C or C++ language says there is even the slightest
guarantee. The point of inline is to be able to write inline definitions of
functions, and respect the One Definition Rule. But you knew that already I
suppose ;-)
2. There is absolutely no problem in taking the address of an inline
function. It is very legal. See for example
http://stackoverflow.com/q/3318322/256138
3. I do believe this compiler option makes GCC behave in a non-standard
way, but I haven't checked that myself.

Nevertheless, since ld is too inefficient, this option was necessary to
make it work for stuff like wxWidgets (Qt also added the option to its
build).

Cheers,

Ruben

Post by John E. / TDM

Post by Greg Jung
Also regarding
TDM, how many hooks into the windows registry does it maintain? I
un-installed a TDM from a previous system and was dismayed at what
seemed like 2,000 entries in the registry wind-down - am I
hallucinating that?

You are. The TDM-GCC installer intentionally avoids the registry like
the plague. All is done through file magic. :)
-John E. / TDM
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Mingw-w64-public mailing list
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Massimo Belgrano]

Post by John E. / TDM
Greetings!
=== TDM-GCC 4.9.2 is now available! ===

Nice see tdm reborn
How many mingw version exist for windows ?
wich are the differences?

[John E. / TDM]

Post by Massimo Belgrano
Nice see tdm reborn
How many mingw version exist for windows ?
wich are the differences?

Too many to list for you here. I'll just stick with the ones you're
likely to hear about on this mailing list:

* MinGW-Builds, the official toolchains of the MinGW-w64 project.
<https://sourceforge.net/projects/mingw-w64/files/> (look for
mingw-builds under "Personal builds")

* Win-builds, a distribution that includes a lot of available library
packages.
<http://win-builds.org/>

* TDM-GCC, native Windows toolchains with extra patches that make GCC
more Windows-friendly but in some cases incompatible with other
distributions.
<http://tdm-gcc.tdragon.net/>

* MinGW, the original 32-bit-only project that MinGW-w64 forked from.
<http://www.mingw.org/>

Again, there are quite a few others out there as well, but you're not
likely to hear about them on this list.

-John E. / TDM

[Ruben Van Boxem]

Post by John E. / TDM

Post by Massimo Belgrano
Nice see tdm reborn
How many mingw version exist for windows ?
wich are the differences?

Too many to list for you here. I'll just stick with the ones you're
* MinGW-Builds, the official toolchains of the MinGW-w64 project.
<https://sourceforge.net/projects/mingw-w64/files/> (look for
mingw-builds under "Personal builds")
* Win-builds, a distribution that includes a lot of available library
packages.
<http://win-builds.org/>
* TDM-GCC, native Windows toolchains with extra patches that make GCC
more Windows-friendly but in some cases incompatible with other
distributions.
<http://tdm-gcc.tdragon.net/>
* MinGW, the original 32-bit-only project that MinGW-w64 forked from.
<http://www.mingw.org/>
Again, there are quite a few others out there as well, but you're not
likely to hear about them on this list.

You forgot about MSYS2, of which the developers read this list as well.
It has an extensive repository linux-style of prebuilt binary packages,
which can easily be installed from a Unix shell commandline. I believe the
toolhchains are quite similar to the MinGW-Builds ones.

Ruben