Re: libc.so dependency on libssp_nonshared.a

On Feb 2, 2015, at 23:47, Gleb Kurtsou <gleb_at_freebsd.org> wrote:

> On (02/02/2015 17:06), Jeremie Le Hen wrote:
>> Hi Gleb,
>> On Sun, Feb 1, 2015 at 9:24 PM, Gleb Kurtsou <gleb_at_freebsd.org> wrote:
>>> I came across some build issues in libc.so and SSP.
>>> 
>>> libc.ldscript (aka libc.so) unconditionally includes _at__at_LIBDIR_at__at_/libssp_nonshared.a
>>> 
>>> libssp* are not built if WITHOUT_SSP defined.
>>> 
>>> ObsoleteFiles.inc doesn't mention libssp*.
>>> 
>>> Consider WITHOUT_SSP=yes case.  As soon as one does clean installworld
>>> and/or removes stale libssp_nonshared.a ld fails to link anything
>>> because of missing libssp_nonshared.a
>> 
>> I think nowadays it would make sense to get it of WITHOUT_SSP
>> altogether.  This will turn this into a non-issue.
> 
> Do you mean building libssp_nonshared unconditionally? It makes perfect
> sense. The library is a single stub function.
> 
> By building libssp* conditionally we may expect that -fstack-protector
> complier option won't work. I wasn't able to reproduce this potential
> problem. libc provides __stack_chk_fail and __stack_chk_guard. And I
> failed to create a test case that would generate code using anything
> like __memcpy_chk.
> 
> Perhaps we should change MK_SSP to operate as documented (add
> -fstack-protector to CFLAGS) and consider adding MK_SSP_SUPPORT option
> for libraries.  Although there is no reason to have MK_SSP_SUPPORT if
> that would imply failure to run binaries or compile with
> -fstack-protector.

Silly question: shouldn’t libc.ldscript be built, conditionally with libssp_nonshared.a? Doing that would be trivial… Are there any concerns with doing this?