Hi, The GCC5.3.1 is a Linaro's GCC, maybe it is more of a question to Linaro as this crosstools version doesn't compile well with the linux-generic implementation in ODP1.15 due to the need for libatomic.
Liron -----Original Message----- From: Brian Brooks [mailto:brian.bro...@linaro.org] Sent: Tuesday, October 24, 2017 23:34 To: Liron Himi <lir...@marvell.com> Subject: Re: [EXT] Re: [lng-odp] ODP1.15 with gcc-linaro-5.3.1 Hi Liron, I am not familiar with your crosstools environment. That is why I asked if support for libatomic needs to be enabled. The ODP build will simply try to -latomic. Brian On Tue, Oct 24, 2017 at 8:57 AM, Liron Himi <lir...@marvell.com> wrote: > Hi Brian, > > > > See comments in RED > > > > Liron > > -----Original Message----- > > From: Liron Himi > > Sent: Wednesday, October 18, 2017 21:01 > > To: Brian Brooks <brian.bro...@linaro.org> > > Cc: Liron Himi <lir...@marvell.com> > > Subject: RE: [EXT] Re: [lng-odp] ODP1.15 with gcc-linaro-5.3.1 > > > > Hi Brian, > > > > See inline > > > > -----Original Message----- > > From: Brian Brooks [mailto:brian.bro...@linaro.org] > > Sent: Wednesday, October 18, 2017 20:43 > > To: Liron Himi <lir...@marvell.com> > > Cc: lng-odp@lists.linaro.org > > Subject: Re: [EXT] Re: [lng-odp] ODP1.15 with gcc-linaro-5.3.1 > > > > checking for GCC atomic builtins... yes > > checking whether -latomic is needed for 64-bit atomic built-ins... no > checking whether -latomic is needed for 128-bit atomic built-ins... > yes > > > > So, GCC 5.3.1 will not lower __atomic/__sync builtins on a 128-bit > data type to machine instructions, and instead emit a call to a > function (which is assumed to be provided by libatomic). > > > > There is some timer and scheduler code that makes use of atomics on > 128-bit types. > > > > Can you enable libatomic in the crosstools environment? > > [L.H.] Not sure I understood what do you mean? The libatomic.a/.so is > located in both aarch64-linux-gnu/lib64 and aarch64-linux-gnu/libc/lib. > > The problem is with the libatomic.la where the setting of LIBDIR is to > some weird location. > > > > Note that with GCC 7.1.1 (latest release) there is no problem, and I > also noticed that libatomic.la is not there anymore > > > > > > On Wed, Oct 18, 2017 at 11:51 AM, Liron Himi <lir...@marvell.com> wrote: > >> Hi Brian, > >> > >> I attached full configure output. > >> > >> Liron > >> > >> -----Original Message----- > >> From: Brian Brooks [mailto:brian.bro...@linaro.org] > >> Sent: Wednesday, October 18, 2017 18:50 > >> To: Liron Himi <lir...@marvell.com> > >> Cc: lng-odp@lists.linaro.org > >> Subject: [EXT] Re: [lng-odp] ODP1.15 with gcc-linaro-5.3.1 > >> > >> External Email > >> > >> --------------------------------------------------------------------- >> - > >> Hi Liron, > >> > >> Can you paste a full copy of the ./configure output? > >> > >> Brian > >> > >> On Wed, Oct 18, 2017 at 9:58 AM, Liron Himi <lir...@marvell.com> wrote: > >>> Hi, > >>> > >>> We are using 'gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu' as >>> our tool-chain. > >>> When I compile ODP1.15 with it I get a lot of: > >>> 'libtool: warning: library >>> '/home/userlab/work/crosstools/gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/lib64/libatomic.la' >>> was moved.' > >>> > >>> The main problem is that we have another package that uses our ODP > >>> outcome and it doesn't compile due to > >>> '/bin/sed: can't read >>> /home/tcwg-buildslave/workspace/tcwg-make-release/label/docker-trusty-amd64-tcwg/target/aarch64-linux-gnu/_build/builds/destdir/x86_64-unknown-linux-gnu/aarch64-linux-gnu/lib/../lib64/libatomic.la: >>> No such file or directory > >>> libtool: error: >>> '/home/tcwg-buildslave/workspace/tcwg-make-release/label/docker-trusty-amd64-tcwg/target/aarch64-linux-gnu/_build/builds/destdir/x86_64-unknown-linux-gnu/aarch64-linux-gnu/lib/../lib64/libatomic.la' >>> is not a valid libtool archive' > >>> > >>> I notice that it is related to added lines (compared to ODP1.11) in >>> 'linux-generic/m4/configure.m4'. > >>> dnl Check whether -latomic is needed > >>> use_libatomic=no > >>> > >>> AC_MSG_CHECKING(whether -latomic is needed for 64-bit atomic > >>> built-ins) AC_LINK_IFELSE( > >>> [AC_LANG_SOURCE([[ > >>> static int loc; > >>> int main(void) > >>> { > >>> int prev = __atomic_exchange_n(&loc, 7, __ATOMIC_RELAXED); > >>> return 0; > >>> } > >>> ]])], > >>> [AC_MSG_RESULT(no)], > >>> [AC_MSG_RESULT(yes) > >>> AC_CHECK_LIB( > >>> [atomic], [__atomic_exchange_8], > >>> [use_libatomic=yes], > >>> [AC_MSG_FAILURE([__atomic_exchange_8 is not available])]) > >>> ]) > >>> > >>> AC_MSG_CHECKING(whether -latomic is needed for 128-bit atomic > >>> built-ins) AC_LINK_IFELSE( > >>> [AC_LANG_SOURCE([[ > >>> static __int128 loc; > >>> int main(void) > >>> { > >>> __int128 prev; > >>> prev = __atomic_exchange_n(&loc, 7, __ATOMIC_RELAXED); > >>> return 0; > >>> } > >>> ]])], > >>> [AC_MSG_RESULT(no)], > >>> [AC_MSG_RESULT(yes) > >>> AC_CHECK_LIB( > >>> [atomic], [__atomic_exchange_16], > >>> [use_libatomic=yes], > >>> [AC_MSG_CHECKING([cannot detect support for 128-bit atomics])]) > >>> ]) > >>> > >>> if test "x$use_libatomic" = "xyes"; then > >>> ATOMIC_LIBS="-latomic" > >>> fi > >>> AC_SUBST([ATOMIC_LIBS]) > >>> > >>> > >>> Is there anything I can do with 5.3.1 except of removing the new >>> lines in configure.m4? > >>> > >>> Thanks, > >>> Liron
