All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v3 1/2] erlang: use erlang's native atomic ops
Date: Sat, 27 Feb 2016 23:17:04 +0100	[thread overview]
Message-ID: <56D22060.4020108@mind.be> (raw)
In-Reply-To: <1456082246-28181-1-git-send-email-fhunleth@troodon-software.com>

On 02/21/16 20:17, Frank Hunleth wrote:
> Now that we're using Erlang 18, the preferred atomic ops implementation
> for Erlang is its own built-in implementation, so use it.  It is still
> possible to use libatomic_ops if the native implementation does not
> work. BR2_PACKAGE_ERLANG_ARCH_SUPPORTS is added now that
> BR2_PACKAGE_LIBATOMIC_OPS_ARCH_SUPPORTS is no longer appropriate for
> checking whether Erlang can be built for a platform.
> 
> This fixes an autobuilder failure when using libatomic_ops on aarch64.
> Erlang's native atomic ops implementation works on this platform.
> 
> Fixes:
> http://autobuild.buildroot.net/results/0cd/0cd22eb74fa29e5a85bf897762e16ab3daf33962/
> 
> Signed-off-by: Frank Hunleth <fhunleth@troodon-software.com>
> ---
[snip]
> +config BR2_PACKAGE_ERLANG_ARCH_SUPPORTS
> +	bool
> +	default y if BR2_i386 || BR2_x86_64 || BR2_powerpc || BR2_sparc_v9 || BR2_arm || BR2_aarch64 # case (1)

 This line is too long, please split it.

> +	default y if BR2_PACKAGE_LIBATOMIC_OPS_ARCH_SUPPORTS # case (4)
>  
>  config BR2_PACKAGE_ERLANG
>  	bool "erlang"
>  	depends on BR2_USE_MMU # fork()
>  	depends on !BR2_STATIC_LIBS
> -	depends on BR2_PACKAGE_LIBATOMIC_OPS_ARCH_SUPPORTS
> -	select BR2_PACKAGE_LIBATOMIC_OPS
> +	depends on BR2_PACKAGE_ERLANG_ARCH_SUPPORTS
>  	help
>  	  Erlang is a programming language used to build massively scalable
>  	  soft real-time systems with requirements on high availability.
> @@ -20,6 +36,14 @@ config BR2_PACKAGE_ERLANG
>  
>  if BR2_PACKAGE_ERLANG
>  
> +config BR2_PACKAGE_ERLANG_LIBATOMIC_OPS
> +	bool "libatomic_ops"

 Does it make sense to let the user select this? I don't think so...

 I think we should have:

config BR2_PACKAGE_ERLANG_ARCH_SUPPORTS_DIRECTLY # case (1)
	bool
	default y if BR2_i386 || BR2_x86_64 || BR2_powerpc || \
		BR2_sparc_v9 || BR2_arm # aarch64 causes build failures

config BR2_PACKAGE_ERLANG_ARCH_SUPPORTS
	bool
	default y if BR2_PACKAGE_ERLANG_ARCH_SUPPORTS_DIRECTLY
	default y if BR2_PACKAGE_LIBATOMIC_OPS_ARCH_SUPPORTS # case (4)

and nothing more.

> +	depends on BR2_PACKAGE_LIBATOMIC_OPS_ARCH_SUPPORTS
> +	depends on !BR2_aarch64 # causes build failures
> +	select BR2_PACKAGE_LIBATOMIC_OPS
> +	help
> +	  Use libatomic_ops instead of Erlang's native atomic ops support.
> +
>  config BR2_PACKAGE_ERLANG_SMP
>  	bool "enable SMP support"
>  	help
> @@ -38,3 +62,8 @@ config BR2_PACKAGE_ERLANG_MEGACO
>  	  enable it.
>  
>  endif # BR2_PACKAGE_ERLANG
> +
> +comment "erlang needs a toolchain w/ dynamic library, atomic_ops"
> +	depends on BR2_USE_MMU # fork()
> +	depends on BR2_STATIC_LIBS || !BR2_PACKAGE_ERLANG_ARCH_SUPPORTS

 This should depend on BR2_PACKAGE_ERLANG_ARCH_SUPPORTS, so:

comment "erlang needs a toolchain w/ dynamic library"
	depends on BR2_PACKAGE_ERLANG_ARCH_SUPPORTS
	depends on BR2_USE_MMU # fork()
	depends on BR2_STATIC_LIBS

and that should ideally be a separate patch, or at least mentioned in the commit
message.

> +
> diff --git a/package/erlang/erlang.mk b/package/erlang/erlang.mk
> index 638d2c2..8257ab4 100644
> --- a/package/erlang/erlang.mk
> +++ b/package/erlang/erlang.mk
> @@ -30,8 +30,12 @@ ERLANG_CONF_ENV += erl_xcomp_sysroot=$(STAGING_DIR)
>  
>  ERLANG_CONF_OPTS = --without-javac
>  
> +# Erlang uses its own native atomic ops implementation if support is
> +# available. Override this if the user wants libatomic_ops.
> +ifeq ($(BR2_PACKAGE_ERLANG_LIBATOMIC_OPS),y)

 So here it should be

ifeq ($(BR2_PACKAGE_ERLANG_ARCH_SUPPORTS_DIRECTLY),)


 Regards,
 Arnout

>  ERLANG_DEPENDENCIES += libatomic_ops
>  ERLANG_CONF_OPTS += --with-libatomic_ops=$(STAGING_DIR)/usr LIBS=-latomic_ops
> +endif
>  
>  # erlang uses openssl for all things crypto. Since the host tools (such as
>  # rebar) uses crypto, we need to build host-erlang with support for openssl.
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

  parent reply	other threads:[~2016-02-27 22:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-21 19:17 [Buildroot] [PATCH v3 1/2] erlang: use erlang's native atomic ops Frank Hunleth
2016-02-21 19:17 ` [Buildroot] [PATCH v3 2/2] erlang: remove extraneous LIBS=-latomic_ops Frank Hunleth
2016-02-27 22:17 ` Arnout Vandecappelle [this message]
2016-03-02 20:47   ` [Buildroot] [PATCH v3 1/2] erlang: use erlang's native atomic ops Frank Hunleth
2016-03-06 19:02     ` Arnout Vandecappelle

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=56D22060.4020108@mind.be \
    --to=arnout@mind.be \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.