Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Stefan Fröberg" <stefan.froberg@petroprogram.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1 v2] gcc: Add support for --enable-default-pie configure option.
Date: Sat, 30 Dec 2017 04:34:14 +0200	[thread overview]
Message-ID: <774e53d5-5fbd-b59d-2b2f-9b4737dd2784@petroprogram.com> (raw)
In-Reply-To: <20171229150446.197ea731@windsurf.lan>

Hello


Thomas Petazzoni kirjoitti 29.12.2017 klo 16:04:
> Hello,
>
> On Fri, 29 Dec 2017 15:48:48 +0200, Stefan Fr?berg wrote:
>
>> Yeah, there is no other way for external toolchains than generic flags
>> passing (and possibly patching)
>> or compiler wrapper (well, there is specs file but it's ...soooo messy...).
> And since the different method needed for external toolchains would
> also work for internal toolchains, there is no point in doing a
> solution that only works for internal toolchains. See my point ?

Except can you be absolute sure that -fpic and -fpie will never happen
in the same commandline
when using just flags?

>> Personally, Im only interested of internal toolchain
>> (and I think this is not the first case that internal/external
>> toolchains have different rules?)
> We generally try to have internal and external toolchains supported in
> the same way. You may only be interested in internal toolchains, but
> Buildroot as a project needs to keep the feature parity between
> internal and external toolchains, so we would like to have a solution
> that solves both situations.
>
> Thomas

Actually, not true. You already have options like "Enable compiler
link-time-optimization support",
"Enable compiler OpenMP support" and "Enable graphite support".
(with pretty spartan description I might add)

All those are optimization related, activated by built-time
configuration switches.
Mine is security related and also activated by built-time configuration
switch.

And when selecting External toolchain then ...*poof* ... they all vanish
into the air.

So if buildroot would really treat both external and internal toolchain
equally then those options should
also be added when using external toolchain.

-S-

      reply	other threads:[~2017-12-30  2:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-28 21:43 [Buildroot] [PATCH 1/1 v2] gcc: Add support for --enable-default-pie configure option Stefan Fröberg
2017-12-28 22:07 ` Thomas Petazzoni
     [not found]   ` <CANQCQpZ40Q3T2gOPqu8_vGHCTAup_fxgW3ubfYjewfgo7DwW0A@mail.gmail.com>
2017-12-28 23:28     ` Matthew Weber
2017-12-29 13:25   ` Stefan Fröberg
2017-12-29 13:34     ` Stefan Fröberg
2017-12-29 13:42     ` Thomas Petazzoni
2017-12-29 13:48       ` Stefan Fröberg
2017-12-29 14:04         ` Thomas Petazzoni
2017-12-30  2:34           ` Stefan Fröberg [this message]

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=774e53d5-5fbd-b59d-2b2f-9b4737dd2784@petroprogram.com \
    --to=stefan.froberg@petroprogram.com \
    --cc=buildroot@busybox.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox