Re: glibc-2.4 __stack_chk_guard/__pointer_chk_guard

[Hamish Greig <hgreig at bigpond dot net dot au>]

On Tuesday 07 March 2006 20:47, Roland McGrath wrote:
> There is indeed no present problem.  The linker behavior does the right
> thing implicitly.  That right thing is a potential gotcha for accidental
> changes in the future.  i.e., if you do introduce the symbol in the future
> on some configuration, then you need to make sure that it gets into a newer
> version set so that configuration's ABI version dependencies work right.
> But uglifying the sources further to avoid the symbol appearing in the
> version script is no less error-prone.  Instead, we rely on checking the
> resultant dynamic symbol lists to watch out for such stray symbols.

Building glibc-2.4 with gcc-4.1 I found two things that I thought might be 
related to this. Apologies if I am mistaken.

gcc-4.1 checks if glibc supports ssp and if yes, doesn't add -lssp* to the 
fstack-protector specs. So nscd fails to build when gcc has been built 
against glibc2.4, unless I add -lssp to the nscd Makefile rules or manually 
change the gcc's specs.

The second thing I noticed is when I specify -disable-ssp in gcc's configure 
nothing on my system exports __stack_ghk_guard (normally in libssp and 
libssp_nonshared), and compiling nscd  fails unless I force the 
stack-protector check in glibc's configure (libc_cv_ssp) to fail. 

I have got to this point and without being a programmer I am stuck where to go 
from here, whether glibc's __stack_chk_fail and gcc's __stack_chk_guard  are 
different implementations of the same thing or if I need to file a bug (for 
glibc or gcc or both) or fix/ adjust my build system.

I am very happy to give more information about my system and the build if 
wanted.

Hamish Greig