Rob.Saccoccio at sas.com
Fri May 29 17:45:48 PDT 2009
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.
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-dev