[Buildroot] [arc-buildroot] [autobuild.buildroot.net] Analysis of build results
Alexey Brodkin
Alexey.Brodkin at synopsys.com
Wed Aug 19 20:31:17 UTC 2020
Hi Thomas, all,
> > arc | log4cplus-2.0.5 | NOK | http://autobuild.buildroot.net/results/a7732fdb2ba526a114d9fb759814236c5332f8d7/ |
>
> undefined reference to `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)'
>
> This is happening only on ARC700. Perhaps a variant of ARC that doesn't
> support atomic instructions?
>
> ARC maintainers, could you have a look please ?
>
> > arc | wampcc-1.6 | NOK | http://autobuild.buildroot.net/results/c3b67d8a5faf7ff06b08a0591f22b1fa4963c2ee/ | ORPH
>
> /home/test/autobuild/run/instance-3/output-1/host/lib/gcc/arc-buildroot-linux-uclibc/9.3.1/../../../../arc-buildroot-linux-uclibc/bin/ld: ../libs/wampcc/libwampcc.so.6.0.0: undefined reference to `std::__atomic_futex_unsigned_base::_M_futex_notify_all(unsigned int*)'
> collect2: error: ld returned 1 exit status
>
> This looks very similar to the log4cplus build issue above, also
> happens only on ARC: http://autobuild.buildroot.net/?reason=wampcc-1.6
>
> ARC maintainers, could you have a look ?
Ok so that happens because of misconfiguration of libstdc++.
When it gets configured we use not true final Buildroot's GCC (read-on...)
but just an intermediate "xgcc". And so when libstdc++ is checking for
atomics support it gets this:
-------------------------------->8-----------------------------
cat << EOF > /tmp/yourfilehere
int
main ()
{
#if __GCC_ATOMIC_INT_LOCK_FREE <= 1
# error atomic int not always lock free
#endif
return 0;
}
EOF
configure:81594: .../output/build/host-gcc-final-arc-2020.03-release/build/./gcc/xgcc \
-B.../output/build/host-gcc-final-arc-2020.03-release/build/./gcc/ \
-B.../output/host/arc-buildroot-linux-uclibc/bin/ \
-B.../output/host/arc-buildroot-linux-uclibc/lib/ \
-isystem .../output/host/arc-buildroot-linux-uclibc/include \
-isystem .../output/host/arc-buildroot-linux-uclibc/sys-include \
-c -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os conftest.c >&5
conftest.c: In function 'main':
conftest.c:240:13: error: #error atomic int not always lock free
240 | # error atomic int not always lock free
| ^~~~~
-------------------------------->8-----------------------------
And that's because "xgcc" uses its default configuration, i.e. "-mcpu=arc700",
and this one is w/o atomics. To make GCC using atomics we need to pass an extra option
to the driver with "-matomics" and... we do it via wrapper, see:
-------------------------------->8-----------------------------
strace -s 1000 .../output/host/bin/arc-linux-gcc -c test.c 2> >(grep execve)
execve(".../output/host/bin/arc-linux-gcc", [".../output/host/bin/arc-linux-gcc", "-c", "test.c"], [/* 136 vars */]) = 0
execve(".../output/host/bin/arc-linux-gcc.br_real", [".../output/host/bin/arc-linux-gcc.br_real", "--sysroot", ".../output/host/arc-buildroot-linux-uclibc/sysroot", "-matomic", "-Wl,-z,max-page-size=8192", "-c", "test.c"], [/* 136 vars */]) = 0
-------------------------------->8-----------------------------
Note how "arc-linux-gcc" nicely takes care of implicit handling of extra options.
So I guess it's clear what was the reason. What's not clear is how to solve
that problem properly, any guesses/hints?
In the meantime I'll be looking at opencv issues.
-Alexey
More information about the buildroot
mailing list