On 30 Nov, Peter kovacs wrote:
> The bug mentioned is referring to a gcc bug in 4.2.x. The bugtrackerlink 
> claims it is fixed in 4.3.x
> Do we need to keep these workarounds?
> Maybe we can drop this all together. Would raise maintainability in general.
> Who uses 4.2.x compilers?

RHEL / CentOS 5 uses 4.1.x.  RHEL / CentOS 6 uses 4.4.x.  Versions of
FreeBSD without clang use 4.2.1 as the system compiler, but the FreeBSD
port brought in a newer version of GCC in that case.

There are a whole bunch of these compiler bug workarounds in the
makefiles, and many of them are not well documented.  It would be nice
to yank them out, but that would require a lot of testing so that we
don't revive old bugs.

The dmake build has $(CCNUMVER), which encodes the compiler version so
that it is able to enable these workarounds when building with a broken
compiler.  Unfortunately, $(CCNUMVER) is not available on the gbuild
side.  That's why the FreeBSD port includes a whole bunch of patches
that I haven't upstreamed. The FreeBSD port is able to conditionally
apply the patches when it detects it is using certain compiler versions.

This new optimization override mechanism should make maintenance easier
since it only requires making a change to the .mk file in one place. The
old method requires two sets of edits per workaround.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Reply via email to