Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 2 Feb 2015 23:47:09 -0800
From:      Gleb Kurtsou <gleb@freebsd.org>
To:        Jeremie Le Hen <jlh@FreeBSD.org>
Cc:        freebsd-current@freebsd.org
Subject:   Re: libc.so dependency on libssp_nonshared.a
Message-ID:  <20150203074709.GA1091@reks>
In-Reply-To: <CAGSa5y0LFURkF2urpuDWXxib65qxF7a-5ZYA_SU_YOfU_h=GGg@mail.gmail.com>
References:  <20150201202413.GA2132@reks> <CAGSa5y0LFURkF2urpuDWXxib65qxF7a-5ZYA_SU_YOfU_h=GGg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On (02/02/2015 17:06), Jeremie Le Hen wrote:
> Hi Gleb,
> On Sun, Feb 1, 2015 at 9:24 PM, Gleb Kurtsou <gleb@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.


> > libc.so during buildworld (as found under /usr/obj) is symlink to the
> > actual shared library, but not ldscript.  Is it intentional?  I wouldn't
> > expect make -C /usr/src/bin/cat to match buildworld result closely
> > assuming src and world are in sync, but they seem to have different idea
> > of what libc is..
> 
> I don't remember the details except this was pretty twisted :).  I
> don't work enough on this subject to keep it warm in my head and each
> time I need to go back to it, it takes me hours.
> 
> The code is here if you want to give a try:
> http://svnweb.freebsd.org/base/head/share/mk/bsd.lib.mk?view=annotate#l335

indeed.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150203074709.GA1091>