Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 15 Jan 2018 17:08:58 +0000
From:      David Chisnall <theraven@FreeBSD.org>
To:        Jan Beich <jbeich@FreeBSD.org>, Ed Maste <emaste@FreeBSD.org>
Cc:        Tijl Coosemans <tijl@FreeBSD.org>, Luca Pizzamiglio <pizzamig@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org>, freebsd-ports@freebsd.org
Subject:   Re: atomic in i386 Current after CLANG 6 upgrade
Message-ID:  <03DDFE7A-B5FE-4DE5-98D8-AF28EFDDFACF@FreeBSD.org>
In-Reply-To: <mv1f-jbvo-wny@FreeBSD.org>
References:  <CAB88xy96bTtauBJtZyRbZCVDgKtgpv%2BQiZ29aWqe%2B_dud9domA@mail.gmail.com> <20180115125756.37b803ba@kalimero.tijl.coosemans.org> <mv1f-jbvo-wny@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 15 Jan 2018, at 17:00, Jan Beich <jbeich@FreeBSD.org> wrote:
>=20
> It wouldn't help (see below). Clang 6 accidentally made __atomic* work
> enough to satisfy configure check but not for the port to build. I =
guess,
> it also confuses configure in net/librdkafka and net-mgmt/netdata.
>=20

Can we (by which I probably mean emaste@) push out an EN that adds the =
atomic.c from compiler-rt to our libgcc_s?  That should provide all of =
these helper functions.  Clang assumes that they exist because both =
compiler-rt and vaguely recent libgcc_s provide them.  Recent GCC will =
also assume that they exist and so the correct fix is probably for us to =
make them to exist.

If this is difficult, then we can perhaps provide a port that compiles =
atomic.c into libatomic_fudge.so or similar and provides a libgcc_s.so =
that=E2=80=99s a linker script that forces linking to libatomic_fudge.so =
and libgcc_s.so.

David




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?03DDFE7A-B5FE-4DE5-98D8-AF28EFDDFACF>