__stack_chk_fail@@GLIBC_2.4 dependency

[Rob Saccoccio]

Thanks for the quick reply Martin.

I figured it out (as is often the case once I post for help ;).

The build links statically against stdc++ and that was built with stack protection.  Linking stdc++ dynamically eliminated the dependency on __stack_chk_fail.

Two new()s and a delete() are being picked up from stdc++.  Anyone have a guess at the badness of making these calls dynamic?

My stuff spends most of its time in loops crunching numbers so I don't expect it to be too big deal - at least for the work I need to complete this week.

Rob



From: Martin Buchholz [mailto:martinrb at google.com]
Sent: Friday, May 29, 2009 7:38 PM
To: Rob Saccoccio
Cc: hotspot-dev at openjdk.java.net
Subject: Re: __stack_chk_fail@@GLIBC_2.4 dependency

My standard recommendation is to build on the oldest version of a platform
that you intend to support at runtime.  For the particular case of linux,
I recommend building on Ubuntu dapper or equivalent system with glibc 2.3.x.

Martin
On Fri, May 29, 2009 at 12:06, Rob Saccoccio <Rob.Saccoccio at sas.com<mailto:Rob.Saccoccio at sas.com>> wrote:
I'm building hotspot on X86_64 Fedora 10 with gcc 4.3.2.  The resulting libjvm.so has a dependency on __stack_chk_fail@@GLIBC_2.4.  This is fine until I try to move it to a linux box that only has glibc 2.3.4.

Building with "-fno-stack-protector -U_FORTIFY_SOURCE" doesn't eliminate the dependency and apbuild didn't help either.

I don't know where the dependency is coming from.

Any help would be most welcome.

Rob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090529/cbe7091e/attachment.html