On 03/03/17 13:23, Eric Botcazou wrote:
Is libbacktrace excluded from the build, or is it build but broken?
Neither, it's presumably falls back to __atomic. No big deal in any case,
since you'll presumably never use libbacktrace in practice.
We have (libgcc/config/gthr-rtems.h)
static inlin
> Is libbacktrace excluded from the build, or is it build but broken?
Neither, it's presumably falls back to __atomic. No big deal in any case,
since you'll presumably never use libbacktrace in practice.
--
Eric Botcazou
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Eric Botcazou
> Sent: Monday, February 27, 2017 10:30 PM
> To: Jan Sommer
> Cc: gcc@gcc.gnu.org; de...@rtems.org
> Subject: Re: __sync_-builtins cause undefined ref
> Is there an easy way to remove the libbacktrace dependency?
> Might something like that work?: https://patchwork.ozlabs.org/patch/553017/
Yes, even better, simply arrange for the __sync and __atomic support tests of
libbacktrace to fail on your target, possibly by using the same trick as HPUX.
On Montag, 27. Februar 2017 22:07:56 CET Eric Botcazou wrote:
> > "This __sync_() stuff seems to be used in several places in GCC. So,
> > changing libbacktrace is probably not enough. We need a general solution
> > for the __sync_() builtins on RTEMS. I don't think GCC can be changed to
> > emit _
> "This __sync_() stuff seems to be used in several places in GCC. So,
> changing libbacktrace is probably not enough. We need a general solution
> for the __sync_() builtins on RTEMS. I don't think GCC can be changed to
> emit __atomic_() calls for the __sync_() builtins (I would still try to
> as
