[lsb-discuss] lsbappchk DT_NEEDED

Vladimir Rubanov vrub at ispras.ru
Wed Jul 18 00:35:42 PDT 2007


OK, thanks, Robert, for good explanations.

So, the bottom line looks like (please correct me if needed):
1. We do NOT add --as-needed option to lsbcc.
2. We flag non-LSB libraries in DT_NEEDED section as fails.
3. We recommend developers to keep DT_NEEDED section clean of indirectly
called libraries by using techniques presented by Robert (+ possibly still
trying --as-needed for lazy ones).

As for appchk changes regarding this, I think appchk should distinguish
between non-LSB libraries with and without directly called interfaces. In
the latter case, appchk should advise user about the possible techniques to
"easily" fix this. Without this functionality, we risk to scare small ISVs
from LSB as most real apps do contain unused libs in DT_NEEDED and we should
help them as much as possible in fixing this.

We'll take care of implementing these changes in a future version of
appchk/ATK Manager.

/Vladimir.


> -----Original Message-----
> From: Robert Schweikert [mailto:robert.schweikert at mathworks.com]
> Sent: Tuesday, July 17, 2007 8:00 PM
> To: Vladimir Rubanov
> Cc: 'Wichmann, Mats D'; 'lsb-discuss'
> Subject: Re: [lsb-discuss] lsbappchk DT_NEEDED
> 
> 
> Vladimir Rubanov wrote:
> > Is it always possible to explicitly and easily control which libraries
> > go into DT_NEEDED section?
> >
>
> To the best of my knowledge yes.
>
> > It seems that most of the captured in the LSB Navigator DB apps (about
> > 500
> > in local ISPRAS version) have some libraries in DT_NEEDED that are not
> > called directly. Is it carelessness of developers' of these apps?
>
> That depends. There is the indirect dependency problem. For example if
> application A depends on library X only but X depends on Y then the
> developer has various options to deal with the dependency.
> 
> a.) when linking A use both -lX -lY
> this will cause no link errors but will add Y into the DT_NEEDED section
> of A (this is the kitchen sink model most people use)
> 
> b.) use -rpath-link when linking X, then when linking A one only needs -lX
> thus only X shows up in DT_NEEDED
> 
> c.) the classic "artificial dependency" problem by adding a library
> which is not needed at all, in this example -lX -lY -lZ
> Z is a third library but neith A, X, or Y depend on it. However, since
> it is on the command line it still shows up in DT_NEEDED.
>
> > Do you
> > think it is easy for them to fix this to contain only directly called
> > libraries?
> >
>
> IMHO it is relatively easy to transform a.) into b.) to clean up the
> DT_NEEDED section. However, even easy fixes often meet resistance. Case
> c.) is usually a not an issue of getting it cleaned up. Thus if you have
> prove that DT_NEEDED contains a library that is not used anywhere there
> is a good chance developers will accept a patch to the make file.





More information about the lsb-discuss mailing list