[dpdk-dev] [Bug 87] build dpdk and example with different gcc version issue

Jerin Jacob jerin.jacob at caviumnetworks.com
Fri Aug 31 19:08:34 CEST 2018


-----Original Message-----
> Date: Fri, 31 Aug 2018 11:04:06 +0100
> From: Ferruh Yigit <ferruh.yigit at intel.com>
> To: bugzilla at dpdk.org, dev at dpdk.org, Jerin Jacob
>  <jerin.jacob at caviumnetworks.com>, Santosh Shukla
>  <santosh.shukla at caviumnetworks.com>
> CC: Ajit Khaparde <ajit.khaparde at broadcom.com>, Thomas Monjalon
>  <thomas at monjalon.net>
> Subject: Re: [dpdk-dev] [Bug 87] build dpdk and example with different gcc
>  version issue
> User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
>  Thunderbird/52.9.1
> 
> 
> On 8/31/2018 4:28 AM, bugzilla at dpdk.org wrote:
> > https://bugs.dpdk.org/show_bug.cgi?id=87
> >
> >             Bug ID: 87
> >            Summary: build dpdk and example with different gcc version
> >                     issue
> >            Product: DPDK
> >            Version: unspecified
> >           Hardware: x86
> >                 OS: FreeBSD
> >             Status: CONFIRMED
> >           Severity: minor
> >           Priority: Low
> >          Component: other
> >           Assignee: dev at dpdk.org
> >           Reporter: xuemingx.zhang at intel.com
> >   Target Milestone: ---
> >
> > we try different gcc version,results are as follows:
> >
> > 1、Compiled successfully
> > # gmake install -j1 T=x86_64-native-bsdapp-gcc CC=gcc48
> > # gmake examples -j1 T=x86_64-native-bsdapp-gcc CC=gcc48
> >
> > 2、Compiled successfully
> > # gmake install -j1 T=x86_64-native-bsdapp-gcc
> > # gmake examples -j1 T=x86_64-native-bsdapp-gcc
> >
> > 3、Compiled successfully
> > # gmake install -j1 T=x86_64-native-bsdapp-gcc
> > # gmake examples -j1 T=x86_64-native-bsdapp-gcc CC=gcc48
> >
> > 4、Compile failed
> > # gmake install -j1 T=x86_64-native-bsdapp-gcc CC=gcc48
> > # gmake examples -j1 T=x86_64-native-bsdapp-gcc
> > error message:
> > ================== Build examples for x86_64-native-bsdapp-gcc ==
> > bbdev_app
> >    CC main.o
> >    LD bbdev
> > /usr/local/bin/ld: cannot find -lrte_common_octeontx
> > collect2: error: ld returned 1 exit status
> > gmake[4]: *** [/root/meijuan/dpdk/mk/rte.app.mk:365: bbdev] Error 1
> > gmake[3]: *** [/root/meijuan/dpdk/mk/rte.extapp.mk:15: all] Error 2
> > gmake[2]: *** [/root/meijuan/dpdk/mk/rte.extsubdir.mk:22: bbdev_app]
> > Error 2
> > gmake[1]: *** [/root/meijuan/dpdk/mk/rte.sdkexamples.mk:26: x86_64-
> > native-bsdapp-gcc_examples] Error 2
> > gmake: *** [/root/meijuan/dpdk/mk/rte.sdkroot.mk:96: examples] Error 2
> >
> 
> Hi Jerin, Santosh,
> 
> This is because rte_common_octeontx is not compiled when gcc 4.8.5 used [1], and
> when compiling examples with gcc 5.4 it assumes rte_common_octeontx compiled and
> tries to link app with it which fails.
> 
> These specific compiler version conditions shouldn't break build for others.
> 
> To assign defect you guys, can you please bu sure registered into Bugzilla?

I assigned to me. It is more of DPDK build infrastructure issue not the
driver issue.

Is it a real use case ? I don't think, there is a straight forward way to fix
this. I think, I have two options.

1) Have something like below to detect the presence of library file.
it looks ugly to me. Do we have any better solution?

diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index de33883be..f998141c7 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -7,6 +7,16 @@ include $(RTE_SDK)/mk/internal/rte.install-pre.mk
 include $(RTE_SDK)/mk/internal/rte.clean-pre.mk
 include $(RTE_SDK)/mk/internal/rte.build-pre.mk
 
+ifeq ("$(wildcard $((RTE_SDK_BIN)/lib/librte_pmd_octeontx_ssovf*))","")
+CONFIG_RTE_LIBRTE_PMD_OCTEONTX_SSOVF=d
+endif
+ifeq ("$(wildcard $((RTE_SDK_BIN)/lib/librte_mempool_octeontx*))","")
+CONFIG_RTE_LIBRTE_OCTEONTX_MEMPOOL=d
+endif
+ifeq ("$(wildcard $((RTE_SDK_BIN)/lib/librte_pmd_octeontx*))","")
+CONFIG_RTE_LIBRTE_OCTEONTX_PMD=d
+endif
+

2) Actually rte_common_octeontx does not really using any of  the fancy feature of
gcc 4.8.5. There was bug in gcc 4.8.5 on aarch64 which cause compiler to
emit "internal compiler error". So it a bug in the compiler not in
the driver.

I don't think, any production DPDK system is using gcc 4.8.5 on arm64.
So one option to revert 4f760550a0935632cf262d6955ac4d25bc260545 change to
fix the issue.

Adding Ali Alnubani <alialnu at mellanox.com> for his comments as he was using
buggy gcc 4.8.5 compiler on arm64


Thoughts?

> 
> Thanks,
> ferruh
> 
> [1]
> https://git.dpdk.org/dpdk/tree/mk/toolchain/gcc/rte.toolchain-compat.mk?h=v18.08#n84
> https://git.dpdk.org/dpdk/tree/drivers/common/Makefile?h=v18.08#n7


More information about the dev mailing list