This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[ANNOUNCEMENT] Updated: mingw-gcc-{core,g++,fortran,objc}-4.7.3-1; NEW: mingw-gcc-ada-4.7.3-1


The mingw-gcc packages provide the GNU Compiler Collection, configured
as a cross compiler for the MinGW (that is, i686-pc-mingw32) target.
The following languages are supported:
  C              mingw-gcc-core
  C++            mingw-gcc-g++
  Fortran        mingw-gcc-fortran
  ObjC/ObjC++    mingw-gcc-objc
  Ada            mingw-gcc-ada

WARNING: ABI BREAKAGE!!! (See below).

Changes since 4.5.1-2
=====================
* Updated to lastest in 4.7.x series because 4.7.2 has an ICE during
  build on cygwin64.
* Rely on cygport to autogenerate setup.hints
* x86 only: added Ada compiler & libs
  NOTE: x86_64 version does not have Ada, because cygwin64's native
  gcc does not yet provide it, and a native Ada is required to build
  a cross-Ada.)
* First cygwin64 release
* x86_64 only: added debuginfo package

* =============== ABI BREAKAGE ==================
  The C and C++ ABI changed in GCC 4.7.0, which means in general you
  can't link together binaries compiled with this version of the
  compiler and with versions before GCC 4.7.0. In particular:

  * The option -mms-bitfields is enabled by default, which means the
    bitfield layout follows the convention of the Microsoft compiler.

  * C++ class-member functions now follow the __thiscall calling
    convention.

  * The compiler now assumes that the caller pops the stack for the
    implicit arguments pointing to an aggregate return value. This
    affects functions returning structs by value, like the complex
    math type.

* New features: See http://gcc.gnu.org/gcc-4.7/changes.html

* Unless the -fno-keep-inline-dllexport compiler flag is given, inline
  functions decorated with __declspec(dllexport) are always generated
  and included in object files. This also applies to methods defined in
  classes decorated with __declspec(dllexport).

  This may cause a general increase in object size, since many copies of
  dllexport'd inline function and methods end up in object files.

  To avoid this, do:

  1) Compile all sources with -fno-keep-inline-dllexport.

  2) Compile a separate dummy source file, that includes all headers, with
  -fkeep-inline-dllexport.

  This will generate all dllexported inline methods
  and functions, just once. The resulting DLL size should not be affected,
  but the object size and the link time should be reduced.

* 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. To disable this, use
  -static-libgcc.

* Shared libstdc++: By default, C++ modules are linked with a DLL version
  of libstdc++. To use the static version, use the -static-libstdc++ flag.
  Note: When building and using DLLs, it is best in general not to use
  static libraries, to avoid the issue of having multiple copies of shared
  data. This applies to static libstdc++ as well.
 
**************
*** NOTE 1 ***
**************
This cross compiler is intended to be compatible with the MinGW.org
(native) win32 gcc.  As such, it is configured with the following
options:

        --disable-multilib
        --disable-win32-registry
        --enable-languages=c,c++,${ARCH_i686+ada,}fortran,objc,obj-c++
        --enable-libgomp
        --disable-sjlj-exceptions
        --enable-libstdcxx-debug
	--disable-build-poststage1-with-cxx
        --enable-version-specific-runtime-libs
	--enable-decimal-float=bid 
        --with-dwarf2
        --disable-werror
        --enable-lto

Most importantly, the use of --disable-sjlj-exceptions means that our
MinGW cross compiler (and MinGW.org's "native" compiler) use dw2
exception handling, rather than sjlj.  MOST other platforms' mingw
cross compilers (such as Fedora or Mandriva) are (now) based on the
mingw64 compiler, and therefore use sjlj instead. Thus, products
generated using those cross compilers are not compatible with
MinGW.org's compiler, while those generated using this toolchain
compiler ARE compatible.  However, the downside is that maintaining
compatibility with MinGW.org means we are INcompatible with Fedora and
Mandriva (etc) mingw cross compilers; for that, rely on cygwin's
mingw64-based toolchains.

**************
*** NOTE 2 ***
**************
What's with all the cross compilers? Cygwin now has

  1. mingw-*          (that is, i686-pc-mingw32-*) stuff
  2. mingw64-i686-*   (that is, i686-w64-mingw32-*) stuff
  3. mingw64-x86_64-* (that is, x86_64-w64-mingw32-*) stuff

Well, all three provide gcc.  However, #2 and #3 use runtime libraries,
Win32 API import libraries, and Win32 API header files developed by the
mingw64.sf.net project (which as of late 2012 are also used by the
native cygwin compiler).  #3 uses the Win32 API import libraries and
header files developed by both cygwin and the mingw.org project jointly
(and, prior to 2012, were used by cygwin itself). They also differ
in which threading library is used "underneath the hood", and several
other ABI-changing ways (--enable-fully-dynamic-string in the mingw64
versions, for instance).   

Obviously, #3 supports 64bit targets, while #1 and #2 do not.

Finally, the mingw-i686 compiler uses dw2 exception handling. This tends
to be faster ('zero-cost') than the sjlj exception handling used by #2
and #3.  MinGW.org hopes that this will allow to provide Java and Ada
environments that are NOT extremely slow -- but as of yet, mingw.org's
compilers do not support Java.  Once they do...our MinGW (i686-pc-mingw32)
cross compiler will join them in supporting those languages.  OTOH, sjlj
is a requirement if you wish to catch exceptions that unwind through
'foreign frames' -- that is, you pass a callback function to a Win32 API
function, and expect to catch any exceptions it may throw, even though
those exceptions must unwind "through" the Win32 API (i.e. "foreign")
frame.  So, there are advantages and drawbacks to each approach:
mingw64.sf chose one way, MinGW.org chose the other.

                   mingw.org      mingw64,i686    mingw64,x86_64
	           ===============================================
bits               32             32              64
threading          Pthreads-W32   winpthreads     winpthreads
exceptions         dw2            sjlj            sjlj             
w32api-provenance  mingw.org      mingw64.sf      mingw64.sf
crt-provenance     mingw.org      mingw64.sf      mingw64.sf

Note that libraries compiled by one of these compilers are generally
not usable by any of the others.

-- 
Charles Wilson

====================================================================

To update your installation, click on the "Install Cygwin now" link
on the http://cygwin.com/ web page.  This downloads setup.exe to
your system.  Then, run setup and answer all of the questions.

              *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]