Re: Bug#190399: Bug#246547: amd64 support for glibc 2.3.2.ds1-14

[Andreas Jochens <aj@andaco.de>]

On 04-Jul-08 13:58, Chris Cheney wrote:
> I don't know if there is an actual ABI change but what it accepts is
> more strict so it could break building packages, whether it breaks
> binary compatibility though is another question.

Yes, gcc-3.4 breaks some packackage because it is stricter.

While recompiling my private amd64 archive with gcc-3.4.1 I found the 
following kinds of problems with gcc-3.4 in a (small) number of 
packages:

- semicolons (';') at the end of a function body generate an error 
  e.g. in kbear, kbarcode, myspell

- labels at the end of a compound statement generate an error
  (most prominently a superfluous 'default:' label at the end of a 
  switch statement)
  e.g. in bash, asmem, autofs, avview

- c++ memory allocations for an array of pointers generate an error,
  i.e. 'new (p*)[n]' has to be replaced by 'new p*[n]'
  e.g. in achilles, aleph
  
- some packages declare 'char *malloc();' which generates an error
  and has to be replaced with 'void *malloc();' (or with '' ?)
  e.g. in a2ps, af

I am sure there will be more of those little problems (I still have to 
rebuild a few thousand packages with gcc-3.4.1). These problems 
are easy to fix. They must be fixed anyway because at some point 
debian _will_ switch to gcc-3.4. I do not think that these little 
problems should prevent us from using gcc-3.4 for the amd64 port.

Regarding a possible ABI change, I suspect that there is no 
ABI change from gcc-3.3 to gcc-3.4 until someone points me 
to some kind of official document describing such a change.

Regards
Andreas Jochens