From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] Analysis of build results for 2017-11-25
Date: Wed, 29 Nov 2017 14:34:27 +0100 [thread overview]
Message-ID: <20171129143427.576f713e@windsurf.home> (raw)
In-Reply-To: <CAJtjsKbTBDN8zaOOR5FLfC-rXq7WDskvVu-M6Y1sgZzcTTSBog@mail.gmail.com>
Hello,
On Wed, 29 Nov 2017 14:28:55 +0100, Johan Oudinet wrote:
> > I don't have much time at the moment but I'll take a look at this when I
> > can (in a previous life I was an Erlang programmer, it's great to see it
> > as part of buildroot!). It would be sad to disable HiPE so I'll see if
> > we can just bump the version up to 20.
> >
> > Or Johan if you get to it first, I'll certainly test it :-)
>
> I haven't had the time to do it yet, however, it seems OTP 20 has
> simply applied the patch I mentioned:
> https://github.com/erlang/otp/pull/1394/commits/024e438101c010f17e3a374117c3b376d48483f3
>
> If I understand correctly this configure, there is a test in the
> configure to automatically enable HiPE for a list of architectures.
> ppc64 is present in this list but not ppc64le. So, I think HiPE would
> be disabled on ppc64le architectures even if we bump to OTP 20.
Well, if this commit made it to OTP 20, then there is no need to
disable HiPE explicitly: my understanding is that this commit makes
sure ppc64le is not mistaken as ppc64, in particular to avoid having
HiPE being enabled. See https://github.com/erlang/otp/blob/master/erts/configure.in:
if test "$cross_compiling" != "yes" && test X${enable_hipe} != Xno; then
if test -z "$M4"; then
enable_hipe=no
AC_MSG_NOTICE([HiPE disabled as no valid m4 is found in PATH])
else
case "$ARCH-$OPSYS" in
x86-linux|amd64-linux|x86-darwin*|amd64-darwin*|ppc-linux|ppc64-linux|ppc-darwin|arm-linux|amd64-freebsd|x86-freebsd|x86-sol2|amd64-sol2|ultrasparc-linux)
enable_hipe=yes
;;
esac
fi
fi
ppc64le used to be handled as ppc64, so it was matching the case
"$ARCH-$OPSYS", and enable_hipe was set to yes.
With ARCH=ppc64le, this will no longer match, and enable_hipe will no
longer be set to yes.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2017-11-29 13:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-26 7:00 [Buildroot] [autobuild.buildroot.net] Build results for 2017-11-25 Thomas Petazzoni
2017-11-26 8:34 ` Yegor Yefremov
2017-11-26 14:21 ` [Buildroot] Analysis of build " Thomas Petazzoni
2017-11-27 11:10 ` Yann E. MORIN
2017-11-27 11:48 ` Yann E. MORIN
2017-11-27 13:58 ` Gaël PORTAY
2017-11-27 14:01 ` Johan Oudinet
2017-11-27 14:13 ` Thomas Petazzoni
[not found] ` <OF3CB5EEB3.059011A8-ON002581E5.004E2384@notes.na.collabserv.com>
2017-11-28 23:30 ` Sam Bobroff
2017-11-29 13:28 ` Johan Oudinet
2017-11-29 13:34 ` Thomas Petazzoni [this message]
2017-11-30 15:00 ` Johan Oudinet
2017-11-27 20:08 ` Ismael Luceno
2017-11-28 22:44 ` Arnout Vandecappelle
2017-11-30 0:35 ` Matthew Weber
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=20171129143427.576f713e@windsurf.home \
--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