* [Buildroot] [git commit] erlang: use libatomic_ops if available
@ 2014-12-15 21:36 Peter Korsgaard
2014-12-16 12:26 ` Thomas Petazzoni
0 siblings, 1 reply; 5+ messages in thread
From: Peter Korsgaard @ 2014-12-15 21:36 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=4a5b819c0f9f5ad0a77017d402410870183967e0
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Erlang can either provide its own atomic_ops implementation or use the
one in libatomic_ops. This patch ensures that it only uses the one from
libatomic_ops if it is available.
Fixes:
http://autobuild.buildroot.net/results/3eb/3ebfd36948d5a642cc83ce31ddf5902cb369bfbd/
http://autobuild.buildroot.net/results/04c/04cbf79ccf159e15f9ea3953b425faadafc8a1c0/
http://autobuild.buildroot.net/results/fc9/fc9904446553e67dd44954310fea26d751a0df5d/
http://autobuild.buildroot.net/results/501/501a12da25615071fb6197a898456cfe41a6451d/
http://autobuild.buildroot.net/results/34e/34e2fbb4d39737fd7defa5bd607726d52ef38568/
http://autobuild.buildroot.net/results/722/7220c3905ebe9e081f1e3b90641b0859d996c2ac/
http://autobuild.buildroot.net/results/ffd/ffdc531d8cf9adb43340d045aa88eb0b39fc9bb7/
http://autobuild.buildroot.net/results/b4f/b4f238bcb30b0191ce1a2be669fa792c8ccd3e69/
Signed-off-by: Frank Hunleth <fhunleth@troodon-software.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
---
package/erlang/erlang.mk | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/package/erlang/erlang.mk b/package/erlang/erlang.mk
index 045c07f..dd15539 100644
--- a/package/erlang/erlang.mk
+++ b/package/erlang/erlang.mk
@@ -22,6 +22,11 @@ ERLANG_CONF_ENV += erl_xcomp_sysroot=$(STAGING_DIR)
ERLANG_CONF_OPTS = --without-javac
+ifeq ($(BR2_PACKAGE_LIBATOMIC_OPS),y)
+ERLANG_DEPENDENCIES = libatomic_ops
+ERLANG_CONF_OPTS += --with-libatomic_ops=$(STAGING_DIR)/usr
+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.
HOST_ERLANG_DEPENDENCIES = host-openssl
^ permalink raw reply related [flat|nested] 5+ messages in thread
* [Buildroot] [git commit] erlang: use libatomic_ops if available
2014-12-15 21:36 [Buildroot] [git commit] erlang: use libatomic_ops if available Peter Korsgaard
@ 2014-12-16 12:26 ` Thomas Petazzoni
2014-12-16 12:41 ` Peter Korsgaard
0 siblings, 1 reply; 5+ messages in thread
From: Thomas Petazzoni @ 2014-12-16 12:26 UTC (permalink / raw)
To: buildroot
Hello,
On Mon, 15 Dec 2014 22:36:24 +0100, Peter Korsgaard wrote:
> Erlang can either provide its own atomic_ops implementation or use the
> one in libatomic_ops. This patch ensures that it only uses the one from
> libatomic_ops if it is available.
Is this really what we want to do? In such cases, we normally always
force to use the "system" version of the library rather than the
built-in one. Why should Erlang be treated differently, especially if
using the "system" version of the library works fine?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Buildroot] [git commit] erlang: use libatomic_ops if available
2014-12-16 12:26 ` Thomas Petazzoni
@ 2014-12-16 12:41 ` Peter Korsgaard
2014-12-16 12:45 ` Thomas Petazzoni
0 siblings, 1 reply; 5+ messages in thread
From: Peter Korsgaard @ 2014-12-16 12:41 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> Hello,
> On Mon, 15 Dec 2014 22:36:24 +0100, Peter Korsgaard wrote:
>> Erlang can either provide its own atomic_ops implementation or use the
>> one in libatomic_ops. This patch ensures that it only uses the one from
>> libatomic_ops if it is available.
> Is this really what we want to do? In such cases, we normally always
> force to use the "system" version of the library rather than the
> built-in one. Why should Erlang be treated differently, especially if
> using the "system" version of the library works fine?
So in other words, make erlang select libatomic_ops? That sounds fine to
me.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Buildroot] [git commit] erlang: use libatomic_ops if available
2014-12-16 12:41 ` Peter Korsgaard
@ 2014-12-16 12:45 ` Thomas Petazzoni
2014-12-16 13:00 ` Frank Hunleth
0 siblings, 1 reply; 5+ messages in thread
From: Thomas Petazzoni @ 2014-12-16 12:45 UTC (permalink / raw)
To: buildroot
Dear Peter Korsgaard,
On Tue, 16 Dec 2014 13:41:33 +0100, Peter Korsgaard wrote:
> > Is this really what we want to do? In such cases, we normally always
> > force to use the "system" version of the library rather than the
> > built-in one. Why should Erlang be treated differently, especially if
> > using the "system" version of the library works fine?
>
> So in other words, make erlang select libatomic_ops? That sounds fine to
> me.
Yes, that's what I meant: make erlang select libatomic_ops.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Buildroot] [git commit] erlang: use libatomic_ops if available
2014-12-16 12:45 ` Thomas Petazzoni
@ 2014-12-16 13:00 ` Frank Hunleth
0 siblings, 0 replies; 5+ messages in thread
From: Frank Hunleth @ 2014-12-16 13:00 UTC (permalink / raw)
To: buildroot
Thomas and Peter,
On Tue, Dec 16, 2014 at 7:45 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Peter Korsgaard,
>
> On Tue, 16 Dec 2014 13:41:33 +0100, Peter Korsgaard wrote:
>
>> > Is this really what we want to do? In such cases, we normally always
>> > force to use the "system" version of the library rather than the
>> > built-in one. Why should Erlang be treated differently, especially if
>> > using the "system" version of the library works fine?
>>
>> So in other words, make erlang select libatomic_ops? That sounds fine to
>> me.
>
> Yes, that's what I meant: make erlang select libatomic_ops.
This sounds good to me as well. I'll fix it shortly.
Thanks,
Frank
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-12-16 13:00 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-12-15 21:36 [Buildroot] [git commit] erlang: use libatomic_ops if available Peter Korsgaard
2014-12-16 12:26 ` Thomas Petazzoni
2014-12-16 12:41 ` Peter Korsgaard
2014-12-16 12:45 ` Thomas Petazzoni
2014-12-16 13:00 ` Frank Hunleth
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.