On Feb 2, 2015, at 23:47, Gleb Kurtsou <g...@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 <g...@freebsd.org> wrote:
>>> I came across some build issues in libc.so and SSP.
>>> libc.ldscript (aka libc.so) unconditionally includes 
>>> @@LIBDIR@@/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?

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to