Re: [dpdk-dev] [PATCH] pci: fix missing pci bus with shared library build

[Stephen Hemminger <stephen@networkplumber.org>]

On Mon, 22 Jul 2019 19:04:55 +0200
Thomas Monjalon <thomas@monjalon.net> wrote:

> 22/07/2019 18:43, Stephen Hemminger:
> > On Mon, 22 Jul 2019 10:06:11 +0100
> > Bruce Richardson <bruce.richardson@intel.com> wrote:  
> > > On Mon, Jul 22, 2019 at 09:38:27AM +0200, Thomas Monjalon wrote:  
> > > > 19/07/2019 22:55, Stephen Hemminger:    
> > > > > The root cause is that recent gcc won't run constructor on unused libraries.
> > > > > Testing a patch to take --as-needed off of PCI library.
> > > > > 
> > > > > See: https://stackoverflow.com/questions/11631161/force-to-link-against-unused-shared-library    
> > > > 
> > > > The constructor is run when calling dlopen, right?
> > > > 
> > > > Note: dlopen with -d is a feature.
> > > > The original idea was to be able to specify which driver we want to use.
> > > > If we want an automatic dlopen, like modprobe, then we need more scripts.
> > > > But I understand you are against the whole dlopen idea.  
> > > 
> > > This issue is more of a problem for development systems where we EAL path
> > > is not really usable for finding the drivers. For a properly deployed
> > > system where we use DPDK installed to /usr/local or /usr, the EAL PMD path
> > > will be correctly configured and properly probe all drivers.  
> > 
> > The problem is that bus drivers register themselves in constructors and
> > these construtors are not run with as-needed.  
> 
> Are the constructors run on dlopen of the bus driver?
> 
> 
> 

Yes, constructors are run on dlopen.
But application should not have to ask DPDK to dlopen the bus devices.

The core principle is that dynamic build of DPDK should act the same as old
statically linked DPDK. Otherwise, the user experience is even worse, and all
the example documentation is wrong.