Hello, чт, 3 янв. 2019 г. в 02:09, Luca Boccassi <bl...@debian.org>: > On Wed, 2019-01-02 at 14:55 +0300, Dmitry Eremin-Solenikov wrote: > > ср, 2 янв. 2019 г. в 14:49, Luca Boccassi <bl...@debian.org>: > > > On Wed, 2019-01-02 at 01:43 +0300, Dmitry Eremin-Solenikov wrote: > > > Strange that libtool is messing things up, I've used the same > > > pkgconfig > > > file in a few different projects that use autoconf/automake and I > > > haven't seen this issue. > > > > libtool rearranges/squashes linking flags in an attempt to find > > 'better' > > linking flags. Unfortunately this fail for DPDK. We have worked > > around > > this by squashing all PMDs into a single gcc argument: > > -Wl,--whole-archive,-lrte_pmd_af_packet,-lrte_pmd_ark,........,- > > lrte_pmd_vmxnet3_uio,--no-whole-archive > > -ldpdk > > > > Thus libtool won't move PMDs from --whole-archive/--no-whole-archive > > brackets. > > > > > I had a look on github, and it does not seem that odp is currently > > > using pkg-config, but rather doing some manual check - is there a > > > branch in a fork or a patch you could point me to so that I can try > > > to > > > reproduce? > > > > No, I have not pushed my code to github yet. The easies way to > > reproduce > > is to statically link a sample program with libtool and check that > > generated > > ELF contains all PMDs. > > That looks like a very very old libtool bug: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=347650 > > Have you tried patching config/ltmain.sh as it's suggested on that bug?
I can try doing that as a test, but I wouldn't like to have patched ltmain.sh in the source tree. > Something like: [patch skipped] > Note that the current version of Meson does not do a good job of > generating the pkg-config file, but it's fixed in the version in > development. I also found a couple of bugs in dpdk. So the following > content for libdpdk.pc is more correct: [libdpdk.pc skipped] Do you plan to upload fixed dpdk packages? > With that I can manually do a static link (without using libtool). Good! BTW: Is there any chance to get libdpdk.a back? We can then work on fixing linking with libdpdk.pc as the time permits. Note: according to README.md the 'official' DPDK build is one done using GNU Make and this build has libdpdk.a instead of libdpdk.pc. -- With best wishes Dmitry