[dpdk-dev] Can't compile DPDK if both CONFIG_RTE_BUILD_COMBINE_LIBS and LIBRTE_PMD_XENVIRT are set to "yes"

[Sergio Gonzalez Monroy]

On 24/11/2015 13:57, Panu Matilainen wrote:
> On 11/23/2015 08:37 PM, Martinx - ジェームズ wrote:
>> Hello!
>>
>> My name is Thiago, I'm trying to compile DPDK 2.0, 2.1 and/or 2.2-rc1,
>> on Ubuntu with Xen support but, it does not build...
>>
>> Also, initially, I'm using DPDK sources from Ubuntu APT repository
>> but, it is also reproducible using upstream DPDK tarball as well,
>> explained as follows:
>>
>> Problem:
>>
>> * It is not possible to use the following DPDK options at the same time:
>>
>> CONFIG_RTE_BUILD_COMBINE_LIBS
>> LIBRTE_PMD_XENVIRT
>>
>> Ubuntu DPDK .deb package uses CONFIG_RTE_BUILD_COMBINE_LIBS and,
>> without it, it can't build its .deb binary package (step: "make -f
>> debian/rules binary" doesn't work).
>>
>> So, if you have the above two options set to "yes", the following
>> error appear while building DPDK:
>>
>> http://pastebin.com/xUsQPxh8
>>
> [...]
>> Build error:
>>
>> http://pastebin.com/fuUkpF4w
>>
>> If you remove "CONFIG_RTE_BUILD_COMBINE_LIBS", then, you can build it
>> with "LIBRTE_PMD_XENVIRT", and vice-versa. But, without
>> "...COMBINE_LIBS", Ubuntu .deb package doesn't get builded.
>>
>> BTW, the option LIBRTE_XEN_DOM0 is fine when also enabling 
>> COMBINE_LIBS...
>>
>> Am I missing something? Is this by design or a DPDK bug?
>
> DPDK bug I would say. The combined library has been increasingly in 
> risk of collapsing under its own weight for some time now.
>
> A much better way of achieving the same is using a so called linker 
> script which is essentially just an ascii file listing all the 
> individual libraries which the linker handles behind the scenes.
> FWIW, that's how the combined library is packaged on Fedora and RHEL 
> and consumers like OVS and pktgen never knew the difference.
>
> The linker script approach has been suggested before but somehow the 
> threads died without nothing actually happening. I'll revive the patch 
> and post here shortly. Unless Sergio (cc'd) who previously worked on 
> the patches has a newer version cooking silently?
>
I haven't worked on it since,  so you probably are in a better position 
to continue the work than me.

Sergio
> P.S. I know, a "linker script" sounds exotic but they're actually 
> rather commonplace. On an average Linux system, libc.so is a linker 
> script for example.
>
>     - Panu -