On 9/24/20 8:32 AM, Tobias Burnus wrote: > Hi all, > > we got the user comment that it is far from obvious to > use -foffload=-latomic if the following error shows up: > > unresolved symbol __atomic_compare_exchange_16 > collect2: error: ld returned 1 exit status > mkoffload: fatal error: > ..../powerpc64le-none-linux-gnu-accel-nvptx-none-gcc returned 1 exit status > > In principle, the same issue pops up with -lm and -lgfortran, > which on the host are automatically linked for g++ (-lm) and > for gfortran (both) but not gcc. > > Atomic is a bit more special as '-lm' and its functions > are better known and when compiling with gfortran and > getting 'unresolved symbol _gfortran_stop_numeric' is > also a bit more obvious. > > Thoughts? Or just better educating our users in the > documentation? — Currently, -foffload= is only documented > in the wiki ... > > For nvptx-none and libatomic, I was thinking of adding > -foffload=nvptx-none=-latomic > to the host's > libgomp/libgomp.spec(.in) > if configured with --enable-offload-targets=nvptx-none > but that assumes that nvptx-none has been configured > without --disable-atomic. – And I fail how the host > configure can see how the device configure was invoked.
Maybe we could require building libatomic for nvptx. Thanks, - Tom