From: "André Draszik" <git@andred.net>
To: Khem Raj <raj.khem@gmail.com>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 2/2] uclibc: never build with SSP
Date: Mon, 20 Jun 2016 15:48:54 +0100 [thread overview]
Message-ID: <1466434134.6499.27.camel@andred.net> (raw)
In-Reply-To: <CAMKF1srfaxLS3wn5d5Fu46i5-hU+kGj3dViD_v7YyF3wut013A@mail.gmail.com>
Hi Khem,
On Mi, 2016-06-15 at 17:20 -0700, Khem Raj wrote:
> On Fri, Jun 10, 2016 at 8:12 AM, André Draszik <git@andred.net> wrote:
> > From: André Draszik <adraszik@tycoint.com>
> >
> > This doesn't work, as the initial gcc that is used for compiling
> > uclibc doesn't have support for SSP yet (since that will only
> > be available once uclibc has been compiled). Since during that
> > same compilation step uclibc is trying to build its own utils
> > those are failing to compile with SSP enabled as the
> > initial gcc doesn't have access to the required libraries,
> > yet.
>
> Please look at how we do this for glibc based systems.
Are you saying glibc is compiled *with* SSP enabled?
I can't seem to find anything relevant. The only thing I can find seems to
result in glibc and (and glibc-initial) and all glibc executables (!) being
compiled without stack protector. As you seem to have something in mind, can
you please be more specific and give me a pointer?
> This patch is
> not something we need.
This patch fixes uclibc builds when SSP has been enabled by including
security_flags.inc in distro.conf. Why is it not needed? Can you be more
specific please?
Cheers,
Andre
next prev parent reply other threads:[~2016-06-20 14:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-10 15:12 [PATCH 1/2] uclibc: no need for CONFIG_MIPS_ISA_xxx config options André Draszik
2016-06-10 15:12 ` [PATCH 2/2] uclibc: never build with SSP André Draszik
2016-06-16 0:20 ` Khem Raj
2016-06-20 14:48 ` André Draszik [this message]
2016-06-20 15:21 ` André Draszik
2016-06-21 16:12 ` Khem Raj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1466434134.6499.27.camel@andred.net \
--to=git@andred.net \
--cc=openembedded-core@lists.openembedded.org \
--cc=raj.khem@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.