Debian Developers - gcc-3.4 upload to unstable

Author

gcc-3.4 upload to unstable

Matthias Klose

2004-07-15, 2:51 am

[sent to debian-release earlier this week]

I'm planning the upload of gcc-3.4 packages to unstable this weekend.
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.

Someone reported trouble with kernel compilation, but I never could
reproduce it nor got I more info. See #255127. I'm running 3.4
compiled kernels on powerpc and ix86.

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.

No comittment, when and if gcc-3.4 will become the default compiler.
The default compiler will not change for sarge on architectures
currently in testing.

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.
The C++ ABI version changed from 102 to 1003.

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.
The ABI version changed from 102 to 1003.

- 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

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Russell Coker

2004-07-15, 2:51 am

On Thu, 15 Jul 2004 17:17, Matthias Klose <doko@cs.tu-berlin.de> wrote:
> [sent to debian-release earlier this week]
>
> I'm planning the upload of gcc-3.4 packages to unstable this weekend.
> 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).

Would it be possible to have SSP enabled in GCC 3.4? It seems that SSP has
been tested as much as it can be without being uploaded to unstable (and
passed all such tests). Also as GCC 3.4 is likely to be in a test state for
quite some time with most people using 3.3 it would be a good time to
introduce a significant new feature.

--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Falk Hueffner

2004-07-15, 7:51 am

Russell Coker <russell@coker.com.au> writes:

> Would it be possible to have SSP enabled in GCC 3.4? It seems that
> SSP has been tested as much as it can be without being uploaded to
> unstable (and passed all such tests).

I would much prefer such an invasive patch to enter Debian from
upstream. I can't however see any attempt for this patch to be
submitted to the gcc project; there doesn't even seem to be a version
for CVS mainline. This could be a pain in the long run. Is there
reason to believe this will change?

--
Falk

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Russell Coker

2004-07-15, 7:51 am

On Thu, 15 Jul 2004 18:42, Falk Hueffner
<hueffner@informatik.uni-tuebingen.de> wrote:
> Russell Coker <russell@coker.com.au> writes:
>
> I would much prefer such an invasive patch to enter Debian from
> upstream. I can't however see any attempt for this patch to be
> submitted to the gcc project; there doesn't even seem to be a version
> for CVS mainline. This could be a pain in the long run. Is there
> reason to believe this will change?

Quite often there is a catch-22 situation where upstream doesn't accept a
significant patch because it requires more testing than they have time for,
and distributions don't accept it because the upstream hasn't done so. Both
the distributions and the upstream wait for each other and nothing happens.

Currently Gentoo is the only serious distribution that's doing SSP. If we get
more distributions using it then we get more support, testing, and debugging
for it and increase the chance of it being accepted upstream.

--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Steve Kemp

2004-07-15, 7:51 am

On Thu, Jul 15, 2004 at 07:40:37PM +1000, Russell Coker wrote:

> Quite often there is a catch-22 situation where upstream doesn't accept a
> significant patch because it requires more testing than they have time for,
> and distributions don't accept it because the upstream hasn't done so. Both
> the distributions and the upstream wait for each other and nothing happens.

That's almost certainly true in this case given the wide number of
platforms that GCC is released upon.

> Currently Gentoo is the only serious distribution that's doing SSP.

Adamantix is also using it globally, which I think counts as a
serious distribution!

> If we get more distributions using it then we get more support,
> testing, and debugging for it and increase the chance of it being
> accepted upstream.

Agreed. Enabling it on just a couple of architectures might be
a good compromise, say x86 only. Assuming that works out OK then
alpha, sparc, etc, could be enabled afterwards.

Steve
-

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Falk Hueffner

2004-07-15, 7:51 am

Russell Coker <russell@coker.com.au> writes:

> On Thu, 15 Jul 2004 18:42, Falk Hueffner
> <hueffner@informatik.uni-tuebingen.de> wrote:
>
> Quite often there is a catch-22 situation where upstream doesn't
> accept a significant patch because it requires more testing than
> they have time for, and distributions don't accept it because the
> upstream hasn't done so.

It's quite unusual for gcc to reject a patch on the grounds that it
hasn't received enough public testing. Usually, the patch conforming
to the coding standard and passing the regression tests suffices. So
I'd really recommend retrying to submit it.

> Currently Gentoo is the only serious distribution that's doing SSP.
> If we get more distributions using it then we get more support,
> testing, and debugging for it and increase the chance of it being
> accepted upstream.

I don't think so. There's no precedence for anything like that with
the gcc project, AFAIK.

--
Falk

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Matthias Klose

2004-07-16, 2:50 am

Russell Coker writes:
> On Thu, 15 Jul 2004 18:42, Falk Hueffner
> <hueffner@informatik.uni-tuebingen.de> wrote:
>
> Quite often there is a catch-22 situation where upstream doesn't accept a
> significant patch because it requires more testing than they have time for,
> and distributions don't accept it because the upstream hasn't done so. Both
> the distributions and the upstream wait for each other and nothing happens.
>
> Currently Gentoo is the only serious distribution that's doing SSP. If we get
> more distributions using it then we get more support, testing, and debugging
> for it and increase the chance of it being accepted upstream.

Agreeing here with Falk. As long as it's not supported in the HEAD
branch, it's not an option.

I'm CCing Hiroaki Etoh on the question if this patch has been
submitted.

Matthias

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Florian Weimer

2004-07-16, 2:50 am

* Russell Coker:

> On Thu, 15 Jul 2004 17:17, Matthias Klose <doko@cs.tu-berlin.de> wrote:
>
> Would it be possible to have SSP enabled in GCC 3.4?

Upstream has already decided to support mudflap in GCC 3.5, which is
even more far-reaching than SSP.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Russell Coker

2004-07-16, 7:51 am

On Fri, 16 Jul 2004 17:46, Florian Weimer <fw@deneb.enyo.de> wrote:
> * Russell Coker:
>
> Upstream has already decided to support mudflap in GCC 3.5, which is
> even more far-reaching than SSP.

Sounds great! Given that GCC 3.5 may not be released for some time, is there
any chance of getting a back-port of mudflap to GCC 3.4?

--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Florian Weimer

2004-07-16, 7:51 am

* Russell Coker:

>
> Sounds great! Given that GCC 3.5 may not be released for some time, is there
> any chance of getting a back-port of mudflap to GCC 3.4?

mudflap depends on tree-ssa, which is a major new component of GCC
3.5. A backport would be roughly equivalent to GCC 3.5.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Falk Hueffner

2004-07-16, 5:54 pm

Florian Weimer <fw@deneb.enyo.de> writes:

> Upstream has already decided to support mudflap in GCC 3.5, which is
> even more far-reaching than SSP.

I'm not sure whether all users of SSP would he happy with mudflap as a
replacement. It has a different focus; it was designed as debugging
tool. For example it probably incurs a much larger performance
overhead, since basically every pointer dereference goes through a
hash table.

--
Falk

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org