> On Jun 20, 2016, at 7:48 AM, André Draszik <g...@andred.net> wrote: > > 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 <g...@andred.net> wrote: >>> From: André Draszik <adras...@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?
We set the ssp variables manually (gcc_cv_libc_provides_ssp=yes), when building gcc initial. which should suffice for building core libraries. If uclibc build extra utils then lets spin that via a separate recipe something like uclibc-utils or some such which is built later than uclibc. > > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
