[lsb-discuss] lsbappchk DT_NEEDED

Robert Schweikert robert.schweikert at mathworks.com
Wed Jul 18 06:06:02 PDT 2007



Vladimir Rubanov wrote:
> 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.
>   
Mark as failure only if the DT_NEEDED library is not in one of the 
directories provided with -D or on the library list provided with -L.

We do need to work on the command line interface, haven't had any good 
ideas yet on what this should look like.
> 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.
>>     
>
>
>   

-- 
Robert Schweikert                       MAY THE SOURCE BE WITH YOU
(robert.schweikert at mathworks.com)                 LINUX
The MathWorks Inc.
Phone : 508-647-2042






More information about the lsb-discuss mailing list