[Pkg-dpdk-devel] not-so-multiarch

[Luca Boccassi]

On Tue, 2017-07-04 at 07:01 +0200, Christian Ehrhardt wrote:
> Hi,
> Luca and I were discussing working on a change to make the headers
> really
> as multiarch as they should be.
> Yet it turns out things are not always so easy.
> 
> If a dpdk consuming project has uses pkg-config all the time it is
> likely
> good.
> But if not there are multiple hurdles:
> 1. it must implement pkg-config for dpdk to get the new options for
> libs/cflags
> 2. it must work with the new path setup
> 
> Openvswitch-dpdk is one example that has no pkg-config at the moment.
> We tried to modify the config [1] but so far had no full success [2]
> so far.
> Note: I guess the extra -include is wrong in
> "-I-include /usr/include/x86_64-linux-gnu/dpdk/rte_config.h
> -I/usr/include/dpdk -I/usr/include/x86_64-linux-gnu/dpdk"

I think OVS's autoconf is doing something naughty there. This is the
pre-existing line:

DPDK_INCLUDE="/usr/local/include/dpdk -I/usr/include/dpdk"

It has a path as the first half, without a -I. So I assume that
somewhere else down the line it does something silly such as:

-I$DPDK_INCLUDE

Which would explain why it gets an extra -I: -I-include /usr/...

If you also fix that to move the -I together with the path, as it
should be, it should then work.

> But while working on it it got me thinking if that is the right
> approach at
> all.
> There might be a random number of projects out there depending on the
> paths
> just as upstream DPDK creates them and those are unfortunately not
> "/usr/include/ARCH".
> We discussed and agreed that it would be a shame, to make all of the
> headers non multiarch, but I had another idea.
> 
> How about splitting "libdpdk-dev" into a
> - libdpdk-dev-generic
> - libdpdk-dev
> 
> This could of course also be
> - libdpdk-dev
> - libdpdk-dev-arch
> if preferred.
> 
> In any case one of them would be arch specific just holding the
> critical
> files.
> The other would stay out real multiarch package with most of the
> files.
> That way depending projects can work as-is and we get a proper
> multiarch
> -dev package.
> 
> Opinions?

The problem with multiarch is that it's a pretty much an all-or-nothing 
affair - either the dev library is multi-arch, or is not. Unfortunately
having only half of it multiarch compliant doesn't solve much, as it
still means it cannot be used in a multiarch setting.

Especially in the DPDK case, where rte_config.h is a mandatory header
(hence its special treatment of automatic inclusion via -include) but
it's architecture dependent.

-- 
Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-dpdk-devel/attachments/20170704/31913b36/attachment-0001.sig>