[lsb-discuss] lsbappchk DT_NEEDED

Robert Schweikert robert.schweikert at mathworks.com
Thu Jul 12 09:03:56 PDT 2007



Vladimir Rubanov wrote:
> It is still not a simple issue in the practical perspective. Formally, yes,
> the app should contain only LSB libs in DT_NEEDED section and appchk should
> flag errors otherwise. But there is a usual case when applications contain a
> library in their DT_NEEDED list but do not call any of its interfaces
> directly. For example, there are 63 applications (firefox is among them) in
> the Navigator DB which contain libXau in DT_NEEDED but which do not call any
> libXau interfaces directly. So there is no practical reason to say the apps
> violate LSB due to wrong interfaces usage - the apps DO NOT use any libXau
> interfaces. 
But because libXau is in DT_NEEDED the dynamic linker will try and load 
libXau when the application starts, it doesn't matter whether or not 
interfaces from the library are used or not. This means the application 
will fall over with "library not found" on an LSB system (system which 
contains only LSB libraries).

> The only "guilt" is having wrong lib in DT_NEEDED list due to
> the linker whim.
It's not a linker whim. It's an incorrect link command. Somewhere on the 
link line there is an -lXau when there shouldn't be.

If a library is in DT_NEEDED and it is not in the -D or -L options to 
appcheck then this is a failure.
>  BTW, libXau is unlikely to ever become LSB lib as it is
> just an underlying implementation piece of libX11.
>
> We might require that all LSB applications should be built with
> "--as-needed" linker option (and make lsbcc use it). This should ensure no
> libraries are placed in DT_NEEDED that are not directly called by the app.
>   
Yes, for people who don't know how to link their application the 
"--as-needed" option is the right way to go. Throw everything on the 
link line and let the linker figure out what is really required.
> But I wonder why people do not use this option in wide practice - are there
> any reasons other than the option is not active by default?
>
> One more idea to smooth the situation is to grant waivers in particular
> cases like libXau included in DT_NEEDED as a side effect of using libX11.
>   
There is no side effect. If -lXau is not on the link line it will not 
show up in DT_NEEDED
> Any thoughts?
>
> /Vladimir.
>
> P.S. There was a discussion about different sets of libraries used by an app
> in lsb-infrastructure list with a summary at
> http://lists.freestandards.org/pipermail/lsb-infrastructure/2007-June/000573
> .html.
>
>
>
>   
>> -----Original Message-----
>> From: lsb-discuss-bounces at lists.freestandards.org [mailto:lsb-discuss-
>> bounces at lists.freestandards.org] On Behalf Of Wichmann, Mats D
>> Sent: Thursday, June 28, 2007 6:15 PM
>> To: Robert Schweikert; lsb-discuss
>> Subject: Re: [lsb-discuss] lsbappchk DT_NEEDED
>>
>> lsb-discuss-bounces at lists.freestandards.org wrote:
>>     
>>> New app to test new problems to be found. I'll post a number
>>> of message to keep each message relatively short.
>>>
>>> When appchk finds a DT_NEEDED section and the library is not
>>> part of the LSB and not part of -L command line arguments or
>>> not in any of the -D directories I think the test should be
>>> marked as FAIL rather than pass.
>>>
>>> 400|6 39 1 08:47:14|IC Start
>>> 200|6 39 08:47:14|Check Elf Section .dynamic
>>> 520|6 39 0 0 0|DT_NEEDED: libicudata.so.36 is used, but not part of
>>>       
>> the LSB
>>     
>>> 520|6 39 0 0 0|DT_NEEDED: libicuuc.so.36 is used, but not part of the
>>>       
>> LSB
>>     
>>> 520|6 39 0 0 0|DT_NEEDED: libicui18n.so.36 is used, but not part of
>>>       
>> the LSB
>>     
>>> 520|6 39 0 0 0|DT_NEEDED: libicuio.so.36 is used, but not part of the
>>>       
>> LSB
>>     
>>> 220|6 39 0 08:47:14|PASS
>>> 410|6 39 1 08:47:14|IC End
>>>       
>> Gee, I wonder how we missed that idea.  I guess
>> the .dynamic section check is doing something a
>> little different but it ought indeed to flag this
>> as a failure, in my opinion.
>>
>> I'd go ahead and enter a bugzilla on this one.
>>
>> _______________________________________________
>> lsb-discuss mailing list
>> lsb-discuss at lists.freestandards.org
>> http://lists.freestandards.org/mailman/listinfo/lsb-discuss
>>     
>
>   

-- 
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