gcc-3.4 upload to unstable
I'm planning the upload of gcc-3.4 packages to unstable this week.
There's one overlapping binary package, which is now built by gcc-3.4,
instead of gcc-3.3: libgcc1 (for all architectures but hppa and m68k).
Checked libgcc1 from 3.4 to export at least all symbols that are
exported from the 3.3 based libgcc1 on all archs, installed and used
the new package on i386, powerpc, mips, mipsel, hppa and m68k without
problems.
Due to the tighened libgcc1 (>= 1:3.4.0-1) shlibs dependency there
will be a delay for moving packages to testing.
In any case a fallback solution in the case of RC reports, gcc-3.4 can
be removed again, and libgcc1 rebuilt from 3.3 sources with an
increased epoch.
Packages can be found at
http://people.debian.org/~doko/gcc-3.3/
http://people.debian.org/~doko/gcc-3.4/
The following notes are added the 3.3 package descriptions:
Package: gcc-3.4
ABIs changed between gcc-3.3 and gcc-3.4 on some architectures (hppa, m68k,
mips, mipsel, sparc). Please read /usr/share/doc/gcc-3.4/README.Debian
for more details.
Package: g++-3.4
ABIs changed between gcc-3.3 and gcc-3.4 on some architectures (hppa, m68k,
mips, mipsel, sparc). Please read /usr/share/doc/gcc-3.4/README.Debian
for more details. Do not mix code compiled with g++-3.3 and g++-3.4.
README.Debian:
Notes on GCC 3.4 in the sarge distribution
------------------------------------------
[package maintainers: when using GCC 3.4 for package building, please
check that your packages still work on platforms with GCC changes
specific for these platforms (hppa, m68k, mips, mipsel, sparc). ]
GCC 3.4 is included in sarge as a newer compiler version, the system
compiler for sarge is GCC 3.3 (the transition to a newer system compiler
is a post sarge issue). Due to some incompatibilities between
3.3 and 3.4 care should be taken, when some code built by both versions
is linked together (most likely linking against a shared library found
in Debian):
- C++ code compiled by g++-3.3 and g++-3.4 is not compatible. Applications
using C++ libraries have to make sure that these libraries are rebuilt.
- On hppa and m68k the exception handling changed from SJLJ to Dwarf2 based
exception handling. This affects C++ and code, which implements it's own
handling. If a library or binary ends up linked against libgcc1 _and_
libgcc2, something probably won't work.
- The implementation of the MIPS ABIs has changed. As a result, the code
generated for certain MIPS targets will not be binary compatible with
earlier releases. See http://gcc.gnu.org/gcc-3.4/mips-abi.html
- The implementation of the SPARC ABIs has changed. As a result, the code
generated will not be binary compatible with earlier releases in certain
cases. See http://gcc.gnu.org/gcc-3.4/sparc-abi.html
Reply to: