Bug#678252: Please drop gcc-4.4 build dependency now

2013-04-23 Thread Robie Basak
It has been almost a year since the last comment on this bug. Upstream
still don't appear to support building the embedded ssl library on the
current gcc in a way that works.

Can the decision to build with gcc 4.4 instead of disabling the i386
assembly optimisations now be reconsidered? Perhaps with a view to
making this change when jessie opens?

Note that AFAICT the optimisations are only enabled when __i386__ is
defined, so amd64 has been relying on gcc's optimisation for the
portable C equivalent anyway. I think it's also reasonable to doubt the
usefulness of the assembly that's being used, since it was clearly
designed and compared against an older version of gcc, and using a newer
gcc invalidates any assumptions that the assembly optimisations provide
any performance benefit anyway.

There is a regression risk, but only if the underlying code is broken.
Since the test suite detected the original problem, I think it's
reasonable to consider it to have adequate coverage to manage the risk.

So can we now define TAOCRYPT_DISABLE_X86ASM and drop the use of
gcc-4.4 please?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#678252: [debian-mysql] Bug#678252: Please drop gcc-4.4 build dependency now

2013-04-23 Thread Clint Byrum

On 2013-04-23 05:17, Robie Basak wrote:

It has been almost a year since the last comment on this bug. Upstream
still don't appear to support building the embedded ssl library on the
current gcc in a way that works.

Can the decision to build with gcc 4.4 instead of disabling the i386
assembly optimisations now be reconsidered? Perhaps with a view to
making this change when jessie opens?

Note that AFAICT the optimisations are only enabled when __i386__ is
defined, so amd64 has been relying on gcc's optimisation for the
portable C equivalent anyway. I think it's also reasonable to doubt 
the

usefulness of the assembly that's being used, since it was clearly
designed and compared against an older version of gcc, and using a 
newer
gcc invalidates any assumptions that the assembly optimisations 
provide

any performance benefit anyway.

There is a regression risk, but only if the underlying code is broken.
Since the test suite detected the original problem, I think it's
reasonable to consider it to have adequate coverage to manage the 
risk.


So can we now define TAOCRYPT_DISABLE_X86ASM and drop the use of
gcc-4.4 please?



+1 from me. I have also started working on packing a non-embedded 
cyassl for Jessie, and I hope to link MySQL 5.6 against it. Presumably 
MariaDB can do the same.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org