meta-riscv: building curl, "undefined reference to '__atomic_exchange_1'


Robert P. J. Day
 

on admittedly unsupported ubuntu 22.04 platform but it's clear this
is a known issue as it's pretty much identical to what one reads here:

https://github.com/advancedtelematic/aktualizr/issues/1427

the explanation being that, "not every atomic operation is currently
supported by GCC on RISC-V."

oddly, building a riscv64 core-image-minimal once upon a time on
fedora worked just fine, so i'm assuming a difference in gcc versions
is what is causing this.

what is the recommended workaround for this?

rday


Robert P. J. Day
 

On Thu, 7 Jul 2022, Robert P. J. Day wrote:


on admittedly unsupported ubuntu 22.04 platform but it's clear this
is a known issue as it's pretty much identical to what one reads here:

https://github.com/advancedtelematic/aktualizr/issues/1427

the explanation being that, "not every atomic operation is currently
supported by GCC on RISC-V."

oddly, building a riscv64 core-image-minimal once upon a time on
fedora worked just fine, so i'm assuming a difference in gcc versions
is what is causing this.

what is the recommended workaround for this?
another data point, matches exactly what i'm referring to:

https://github.com/curl/curl/issues/9055

rday


Khem Raj
 

On Thu, Jul 7, 2022 at 6:14 AM Robert P. J. Day <rpjday@...> wrote:

On Thu, 7 Jul 2022, Robert P. J. Day wrote:


on admittedly unsupported ubuntu 22.04 platform but it's clear this
is a known issue as it's pretty much identical to what one reads here:

https://github.com/advancedtelematic/aktualizr/issues/1427

the explanation being that, "not every atomic operation is currently
supported by GCC on RISC-V."

oddly, building a riscv64 core-image-minimal once upon a time on
fedora worked just fine, so i'm assuming a difference in gcc versions
is what is causing this.

what is the recommended workaround for this?
another data point, matches exactly what i'm referring to:

https://github.com/curl/curl/issues/9055
does backporting

https://github.com/curl/curl/commit/50efb0822aa0e0ab165158dd0a26e65a2290e6d2

to curl help ?


rday



Robert P. J. Day
 

On Thu, 7 Jul 2022, Khem Raj wrote:

On Thu, Jul 7, 2022 at 6:14 AM Robert P. J. Day <rpjday@...> wrote:

On Thu, 7 Jul 2022, Robert P. J. Day wrote:


on admittedly unsupported ubuntu 22.04 platform but it's clear this
is a known issue as it's pretty much identical to what one reads here:

https://github.com/advancedtelematic/aktualizr/issues/1427

the explanation being that, "not every atomic operation is currently
supported by GCC on RISC-V."

oddly, building a riscv64 core-image-minimal once upon a time on
fedora worked just fine, so i'm assuming a difference in gcc versions
is what is causing this.

what is the recommended workaround for this?
another data point, matches exactly what i'm referring to:

https://github.com/curl/curl/issues/9055
does backporting

https://github.com/curl/curl/commit/50efb0822aa0e0ab165158dd0a26e65a2290e6d2

to curl help ?
it does indeed fix the curl build error, thanks. i haven't tested
its operation yet, but getting a build was all i was after at the
moment.

rday


Robert P. J. Day
 

On Thu, 7 Jul 2022, Khem Raj wrote:

On Thu, Jul 7, 2022 at 6:14 AM Robert P. J. Day <rpjday@...> wrote:

On Thu, 7 Jul 2022, Robert P. J. Day wrote:


on admittedly unsupported ubuntu 22.04 platform but it's clear this
is a known issue as it's pretty much identical to what one reads here:

https://github.com/advancedtelematic/aktualizr/issues/1427

the explanation being that, "not every atomic operation is currently
supported by GCC on RISC-V."

oddly, building a riscv64 core-image-minimal once upon a time on
fedora worked just fine, so i'm assuming a difference in gcc versions
is what is causing this.

what is the recommended workaround for this?
another data point, matches exactly what i'm referring to:

https://github.com/curl/curl/issues/9055
does backporting

https://github.com/curl/curl/commit/50efb0822aa0e0ab165158dd0a26e65a2290e6d2

to curl help ?
as i read it, this issue is also related to -pthread versus
-lpthread:

https://blog.jiejiss.com/A-RISC-V-gcc-pitfall-revealed-by-a-glibc-update/

rday


Khem Raj
 

On Thu, Jul 7, 2022 at 1:06 PM Robert P. J. Day <rpjday@...> wrote:

On Thu, 7 Jul 2022, Khem Raj wrote:

On Thu, Jul 7, 2022 at 6:14 AM Robert P. J. Day <rpjday@...> wrote:

On Thu, 7 Jul 2022, Robert P. J. Day wrote:


on admittedly unsupported ubuntu 22.04 platform but it's clear this
is a known issue as it's pretty much identical to what one reads here:

https://github.com/advancedtelematic/aktualizr/issues/1427

the explanation being that, "not every atomic operation is currently
supported by GCC on RISC-V."

oddly, building a riscv64 core-image-minimal once upon a time on
fedora worked just fine, so i'm assuming a difference in gcc versions
is what is causing this.

what is the recommended workaround for this?
another data point, matches exactly what i'm referring to:

https://github.com/curl/curl/issues/9055
does backporting

https://github.com/curl/curl/commit/50efb0822aa0e0ab165158dd0a26e65a2290e6d2

to curl help ?
as i read it, this issue is also related to -pthread versus
-lpthread:
this would mean that you want to rely on side effects of -pthread
which may work with gcc but may not
work with clang or other compiler drivers. The issue you have is that
some variables are needing atomics
and solution is either you link with libatomic or avoid using the code
which needs them

https://blog.jiejiss.com/A-RISC-V-gcc-pitfall-revealed-by-a-glibc-update/

rday


Robert P. J. Day
 

On Thu, 7 Jul 2022, Khem Raj wrote:

On Thu, Jul 7, 2022 at 1:06 PM Robert P. J. Day <rpjday@...> wrote:

On Thu, 7 Jul 2022, Khem Raj wrote:

On Thu, Jul 7, 2022 at 6:14 AM Robert P. J. Day <rpjday@...> wrote:

On Thu, 7 Jul 2022, Robert P. J. Day wrote:


on admittedly unsupported ubuntu 22.04 platform but it's clear this
is a known issue as it's pretty much identical to what one reads here:

https://github.com/advancedtelematic/aktualizr/issues/1427

the explanation being that, "not every atomic operation is currently
supported by GCC on RISC-V."

oddly, building a riscv64 core-image-minimal once upon a time on
fedora worked just fine, so i'm assuming a difference in gcc versions
is what is causing this.

what is the recommended workaround for this?
another data point, matches exactly what i'm referring to:

https://github.com/curl/curl/issues/9055
does backporting

https://github.com/curl/curl/commit/50efb0822aa0e0ab165158dd0a26e65a2290e6d2

to curl help ?
as i read it, this issue is also related to -pthread versus
-lpthread:
this would mean that you want to rely on side effects of -pthread
which may work with gcc but may not
work with clang or other compiler drivers. The issue you have is that
some variables are needing atomics
and solution is either you link with libatomic or avoid using the code
which needs them

https://blog.jiejiss.com/A-RISC-V-gcc-pitfall-revealed-by-a-glibc-update/
so while i'm still trying to wrap my head around all this, what
*would* be the ideal resolution for this? the link above suggests the
simple solution of introducing a gcc config option
"--always-link-libatomic". would that solve all this in a general way,
not just for RISC-V?

rday


Khem Raj
 



On Thu, Jul 7, 2022 at 2:01 PM Robert P. J. Day <rpjday@...> wrote:
On Thu, 7 Jul 2022, Khem Raj wrote:

> On Thu, Jul 7, 2022 at 1:06 PM Robert P. J. Day <rpjday@...> wrote:
> >
> > On Thu, 7 Jul 2022, Khem Raj wrote:
> >
> > > On Thu, Jul 7, 2022 at 6:14 AM Robert P. J. Day <rpjday@...> wrote:
> > > >
> > > > On Thu, 7 Jul 2022, Robert P. J. Day wrote:
> > > >
> > > >
> > > > >   on admittedly unsupported ubuntu 22.04 platform but it's clear this
> > > > > is a known issue as it's pretty much identical to what one reads here:
> > > > >
> > > > >   https://github.com/advancedtelematic/aktualizr/issues/1427
> > > > >
> > > > > the explanation being that, "not every atomic operation is currently
> > > > > supported by GCC on RISC-V."
> > > > >
> > > > >   oddly, building a riscv64 core-image-minimal once upon a time on
> > > > > fedora worked just fine, so i'm assuming a difference in gcc versions
> > > > > is what is causing this.
> > > > >
> > > > >   what is the recommended workaround for this?
> > > >
> > > >   another data point, matches exactly what i'm referring to:
> > > >
> > > >   https://github.com/curl/curl/issues/9055
> > > >
> > >
> > > does backporting
> > >
> > > https://github.com/curl/curl/commit/50efb0822aa0e0ab165158dd0a26e65a2290e6d2
> > >
> > > to curl help ?
> >
> >   as i read it, this issue is also related to -pthread versus
> > -lpthread:
> >
>
> this would mean that you want to rely on side effects of -pthread
> which may work with gcc but may not
> work with clang or other compiler drivers. The issue you have is that
> some variables are needing atomics
> and solution is either you link with libatomic or avoid using the code
> which needs them
>
> > https://blog.jiejiss.com/A-RISC-V-gcc-pitfall-revealed-by-a-glibc-update/

  so while i'm still trying to wrap my head around all this, what
*would* be the ideal resolution for this? the link above suggests the
simple solution of introducing a gcc config option
"--always-link-libatomic". would that solve all this in a general way,
not just for RISC-V?

Probably, but again if you need a function from a library you include it on linker cmdline if it’s intrinsics then compiler driver doing the needed is best way 
Preferably without introducing compiler specific options 


rday