NetBSD Problem Report #53380

From www@NetBSD.org  Sun Jun 17 18:46:49 2018
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 807797A158
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 17 Jun 2018 18:46:49 +0000 (UTC)
Message-Id: <20180617184648.0EF587A1F4@mollari.NetBSD.org>
Date: Sun, 17 Jun 2018 18:46:48 +0000 (UTC)
From: venture37@geeklan.co.uk
Reply-To: venture37@geeklan.co.uk
To: gnats-bugs@NetBSD.org
Subject: undefined reference to `__atomic_fetch_add_8'
X-Send-Pr-Version: www-1.0

>Number:         53380
>Category:       port-macppc
>Synopsis:       undefined reference to `__atomic_fetch_add_8'
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-macppc-maintainer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jun 17 18:50:00 +0000 2018
>Closed-Date:    Fri Nov 06 04:19:49 +0000 2020
>Last-Modified:  Fri Nov 06 04:19:49 +0000 2020
>Originator:     Sevan Janiyan
>Release:        pkgsrc-current
>Organization:
>Environment:
NetBSD 8.0_RC1 macppc powerpc
>Description:
Attempting to build spidermonkey on NetBSD/macppc, the build fails with undefined reference to `__atomic_fetch_add_8'

/var/tmp/pbulk/lang/spidermonkey52/work/mozjs-52.7.4/_virtualenv/bin/python /var/tmp/pbulk/lang/spidermonkey52/work/mozjs-52.7.4/config/expandlibs_exec.py --uselist --  /var/tmp/pbulk/lang/spidermonkey52/work/.cwrapper/bin/c++ -std=gnu++11 -I/usr/pkg/include/nspr -I/usr/include -I/usr/pkg/include -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++14-compat -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -fno-lifetime-dse -O2 -D_FORTIFY_SOURCE=2 -I/usr/pkg/include/nspr -I/usr/include -I/usr/pkg/include -mcpu=powerpc -Dunix -fno-rtti -fno-exceptions -fno-math-errno -pthread -pipe -I/usr/pkg/include  -g -O -fomit-frame-pointer  -fPIC -DPIC -shared -Wl,-z,defs -o libmozjs-52.so  RegExp.o Parser.o StoreBuffer.o jsarray.o jsatom.o jsdtoa.o jsmath.o jsutil.o pm_stub.o ConditionVariable.o MutexImpl.o Thread.o Initializat
 ion.o TraceLogging.o TraceLoggingGraph.o TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o Unified_cpp_js_src10.o Unified_cpp_js_src11.o Unified_cpp_js_src12.o Unified_cpp_js_src13.o Unified_cpp_js_src14.o Unified_cpp_js_src15.o Unified_cpp_js_src16.o Unified_cpp_js_src17.o Unified_cpp_js_src18.o Unified_cpp_js_src19.o Unified_cpp_js_src2.o Unified_cpp_js_src20.o Unified_cpp_js_src21.o Unified_cpp_js_src22.o Unified_cpp_js_src23.o Unified_cpp_js_src24.o Unified_cpp_js_src25.o Unified_cpp_js_src26.o Unified_cpp_js_src27.o Unified_cpp_js_src28.o Unified_cpp_js_src29.o Unified_cpp_js_src3.o Unified_cpp_js_src30.o Unified_cpp_js_src31.o Unified_cpp_js_src32.o Unified_cpp_js_src33.o Unified_cpp_js_src34.o Unified_cpp_js_src35.o Unified_cpp_js_src36.o Unified_cpp_js_src37.o Unified_cpp_js_src4.o Unified_cpp_js_src5.o Unified_cpp_js_src6.o Unified_cpp_js_src7.o Unified_cpp_js_src8.o Unified_cpp_js_src9.o   -lpthread -L/usr/pkg/lib/nspr -Wl,-R/usr/pkg/lib/nspr -L/usr/lib -Wl,-
 R/usr/lib -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id -Wl,-z,wxneeded    -Wl,-rpath-link,/var/tmp/pbulk/lang/spidermonkey52/work/mozjs-52.7.4/js/src/dist/bin -Wl,-rpath-link,/usr/pkg/lib   ../../modules/fdlibm/src/libmodules_fdlibm_src.a ../../mozglue/build/libmozglue.a ../../config/external/icu/libicu.a ../../config/external/nspr/libnspr.a ../../config/external/zlib/libzlib.a      -lm  -L/usr/pkg/lib -licui18n -Wl,-R/usr/pkg/lib -licuuc -licudata -Wl,-R/usr/pkg/lib/nspr -L/usr/pkg/lib/nspr -lplds4 -lplc4 -lnspr4 -L/usr/lib -pthread -lz -lm 
Executing: ../../../../../.cwrapper/bin/c++ -std=gnu++11 -I/usr/pkg/include/nspr -I/usr/include -I/usr/pkg/include -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++14-compat -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -fno-lifetime-dse -O2 -D_FORTIFY_SOURCE=2 -I/usr/pkg/include/nspr -I/usr/include -I/usr/pkg/include -mcpu=powerpc -Dunix -fno-rtti -fno-exceptions -fno-math-errno -pthread -pipe -I/usr/pkg/include -g -O -fomit-frame-pointer -fPIC -DPIC -shared -Wl,-z,defs -o libmozjs-52.so /var/tmp/pbulk/lang/spidermonkey52/work/mozjs-52.7.4/js/src/js/src/tmp8JShZH.list -lpthread -L/usr/pkg/lib/nspr -Wl,-R/usr/pkg/lib/nspr -L/usr/lib -Wl,-R/usr/lib -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id -Wl,-z,wxneeded -Wl,-rpath-link,/var/tmp/pbulk/lang/spidermonkey52/work/mozjs-52.7.4
 /js/src/dist/bin -Wl,-rpath-link,/usr/pkg/lib -lm -L/usr/pkg/lib -licui18n -Wl,-R/usr/pkg/lib -licuuc -licudata -Wl,-R/usr/pkg/lib/nspr -L/usr/pkg/lib/nspr -lplds4 -lplc4 -lnspr4 -L/usr/lib -pthread -lz -lm
/var/tmp/pbulk/lang/spidermonkey52/work/mozjs-52.7.4/js/src/js/src/tmp8JShZH.list:
    INPUT("RegExp.o")
    INPUT("Parser.o")
    INPUT("StoreBuffer.o")
    INPUT("jsarray.o")
    INPUT("jsatom.o")
    INPUT("jsdtoa.o")
    INPUT("jsmath.o")
    INPUT("jsutil.o")
    INPUT("pm_stub.o")
    INPUT("ConditionVariable.o")
    INPUT("MutexImpl.o")
    INPUT("Thread.o")
    INPUT("Initialization.o")
    INPUT("TraceLogging.o")
    INPUT("TraceLoggingGraph.o")
    INPUT("TraceLoggingTypes.o")
    INPUT("Unified_cpp_js_src0.o")
    INPUT("Unified_cpp_js_src1.o")
    INPUT("Unified_cpp_js_src10.o")
    INPUT("Unified_cpp_js_src11.o")
    INPUT("Unified_cpp_js_src12.o")
    INPUT("Unified_cpp_js_src13.o")
    INPUT("Unified_cpp_js_src14.o")
    INPUT("Unified_cpp_js_src15.o")
    INPUT("Unified_cpp_js_src16.o")
    INPUT("Unified_cpp_js_src17.o")
    INPUT("Unified_cpp_js_src18.o")
    INPUT("Unified_cpp_js_src19.o")
    INPUT("Unified_cpp_js_src2.o")
    INPUT("Unified_cpp_js_src20.o")
    INPUT("Unified_cpp_js_src21.o")
    INPUT("Unified_cpp_js_src22.o")
    INPUT("Unified_cpp_js_src23.o")
    INPUT("Unified_cpp_js_src24.o")
    INPUT("Unified_cpp_js_src25.o")
    INPUT("Unified_cpp_js_src26.o")
    INPUT("Unified_cpp_js_src27.o")
    INPUT("Unified_cpp_js_src28.o")
    INPUT("Unified_cpp_js_src29.o")
    INPUT("Unified_cpp_js_src3.o")
    INPUT("Unified_cpp_js_src30.o")
    INPUT("Unified_cpp_js_src31.o")
    INPUT("Unified_cpp_js_src32.o")
    INPUT("Unified_cpp_js_src33.o")
    INPUT("Unified_cpp_js_src34.o")
    INPUT("Unified_cpp_js_src35.o")
    INPUT("Unified_cpp_js_src36.o")
    INPUT("Unified_cpp_js_src37.o")
    INPUT("Unified_cpp_js_src4.o")
    INPUT("Unified_cpp_js_src5.o")
    INPUT("Unified_cpp_js_src6.o")
    INPUT("Unified_cpp_js_src7.o")
    INPUT("Unified_cpp_js_src8.o")
    INPUT("Unified_cpp_js_src9.o")
    INPUT("../../modules/fdlibm/src/e_acos.o")
    INPUT("../../modules/fdlibm/src/e_acosh.o")
    INPUT("../../modules/fdlibm/src/e_asin.o")
    INPUT("../../modules/fdlibm/src/e_atan2.o")
    INPUT("../../modules/fdlibm/src/e_atanh.o")
    INPUT("../../modules/fdlibm/src/e_cosh.o")
    INPUT("../../modules/fdlibm/src/e_exp.o")
    INPUT("../../modules/fdlibm/src/e_hypot.o")
    INPUT("../../modules/fdlibm/src/e_log.o")
    INPUT("../../modules/fdlibm/src/e_log10.o")
    INPUT("../../modules/fdlibm/src/e_log2.o")
    INPUT("../../modules/fdlibm/src/e_pow.o")
    INPUT("../../modules/fdlibm/src/e_sinh.o")
    INPUT("../../modules/fdlibm/src/e_sqrt.o")
    INPUT("../../modules/fdlibm/src/k_exp.o")
    INPUT("../../modules/fdlibm/src/s_asinh.o")
    INPUT("../../modules/fdlibm/src/s_atan.o")
    INPUT("../../modules/fdlibm/src/s_cbrt.o")
    INPUT("../../modules/fdlibm/src/s_ceil.o")
    INPUT("../../modules/fdlibm/src/s_ceilf.o")
    INPUT("../../modules/fdlibm/src/s_copysign.o")
    INPUT("../../modules/fdlibm/src/s_expm1.o")
    INPUT("../../modules/fdlibm/src/s_fabs.o")
    INPUT("../../modules/fdlibm/src/s_floor.o")
    INPUT("../../modules/fdlibm/src/s_floorf.o")
    INPUT("../../modules/fdlibm/src/s_log1p.o")
    INPUT("../../modules/fdlibm/src/s_nearbyint.o")
    INPUT("../../modules/fdlibm/src/s_rint.o")
    INPUT("../../modules/fdlibm/src/s_rintf.o")
    INPUT("../../modules/fdlibm/src/s_scalbn.o")
    INPUT("../../modules/fdlibm/src/s_tanh.o")
    INPUT("../../modules/fdlibm/src/s_trunc.o")
    INPUT("../../modules/fdlibm/src/s_truncf.o")
    INPUT("../../memory/mozalloc/Unified_cpp_memory_mozalloc0.o")
    INPUT("../../mozglue/misc/StackWalk.o")
    INPUT("../../mozglue/misc/TimeStamp.o")
    INPUT("../../mozglue/misc/TimeStamp_posix.o")
    INPUT("../../mfbt/Compression.o")
    INPUT("../../mfbt/Decimal.o")
    INPUT("../../mfbt/Unified_cpp_mfbt0.o")
    INPUT("../../mfbt/Unified_cpp_mfbt1.o")

ld: warning: -z wxneeded ignored.
Unified_cpp_js_src1.o: In function `std::__atomic_base<unsigned long long>::fetch_add(unsigned long long, std::memory_order)':
/usr/include/g++/bits/atomic_base.h:514: undefined reference to `__atomic_fetch_add_8'
Unified_cpp_js_src20.o: In function `std::__atomic_base<unsigned long long>::fetch_add(unsigned long long, std::memory_order)':
/usr/include/g++/bits/atomic_base.h:514: undefined reference to `__atomic_fetch_add_8'
/var/tmp/pbulk/lang/spidermonkey52/work/mozjs-52.7.4/config/rules.mk:800: recipe for target 'libmozjs-52.so' failed
>How-To-Repeat:
attempt to build lang/spidermonkey52 on NetBSD/macppc
>Fix:

>Release-Note:

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-macppc/53380: undefined reference to `__atomic_fetch_add_8'
Date: Sun, 17 Jun 2018 21:04:24 +0200

 Sounds more like a pkg problem to me? Can all 32bit ppc do 64bit atomics
 at all?

 Martin

From: Sevan Janiyan <venture37@geeklan.co.uk>
To: gnats-bugs@NetBSD.org, port-macppc-maintainer@netbsd.org,
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc: 
Subject: Re: port-macppc/53380: undefined reference to `__atomic_fetch_add_8'
Date: Mon, 18 Jun 2018 08:44:26 +0100

 On 17/06/2018 20:05, Martin Husemann wrote:
 > Sounds more like a pkg problem to me?

 I think you may be right, I may have made the wrong assumption as a
 header in base was reference. smells similar to pkg/48595.

 > Can all 32bit ppc do 64bit atomics at all?

 I don't know, but I'll find out and follow up.


 Sevan

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-macppc/53380: undefined reference to `__atomic_fetch_add_8'
Date: Mon, 18 Jun 2018 09:47:36 +0200

 On Mon, Jun 18, 2018 at 07:45:01AM +0000, Sevan Janiyan wrote:
 >  > Can all 32bit ppc do 64bit atomics at all?
 >  
 >  I don't know, but I'll find out and follow up.

 If they can we need to adjust the atomics test.

 Martin

From: Michael <macallan@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-macppc/53380: undefined reference to
 `__atomic_fetch_add_8'
Date: Mon, 18 Jun 2018 11:57:46 -0400

 On Sun, 17 Jun 2018 19:05:00 +0000 (UTC)
 Martin Husemann <martin@duskware.de> wrote:

 >  Can all 32bit ppc do 64bit atomics at all?

 I don't think so. ldarx/stdcx are 64bit only.

 have fun
 Michael

From: "David H. Gutteridge" <david@gutteridge.ca>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-macppc/53380: undefined reference to `__atomic_fetch_add_8'
Date: Fri, 22 Mar 2019 00:47:26 -0400

 This issue -- with spidermonkey52, anyway -- was addressed by me back
 in January. I didn't know this PR existed at the time. (The commit is
 here: http://anonhg.netbsd.org/pkgsrc/rev/420ac31d94c7 .)

 Sevan, if you haven't already done so, please try building it again.
 It builds and runs successfully for me. (And, yes, I tested it by using
 the JavaScript console that SpiderMonkey provides.)

 (My impetus for fixing this was so that the Xfce meta-package builds on
 macppc. It now does.)

 Fundamentally, the only way I know this will build on 32-bit PowerPC is
 to use GCC's libatomic. This isn't available in NetBSD base, so we must
 use a GCC from pkgsrc, and force it to install the associated libgcc
 libraries. (As leot@ noted recently about Firefox, this "abuses" the
 meaning of USE_PKGSRC_GCC_RUNTIME, but there's no way around this
 here.)

 If it's enough of a concern, I suppose the other possibility would be
 to beg mrg@ to include GCC's libatomic in base. I'm not sure how much
 general utility that would have. (I don't mean that to be too skeptical
 sounding, but at this point, we can expect increasing problems with a
 lot of recent software.) Otherwise, this can be closed.

 Dave


From: Jason Thorpe <thorpej@me.com>
To: gnats-bugs@netbsd.org
Cc: port-macppc-maintainer@netbsd.org,
 gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org,
 venture37@geeklan.co.uk
Subject: Re: port-macppc/53380: undefined reference to `__atomic_fetch_add_8'
Date: Thu, 21 Mar 2019 21:54:56 -0700

 > On Mar 21, 2019, at 9:50 PM, David H. Gutteridge <david@gutteridge.ca> =
 wrote:
 >=20
 > Fundamentally, the only way I know this will build on 32-bit PowerPC =
 is
 > to use GCC's libatomic. This isn't available in NetBSD base, so we =
 must
 > use a GCC from pkgsrc, and force it to install the associated libgcc
 > libraries. (As leot@ noted recently about Firefox, this "abuses" the
 > meaning of USE_PKGSRC_GCC_RUNTIME, but there's no way around this
 > here.)

 We should not be including GCC's libatomic... Can someone explain to me =
 how __atomic_fetch_add_8() is implemented on 32-bit PowerPC?

 -- thorpej

From: "David H. Gutteridge" <david@gutteridge.ca>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-macppc/53380: undefined reference to `__atomic_fetch_add_8'
Date: Fri, 22 Mar 2019 01:17:09 -0400

 On Thu, 21 Mar 2019 at 21:54:56 -0700, Jason Thorpe wrote:
 >We should not be including GCC's libatomic... Can someone explain to me
 >how __atomic_fetch_add_8() is implemented on 32-bit PowerPC?

 My understanding is GCC's libatomic must implement this in software,
 since it isn't available as a hardware instruction. (This solution for
 this specific PowerPC problem has been applied by other projects.) Do
 you have an alternate suggestion to fix this? (A serious question, not
 sarcasm.)

 Dave


From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: port-macppc-maintainer@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, venture37@geeklan.co.uk
Subject: Re: port-macppc/53380: undefined reference to `__atomic_fetch_add_8'
Date: Fri, 22 Mar 2019 06:35:07 +0100

 On Fri, Mar 22, 2019 at 05:20:01AM +0000, David H. Gutteridge wrote:
 >  My understanding is GCC's libatomic must implement this in software,
 >  since it isn't available as a hardware instruction. (This solution for
 >  this specific PowerPC problem has been applied by other projects.) Do
 >  you have an alternate suggestion to fix this? (A serious question, not
 >  sarcasm.)

 The problem is that there is no meaningfull way (at least in my view
 of reality) to implement something like that in software. You can trick
 around it (e.g. by using RAS on a single CPU machine), but then you
 would be far better of not relying on atomics at all.

 We had this discussion a few times for various architectures (like real
 i386/i486 machines). Some software very stupidly relies on avaliable
 atomic ops for sizes that just do not make any sense, and in general it
 is better to fix the software.

 Martin

From: coypu@sdf.org
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-macppc/53380: undefined reference to `__atomic_fetch_add_8'
Date: Fri, 22 Mar 2019 19:21:18 +0000

 there's nothing stopping us from having a libatomic of our own.
 I have already a sketch for how I'd like to implement it and waiting on
 thorpej's futexes for it.

From: Jason Thorpe <thorpej@me.com>
To: gnats-bugs@netbsd.org
Cc: port-macppc-maintainer@netbsd.org,
 gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org,
 venture37@geeklan.co.uk
Subject: Re: port-macppc/53380: undefined reference to `__atomic_fetch_add_8'
Date: Fri, 22 Mar 2019 12:36:08 -0700

 > On Mar 22, 2019, at 12:25 PM, coypu@sdf.org wrote:
 >=20
 > The following reply was made to PR port-macppc/53380; it has been =
 noted by GNATS.
 >=20
 > From: coypu@sdf.org
 > To: gnats-bugs@netbsd.org
 > Cc:=20
 > Subject: Re: port-macppc/53380: undefined reference to =
 `__atomic_fetch_add_8'
 > Date: Fri, 22 Mar 2019 19:21:18 +0000
 >=20
 > there's nothing stopping us from having a libatomic of our own.
 > I have already a sketch for how I'd like to implement it and waiting =
 on
 > thorpej's futexes for it.

 We should just do it in libc where we already have a Solaris-compatible =
 atomics API.

 -- thorpej

From: Joerg Sonnenberger <joerg@bec.de>
To: gnats-bugs@netbsd.org
Cc: port-macppc-maintainer@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, venture37@geeklan.co.uk
Subject: Re: port-macppc/53380: undefined reference to `__atomic_fetch_add_8'
Date: Fri, 22 Mar 2019 21:52:59 +0100

 On Fri, Mar 22, 2019 at 07:40:01PM +0000, Jason Thorpe wrote:
 > The following reply was made to PR port-macppc/53380; it has been noted by GNATS.
 > 
 >  > there's nothing stopping us from having a libatomic of our own.
 >  > I have already a sketch for how I'd like to implement it and
 >  > waiting on
 >  > thorpej's futexes for it.
 >  
 >  We should just do it in libc where we already have a Solaris-compatible =
 >  atomics API.

 There is no reason at all to tie this to futexes. Nor is there any
 reason why this should be in libc. In fact, I strongly argue that it
 should not be in libc. As Martin said, depending on hidden locks for
 atomics is one of the most stupid design decisions in C11 and C++11.
 There are significant behavioral differences involved and it should not
 be hidden. Requiring linking another library is the least to be done.

 Joerg

State-Changed-From-To: open->closed
State-Changed-By: gutteridge@NetBSD.org
State-Changed-When: Fri, 06 Nov 2020 04:19:49 +0000
State-Changed-Why:
This has been addressed by the addition of libatomic to pkgsrc.

>Unformatted:

Home	PR Database Search