From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] Analysis of build results for 2016-02-21
Date: Tue, 23 Feb 2016 09:11:46 +0100 [thread overview]
Message-ID: <20160223091146.33e3f5b1@free-electrons.com> (raw)
In-Reply-To: <CALdGskLWXoRtKZdqYErn6w4QmcAxLroxtzxkMFYiRsPuH_O7Hg@mail.gmail.com>
Hello,
On Tue, 23 Feb 2016 09:34:31 +0200, Olivier Schonken wrote:
> The suggestion from Romain to disable -fPIE as below works for both
> architectures. Can I submit a patch for this? Or do you want to wait for a
> response from Alexey and Waldemar?
>
> # Remove -fPIE -pie from CFLAGS
> ifeq ($(BR2_STATIC_LIBS),y)
> CUPS_CONF_OPTS += LSB_BUILD=y
> endif
Unfortunately, I don't like this, for several reasons:
1/ LSB_BUILD=y will also disable stack protection support.
2/ Only uClibc in static library build is affected by the problem, not
musl for example.
3/ It is not fixing the real problem.
The real fixes are:
1/ Use AC_CACHE_VAL() in the configure.ac script to be able to force
disable PIE, and then use that to disable it on ARC. Or
alternatively, change the configure.ac to use:
++AX_CHECK_COMPILE_FLAG([-fPIE -DPIE], [PIE_CFLAGS="-fPIE -DPIE"])
++AX_CHECK_LINK_FLAG([-pie], [PIE_LDFLAGS="$PIE_LDFLAGS -pie"])
Which also provide cache variables to override their results. See
http://patchwork.ozlabs.org/patch/569556/.
2/ Fix the uClibc static case by fixing the toolchain build process or
uClibc itself (depending on which one is broken).
Of course, this requires effort than the quick hack of LSB_BUILD=y, but
those are IMO the real fixes, while LSB_BUILD=y is papering over the
real problem.
Note that there are other classes of cups-2.1.2 build failures visible
at http://autobuild.buildroot.org/?reason=cups-2.1.2.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2016-02-23 8:11 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-22 19:05 [Buildroot] Analysis of build results for 2016-02-21 Olivier Schonken
2016-02-22 21:55 ` Romain Naour
2016-02-22 22:21 ` Thomas Petazzoni
2016-02-23 7:34 ` Olivier Schonken
2016-02-23 8:11 ` Thomas Petazzoni [this message]
2016-02-23 11:13 ` Olivier Schonken
2016-02-24 21:30 ` Waldemar Brodkorb
-- strict thread matches above, loose matches on Subject: below --
2016-02-22 7:30 [Buildroot] [autobuild.buildroot.net] Build " Thomas Petazzoni
2016-02-22 14:05 ` [Buildroot] Analysis of build " Thomas Petazzoni
2016-02-23 10:12 ` John Keeping
2016-02-23 10:40 ` Jeroen Roovers
2016-02-23 11:03 ` John Keeping
2016-02-23 12:30 ` Thomas Petazzoni
2016-02-24 11:08 ` Eric Limpens
2016-02-24 20:45 ` Arnout Vandecappelle
2016-02-24 20:59 ` Eric Limpens
2016-02-24 21:42 ` Waldemar Brodkorb
2016-02-24 22:09 ` Arnout Vandecappelle
2016-02-27 15:19 ` Romain Naour
2016-02-27 22:05 ` Bernd Kuhls
2016-03-01 9:38 ` Thomas Petazzoni
2016-02-28 0:17 ` Bernd Kuhls
2016-03-01 9:39 ` Thomas Petazzoni
2016-03-03 13:56 ` Gustavo Zacarias
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=20160223091146.33e3f5b1@free-electrons.com \
--to=thomas.petazzoni@free-electrons.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