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

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 8/31/2018 6:08 PM, Jerin Jacob wrote:
> -----Original Message-----
>> Date: Fri, 31 Aug 2018 11:04:06 +0100
>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>> To: bugzilla@dpdk.org, dev@dpdk.org, Jerin Jacob
>>  <jerin.jacob@caviumnetworks.com>, Santosh Shukla
>>  <santosh.shukla@caviumnetworks.com>
>> CC: Ajit Khaparde <ajit.khaparde@broadcom.com>, Thomas Monjalon
>>  <thomas@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@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@dpdk.org
>>>           Reporter: xuemingx.zhang@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.

There is no usecase, but this is something automated build hit, unintentionally.

> 
> 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
> +

I think no need to add ugly exception checks for this issue.

Checks in rte.toolchain-compat.mk, changes config values on the fly for that
session, that is why next build thinks they are enabled again.

Does it help to reflect those changes in the .config file itself?

> 
> 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@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