Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [autobuild.buildroot.net] Build results for 2014-10-04
Date: Wed, 25 Mar 2015 00:26:55 +0100	[thread overview]
Message-ID: <20150325002655.1d4b2f3d@free-electrons.com> (raw)
In-Reply-To: <CANQCQpbYMUU64NYZshBXa-pMXJ2q1gB4pLZODUDB1V5Ch9yO1A@mail.gmail.com>

Dear Matthew Weber,

On Tue, 7 Oct 2014 20:52:15 -0500, Matthew Weber wrote:

> > Yeah, I believe the GCC version check is arbitrary.  I was going to
> > take a look at the generic atomics implementations and see if they
> > were stub functions.  If so, we could patch in a workaround to allow
> > GCC  >= 4.3 to build (with that being an arbitrarily old compiler
> > version.....)  or just open it up to any version and test if we get
> > compiler failures.
> 
> It does look like the version check is correct.  They implemented
> atomics in the latest release and the generic implementation for arch
> not supporting the custom atomics uses the built-in GCC >= 4.7
> functions.  I was looking at conditionally setting
> BR2_ARCH_HAS_ATOMICS and to get it completely correct is quite
> invasive like you mentioned.  What about if we just set it for
> buildroot and external toolchains that we where we know if they are
> >=4.7.  Leaving any user defined external toolchains to possibly run
> into this issue, but maybe that's ok?

Reviving an old discussion, but someone pinged me about this, so I had
a second look. I looked at one of the build failures we originally
discussed:
http://autobuild.buildroot.net/results/3c1/3c1c620684a23b4cbb1cfa560096094cd9bf09ec/build-end.log.
This is a PowerPC build, failing with:

./google/protobuf/stubs/platform_macros.h:77:2: error: #error Host architecture was not detected as supported by protobuf

And here is what the protobuf code looks like:

#if defined(_M_X64) || defined(__x86_64__)
#define GOOGLE_PROTOBUF_ARCH_X64 1
#define GOOGLE_PROTOBUF_ARCH_64_BIT 1
#elif defined(_M_IX86) || defined(__i386__)
#define GOOGLE_PROTOBUF_ARCH_IA32 1
#define GOOGLE_PROTOBUF_ARCH_32_BIT 1
#elif defined(__QNX__)
#define GOOGLE_PROTOBUF_ARCH_ARM_QNX 1
#define GOOGLE_PROTOBUF_ARCH_32_BIT 1
#elif defined(__ARMEL__)
#define GOOGLE_PROTOBUF_ARCH_ARM 1
#define GOOGLE_PROTOBUF_ARCH_32_BIT 1
#elif defined(__aarch64__)
#define GOOGLE_PROTOBUF_ARCH_AARCH64 1
#define GOOGLE_PROTOBUF_ARCH_64_BIT 1
#elif defined(__MIPSEL__)
#if defined(__LP64__)
#define GOOGLE_PROTOBUF_ARCH_MIPS64 1
#define GOOGLE_PROTOBUF_ARCH_64_BIT 1
#else
#define GOOGLE_PROTOBUF_ARCH_MIPS 1
#define GOOGLE_PROTOBUF_ARCH_32_BIT 1
#endif
#elif defined(__pnacl__)
#define GOOGLE_PROTOBUF_ARCH_32_BIT 1
#elif defined(__ppc__)
#define GOOGLE_PROTOBUF_ARCH_PPC 1
#define GOOGLE_PROTOBUF_ARCH_32_BIT 1
#elif defined(__GNUC__) && \
 (((__GNUC__ == 4) && (__GNUC_MINOR__ >= 7)) || (__GNUC__ > 4))
// We fallback to the generic GCC >= 4.7 implementation in atomicops.h
# if __LP64__
#  define GOOGLE_PROTOBUF_ARCH_64_BIT 1
# else
#  define GOOGLE_PROTOBUF_ARCH_32_BIT 1
# endif
#else
#error Host architecture was not detected as supported by protobuf
#endif

So, when the architecture is not supported it indeed falls back on
using atomic intrinsics provided by gcc >= 4.7. However, before that
there is a:

#elif defined(__ppc__)

which should indicate that the PowerPC architecture specifically should
be supported without having to rely on the compiler intrinsics. Do we
know why this is not working?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

      reply	other threads:[~2015-03-24 23:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-05  6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-10-04 Thomas Petazzoni
2014-10-06 19:45 ` Matthew Weber
2014-10-07  7:48   ` Thomas Petazzoni
2014-10-07 16:30     ` Matthew Weber
2014-10-08  1:52       ` Matthew Weber
2015-03-24 23:26         ` Thomas Petazzoni [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=20150325002655.1d4b2f3d@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