On Wed, Aug 10, 2011 at 7:39 PM, David Chapman <dcchapman_at_acm.org> wrote:
> On 8/10/2011 4:12 PM, michael_rytting_at_agilent.com wrote:
>>
>> It is set to 1
>>
>> On Aug 10, 2011, at 3:51 PM, "Philip Martin"<philip.martin_at_wandisco.com>
>> wrote:
>>
>>> <michael_rytting_at_agilent.com> writes:
>>>
>>>> If I disable optimizations by doing "make CFLAGS=-O0" the program no
>>>> longer crashes.
>>>
>>> That suggests it could be a compiler bug.
>
> Sorry to jump in so late, but I had significant problems with optimization
> for 64-bit executables under CentOS 4.x. If you can't upgrade, I suggest
> dialing down the optimization flags. I had to drop from -O3 to -O2 so that
> Crypto++ 5.5.2 would run, for example. At some point I could drop support
> for RHEL/CentOS 4.x from my client's products and try going back to -O3, but
> the required testing hasn't been real high on the priority list.
>
> Assuming the SVN configuration scripts can distinguish between the releases,
> I suspect that changing the default optimization flags for RHEL 4.x will be
> simpler than trying to fix the new UTF-8 code. Have you tried intermediate
> levels of optimization? We went to production with -O2, so it's not as if
> all 64-bit optimizations were broken.
That kind of manipulation would normally be done by setting "CFLAGS"
in the the RPM packaging's .spec files. You may notice that Red Hat
gave up on backporting contemporary subversion releases *years* ago,
and even RPMforge (to which I contribute on this) is only now about
to have 1.6.17 on RHEL 5, because I'm personally testing it.
If you've got RHEL 4 or CentOS 4 or whatever environments to test
with, you're quite welcome to my notes. I don't personally care to
spend unpaid development effort on such an old release, especially
when RHEL 6 is out and active and far more compatible.
Received on 2011-08-11 07:42:21 CEST