Andrzej Ostruszka <a...@semihalf.com> writes: > On 10/29/19 3:12 PM, Andrzej Ostruszka wrote: >> This patch series adds an option to make use of link time optimization >> (if compiler has support for it). > [...] >> .travis.yml | 7 ++++ > [...] > > Aaron, Michael, all > > I'd probably need some assistance with Travis. This patchset added > following changes: > > diff --git a/.travis.yml b/.travis.yml > index 3d6ef2959..3cd746dba 100644 > --- a/.travis.yml > +++ b/.travis.yml > @@ -34,6 +34,7 @@ env: > - DEF_LIB="static" OPTS="-Denable_kmods=false" > - DEF_LIB="shared" OPTS="-Denable_kmods=false" > - DEF_LIB="shared" RUN_TESTS=1 > + - DEF_LIB="shared" OPTS="-Db_lto=true" > > matrix: > include: > @@ -105,6 +106,12 @@ matrix: > apt: > packages: > - *extra_packages > + - env: DEF_LIB="shared" OPTS="-Db_lto=true" EXTRA_PACKAGES=1 > + compiler: gcc > + addons: > + apt: > + packages: > + - *extra_packages > > > however I have to admit I'm not familiar with Travis and the actual > meaning of that configuration (that is it's actual mapping to builds). > I'm getting following CI errors: > > 1. https://travis-ci.com/ovsrobot/dpdk/jobs/250599578 > > This is with clang - this patchset should not be run with clang as it is > not supported. In build "matrix" there is 'gcc' specified but somehow > clang build is attempted. Please advice me how to change this > .travis.yml to stop that - should I remove entry in "env"?
Yes, do not use the non-matrix defines. IE: drop the hunk '@@ -34,6 +34,7 @@ env:' The other hunk '@@ -105,6 +106,12 @@ matrix:' is sufficient. You might want a secondary copy that includes AARCH64=1 if fat LTO is supported under ARM64 (assuming there's a benefit to doing this build). > 2. https://travis-ci.com/ovsrobot/dpdk/jobs/250599577 > https://travis-ci.com/ovsrobot/dpdk/jobs/250599591 > > This is with gcc and meson with shared library and I can't reproduce > this. The are two problems reported, first a compiler warning which > seems to be not connected at all with the changes: These jobs are running on ubuntu xenial, using gcc 5.4.0 compiler. Are you sure that you've passed all of the requisite linker flags for this version of gcc? Alternatively, you can make a package list that will include a version of the compiler you expect to support. But that should also be reflected in the documentation. I didn't see any compiler restrictions documented. > --8<------------------------ > /usr/include/x86_64-linux-gnu/bits/unistd.h:39:9: warning: call to > ‘__read_chk_warn’ declared with attribute warning: read called with > bigger length than size of the destination buffer > return __read_chk (__fd, __buf, __nbytes, __bos0 (__buf)); > ^ > In function ‘__read_alias’, > inlined from ‘eal_intr_process_interrupts’ at > ../lib/librte_eal/linux/eal/eal_interrupts.c:911:17, > inlined from ‘eal_intr_handle_interrupts’ at > ../lib/librte_eal/linux/eal/eal_interrupts.c:1030:7, > inlined from ‘eal_intr_thread_main’ at > ../lib/librte_eal/linux/eal/eal_interrupts.c:1100:3: > --8<------------------------ > > and a second linker error: > > --8<------------------------ > FAILED: gcc -o lib/librte_lpm.so.2.1 > 'lib/76b5a35@@rte_lpm@sha/librte_lpm_rte_lpm.c.o' > 'lib/76b5a35@@rte_lpm@sha/librte_lpm_rte_lpm6.c.o' -flto -Wl,--as-needed > -Wl,--no-undefined -Wl,-O1 -shared -fPIC -Wl,--start-group > -Wl,-soname,librte_lpm.so.2 -Wl,--no-as-needed -pthread -lm -ldl -lnuma > -Wno-lto-type-mismatch lib/librte_eal.so.12.1 lib/librte_kvargs.so.1.1 > lib/librte_hash.so.2.1 lib/librte_ring.so.2.1 > -Wl,--version-script=/home/travis/build/ovsrobot/dpdk/lib/librte_lpm/rte_lpm_version.map > /usr/lib/x86_64-linux-gnu/libbsd.so -Wl,--end-group > '-Wl,-rpath,$ORIGIN/' > -Wl,-rpath-link,/home/travis/build/ovsrobot/dpdk/build/lib > /tmp/ccZPEQKf.ltrans3.ltrans.o: In function `rte_lpm6_delete_bulk_func': > <artificial>:(.text+0xf01): undefined reference to `rte_lpm6_add' > --8<------------------------ > > As I've said I can't reproduce none of these problems - are they some CI > issues? Can you try to reproduce this with a stock xenial image? If I get the chance, I will do the same. > I'd appreciate some help with these. > > Regards > Andrzej
