On 03.07.2017 13:34, Savolainen, Petri (Nokia - FI/Espoo) wrote: >> diff --git a/test/Makefile.inc b/test/Makefile.inc >> index 1ef2a92c..bf31b374 100644 >> --- a/test/Makefile.inc >> +++ b/test/Makefile.inc >> @@ -4,7 +4,7 @@ LIB = $(top_builddir)/lib >> #in the following line, the libs using the symbols should come before >> #the libs containing them! The includer is given a chance to add things >> #before libodp by setting PRE_LDADD before the inclusion. >> -LDADD = $(PRE_LDADD) $(LIB)/libodphelper.la $(LIB)/libodp-linux.la >> +LDADD = $(PRE_LDADD) $(LIB)/libodphelper.la $(LIB)/libodp-linux.la >> $(DPDK_PMDS) > > Application using ODP should only need to add dependency to ODP and helper > libs. It's not scalable if (all) applications need to know which (all) libs > an ODP implementation may use internally.
Applications using shared library don't need to know, what are ODP dependencies. Deps will be pulled in using .so DT_NEEDED. Static linking requires knowledge of all dependencies. Usually this will be handled by pkg-config (See Libs.private) or libtool (which also usually handles such configuration). Unfortunately DPDK PMDs do not fit into libtool scheme because of the way they are linked. Libtool doesn't understand whole -Wl,--whole-archive,... scheme, so it won't include it into dependencies list. Another possibility would be to create source file, which pulls in all PMDs detected by configure and link with just -ldpdk. > I guess this solves some DPDK linking issues, but is there a way to avoid > explicit dependency to ODP lib internals ? Not with DPDK, unfortunately. -- With best wishes Dmitry
