[Pkg-dpdk-devel] Odd issues in testlinkage.bin on Debian
Christian Ehrhardt
christian.ehrhardt at canonical.com
Tue Mar 13 09:17:36 UTC 2018
Hi,
the last fix I submitted really looked good on Ubuntu, but never the less
on Debian 17.11.1 is still broken.
I realized that the new zlib dependency fixed the lack of -lz we had (fine).
But the use of pkg-config brought more.
Note: the test that fails is looking for pthread as 2nd level dependency,
which became a 1st level dependency due to lniking that much directly.
In my case I formerly essentially run the old test against the new upload.
That gives me:
Linkage info
COLLECT_GCC_OPTIONS='-v' '-o' 'testlinkage.bin' '-Wall' '-Werror'
'-include' '/usr/include/x86_64-linux-gnu/dpdk/rte_config.h' '-I'
'/usr/include/
x86_64-linux-gnu/dpdk' '-I' '/usr/include/dpdk' '-mtune=generic'
'-march=x86-64'
testlinkage.bin => ./testlinkage.bin (interpreter =>
/lib64/ld-linux-x86-64.so.2)
librte_eal.so.17.11 => /usr/lib/x86_64-linux-gnu/librte_eal.so.17.11
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1
ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
Which works fine, but due to the use of pkg-config it will be like [1]
In that due to the long -l linkage list it will be:
Linkage info
testlinkage.bin => ./testlinkage.bin (interpreter =>
/lib64/ld-linux-x86-64.so.2)
librte_acl.so.17.11 => /usr/lib/x86_64-linux-gnu/librte_acl.so.17.11
ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2
librte_bitratestats.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_bitratestats.so.17.11
librte_bus_pci.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_bus_pci.so.17.11
librte_bus_vdev.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_bus_vdev.so.17.11
librte_cfgfile.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_cfgfile.so.17.11
librte_cmdline.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_cmdline.so.17.11
librte_cryptodev.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_cryptodev.so.17.11
librte_distributor.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_distributor.so.17.11
librte_eal.so.17.11 => /usr/lib/x86_64-linux-gnu/librte_eal.so.17.11
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1
librte_efd.so.17.11 => /usr/lib/x86_64-linux-gnu/librte_efd.so.17.11
librte_ethdev.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_ethdev.so.17.11
librte_eventdev.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_eventdev.so.17.11
librte_flow_classify.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_flow_classify.so.17.11
librte_gro.so.17.11 => /usr/lib/x86_64-linux-gnu/librte_gro.so.17.11
librte_gso.so.17.11 => /usr/lib/x86_64-linux-gnu/librte_gso.so.17.11
librte_hash.so.17.11 => /usr/lib/x86_64-linux-gnu/librte_hash.so.17.11
librte_ip_frag.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_ip_frag.so.17.11
librte_jobstats.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_jobstats.so.17.11
librte_kni.so.17.11 => /usr/lib/x86_64-linux-gnu/librte_kni.so.17.11
librte_kvargs.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_kvargs.so.17.11
librte_latencystats.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_latencystats.so.17.11
librte_lpm.so.17.11 => /usr/lib/x86_64-linux-gnu/librte_lpm.so.17.11
librte_mbuf.so.17.11 => /usr/lib/x86_64-linux-gnu/librte_mbuf.so.17.11
librte_member.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_member.so.17.11
librte_mempool.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_mempool.so.17.11
librte_mempool_octeontx.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_mempool_octeontx.so.17.11
librte_mempool_ring.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_mempool_ring.so.17.11
librte_mempool_stack.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_mempool_stack.so.17.11
librte_meter.so.17.11 => /usr/lib/x86_64-linux-gnu/librte_meter.so.17.11
librte_metrics.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_metrics.so.17.11
librte_net.so.17.11 => /usr/lib/x86_64-linux-gnu/librte_net.so.17.11
librte_pci.so.17.11 => /usr/lib/x86_64-linux-gnu/librte_pci.so.17.11
librte_pdump.so.17.11 => /usr/lib/x86_64-linux-gnu/librte_pdump.so.17.11
librte_pipeline.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pipeline.so.17.11
librte_pmd_af_packet.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_af_packet.so.17.11
librte_pmd_ark.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_ark.so.17.11
librte_pmd_avp.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_avp.so.17.11
librte_pmd_bnxt.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_bnxt.so.17.11
librte_pmd_bond.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_bond.so.17.11
librte_pmd_crypto_scheduler.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_crypto_scheduler.so.17.11
librte_pmd_cxgbe.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_cxgbe.so.17.11
librte_pmd_e1000.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_e1000.so.17.11
librte_pmd_ena.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_ena.so.17.11
librte_pmd_enic.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_enic.so.17.11
librte_pmd_failsafe.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_failsafe.so.17.11
librte_pmd_fm10k.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_fm10k.so.17.11
librte_pmd_i40e.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_i40e.so.17.11
librte_pmd_ixgbe.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_ixgbe.so.17.11
librte_pmd_kni.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_kni.so.17.11
librte_pmd_lio.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_lio.so.17.11
librte_pmd_nfp.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_nfp.so.17.11
librte_pmd_null.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_null.so.17.11
librte_pmd_null_crypto.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_null_crypto.so.17.11
librte_pmd_octeontx.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_octeontx.so.17.11
librte_pmd_octeontx_ssovf.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_octeontx_ssovf.so.17.11
librte_pmd_pcap.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_pcap.so.17.11
libpcap.so.0.8 => /usr/lib/x86_64-linux-gnu/libpcap.so.0.8
librte_pmd_qede.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_qede.so.17.11
librte_pmd_ring.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_ring.so.17.11
librte_pmd_sfc_efx.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_sfc_efx.so.17.11
librte_pmd_skeleton_event.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_skeleton_event.so.17.11
librte_pmd_softnic.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_softnic.so.17.11
librte_pmd_sw_event.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_sw_event.so.17.11
librte_pmd_tap.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_tap.so.17.11
librte_pmd_thunderx_nicvf.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_thunderx_nicvf.so.17.11
librte_pmd_vhost.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_vhost.so.17.11
librte_pmd_virtio.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_virtio.so.17.11
librte_pmd_vmxnet3_uio.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_pmd_vmxnet3_uio.so.17.11
librte_port.so.17.11 => /usr/lib/x86_64-linux-gnu/librte_port.so.17.11
librte_power.so.17.11 => /usr/lib/x86_64-linux-gnu/librte_power.so.17.11
librte_reorder.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_reorder.so.17.11
librte_ring.so.17.11 => /usr/lib/x86_64-linux-gnu/librte_ring.so.17.11
librte_sched.so.17.11 => /usr/lib/x86_64-linux-gnu/librte_sched.so.17.11
librte_security.so.17.11 =>
/usr/lib/x86_64-linux-gnu/librte_security.so.17.11
librte_table.so.17.11 => /usr/lib/x86_64-linux-gnu/librte_table.so.17.11
librte_timer.so.17.11 => /usr/lib/x86_64-linux-gnu/librte_timer.so.17.11
librte_vhost.so.17.11 => /usr/lib/x86_64-linux-gnu/librte_vhost.so.17.11
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
I wondered about the difference and thought it might be due to my tests
running against an Ubuntu build of it (in a ppa).
I set the test to be more verbose and re-ran it, but same result.
The list above seems that it linked it "all into the test" in the Debian
case.
Which is a bit of a overdose given what the test does, the Ubuntu result
looks much saner.
I checked Ubuntu in dtail with -x on the script, but it does run the
pkg-config and build happens to be :
+ gcc -v testlinkage.c -o testlinkage.bin -Wall -Werror -include
/usr/include/x86_64-linux-gnu/dpdk/rte_config.h
-I/usr/include/x86_64-linux-gnu/d
pdk -I/usr/include/dpdk -lrte_acl -lrte_bitratestats -lrte_bus_pci
-lrte_bus_vdev -lrte_cfgfile -lrte_cmdline -lrte_cryptodev
-lrte_distributor -l
rte_eal -lrte_efd -lrte_ethdev -lrte_eventdev -lrte_flow_classify -lrte_gro
-lrte_gso -lrte_hash -lrte_ip_frag -lrte_jobstats -lrte_kni -lrte_kvar
gs -lrte_latencystats -lrte_lpm -lrte_mbuf -lrte_member -lrte_mempool
-lrte_mempool_octeontx -lrte_mempool_ring -lrte_mempool_stack -lrte_meter -l
rte_metrics -lrte_net -lrte_pci -lrte_pdump -lrte_pipeline
-lrte_pmd_af_packet -lrte_pmd_ark -lrte_pmd_avp -lrte_pmd_bnxt
-lrte_pmd_bond -lrte_pmd
_crypto_scheduler -lrte_pmd_cxgbe -lrte_pmd_e1000 -lrte_pmd_ena
-lrte_pmd_enic -lrte_pmd_failsafe -lrte_pmd_fm10k -lrte_pmd_i40e
-lrte_pmd_ixgbe -
lrte_pmd_kni -lrte_pmd_lio -lrte_pmd_nfp -lrte_pmd_null
-lrte_pmd_null_crypto -lrte_pmd_octeontx -lrte_pmd_octeontx_ssovf
-lrte_pmd_pcap -lrte_pmd
_qede -lrte_pmd_ring -lrte_pmd_sfc_efx -lrte_pmd_skeleton_event
-lrte_pmd_softnic -lrte_pmd_sw_event -lrte_pmd_tap -lrte_pmd_thunderx_nicvf
-lrte_
pmd_vhost -lrte_pmd_virtio -lrte_pmd_vmxnet3_uio -lrte_port -lrte_power
-lrte_reorder -lrte_ring -lrte_sched -lrte_security -lrte_table -lrte_time
r -lrte_vhost -ldl -lm -lpthread -lz
Yet the outcome is working and only has the effective dependencies:
Linkage info
testlinkage.bin => ./testlinkage.binCOLLECT_GCC_OPTIONS='-v' '-o'
'testlinkage.bin' '-Wall' '-Werror' '-include'
'/usr/include/x86_64-linux-gnu/dp
dk/rte_config.h' '-I' '/usr/include/x86_64-linux-gnu/dpdk' '-I'
'/usr/include/dpdk' '-mtune=generic' '-march=x86-64'
+ echo OK
+ printf '\n\nLinkage info\n'
+ lddtree testlinkage.bin
(interpreter => /lib64/ld-linux-x86-64.so.2)
librte_eal.so.17.11 => /usr/lib/x86_64-linux-gnu/librte_eal.so.17.11
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1
ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
I slightly wonder on the reported COLLECT_GCC_OPTIONS being short.
Lets see if I can build a debian autopkgtest target for this ...
Ok I can at least reproduce via (ubuntu1 is just the set -x to 17.11.1-4):
$ autopkgtest --test-name=test-linkage --apt-upgrade --shell-fail
--no-built-binaries dpdk_17.11.1-4ubuntu1.dsc -- lxd images:debian/sid/amd64
And compare it to:
$ autopkgtest --test-name=test-linkage --apt-upgrade --shell-fail
--no-built-binaries --setup-commands="add-apt-repository
ppa:ci-train-ppa-servic
e/3193; apt update; apt -y upgrade" dpdk_17.11.1-4ubuntu1.dsc -- lxd
ubuntu-daily:bionic/amd64
(I need the ppa on Ubuntu to get past the -lz issue)
It still is different, grml.
Lets do a line by line comparison
Debian [2]
Ubuntu [3]
Hmm, options are all the same.
But I run against 17.11 and the Debian case against 17.11.1
Everything else is the same so a change to 17.11.1 itself seems to trigger
this.
Could this be the silly new header include?
Since I can jump into the Debian container why not just hack on there ...
<insert random rant against selection of stable patches if this is true>
It is not (and should not be) the /usr/include/dpdk/rte_common.h include
that we hit before - at least disabling the include of rtc_config.h in
there that was brought by 340edf8d lib: fix missing includes in exported
headers didn't change anything.
So what else in the stable patches might cause this.
We use plan gcc, not the dpdk mk infrastructure so most changes should not
affect us.
The above is the only direct change to rte_common.h, so it must be either
changes to lower headers - or given that we face a linkage change - effects
to the built .so's that behave different (or something completely else).
Lets take a look at the libs in 17.11.1 vs 17.11
$ dpkg -S /usr/lib/x86_64-linux-gnu/librte_eal.so.17.11
librte-eal17.11:amd64: /usr/lib/x86_64-linux-gnu/librte_eal.so.17.11
$ dpkg -l librte-eal17.11
librte-eal17.11:amd64 17.11.1-4
$ lddtree /usr/lib/x86_64-linux-gnu/librte_eal.so.17.11
librte_eal.so.17.11 => /usr/lib/x86_64-linux-gnu/librte_eal.so.17.11
(interpreter => none)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
That looks the same and sand on 17.11 just as on 17.11.1
Ok, what else would affect our testlinkage.c build but not show up in the
verbose gcc output that we compared above?
GCC Versions?
Both are 7.3 derivatives, slight differences in "-fstack-protector-strong
-Wformat-security" defaults, but that isn't "it".
Oh I found it I think.
Look at this (simplified) from gcc's verbose output (converted spaces to
line breaks) in the collect2 call.
$ diff /tmp/foo2 /tmp/bar2
15a16
> --as-needed
18a20,23
> -z
> now
> -z
> relro
That would exactly explain what we see, so how die the Debian 17.11.1 build
loose this?
Ubuntu has 7.3.0-11ubuntu1 in proposed, but currently is at 7.3.0-5ubuntu1.
Maybe there was a change?
7.3.0-6 has in its changelog: "Update gcc-as-needed.diff"
But bumping Ubuntus gcc to the new versiosn doesn't change it.
Where does it get the flags for collect2 in this case from?
With some discussions I found that Debian/Ubuntu differ a long time on this
actually.
But only now it now became an issue for our test.
Here from gcc -dumpspecs on the *link stage
Ubuntu: ... --hash-style=gnu --as-needed %{shared:-shared} ...
Debian: ... --hash-style=gnu %{shared:-shared} ...
That made Ubuntu always having a much narrower link scope.
Any anything built though the dpdk build system has so as well, by -
actually us - triggering via discussions by us IIRC
6248e442 mk: prevent overlinking in applications
4e04fd45 mk: remove library grouping during application linking
Anyway, what to do about it - we want it in a way that works for both
Distributions.
With all of the above found I think we need:
- change the testlinkage build to use the dpdk build system
This will fix some of the issues as well as test the build system
integration that we deliver
- Fix some minor things I found on the way
- Make the test verbose to understand faster what is going on
- Check the second level on something the base will not link to (librt atm,
but libnuma would do as well)
The last change would be enough, but I thought while at it lets do it right.
I made a test build and ran it through Debian (17.11.1-4) and Ubunut
(17.11-5).
Both are good, I'll send a patch against 17.11.x but I thought some
explanation might be useful :-)
[1]:
https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dpdk/20180312_234523/log.gz
[2]: http://paste.ubuntu.com/p/PQ9zZVmytN/
[3]: http://paste.ubuntu.com/p/8pGsGxBs73/
--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-dpdk-devel/attachments/20180313/6ef3f7bc/attachment-0001.html>
More information about the Pkg-dpdk-devel
mailing list