[lsb-discuss] navigator and appcheck mismatch

[Theodore Tso]

On Tue, Mar 10, 2009 at 02:27:52PM -0400, Robert Schweikert wrote:
> I ran AppCheck (through the web interface) version 4.0.2 on openMotif
> libraries built from source on an openSUSE 11.1 system.
> 
> For the library libUil.so.4.0.0 AppCheck decides that the following
> interfaces are not part of the LSB:
> 
>     - XtCalloc
>     - XtFree
>     - XtMalloc
>     - XtRealloc
>     - XtShellStrings
>     - XtStrings
> 
> However, querying the navigator says that these interfaces are part of
> the LSB.

What happened here is a little confusing, and we may want to think
about how to improve the output of the Linux Application Checker.
(You were using the GUI Linux Application Checker and not the old
lsbappchk command-line tool, right?)

If you do analysis of /usr/lib/libMrm.so.3, /usr/lib/libUil.so.3, and
/usr/lib/libXm.so.3, it becomes clearer what's going on.  For
RtRealloc, the report looks something like this:


Interface       Dependent      	    	  Library	In LSB
		Application Components	  		
--------------------------------------------------------------------
	       	1 component (…)        Non-linked ?	No
		/usr/lib/libUil.so.3 
XtRealloc
		2 components (…)       	libXt.so.6	Yes
		/usr/lib/libMrm.so.3
		/usr/lib/libXm.so.3


What's going on here is that /usr/lib/libUil.so.3 isn't actually
listing libXt.so.6 as a library dependency.  The reason why this works
is because Motif applications never link against *just*
/usr/lib/libUil.so.3.  In practice they link against libMrm and/or
libXm as well, and once libMrm drags in the XtMalloc, XtRealloc, and
friends, they can be used to satisfy libUil.

This isn't good programming practice; if libUil uses libXt, it should
have linked against libXt when it was built, so that libUI had a
DT_NEEDED for LibXt.  On some shared library systems (such as AIX),
this wouldn't even work, so I'm a bit surprised a patch to make libUI
have a DT_NEEDED for LibXT never made it back to the core Motif code.
The lack of the DT_NEEDED also means that an attempt to dlopen()
libUil also might not work, againb ecause the dependency on libXt
wasn't declared.

Be that as it may, it's fair to say that Linux Application Checker can
confuse someone looking at it, especially the "No" in the 'In LSB'
column.  Perhaps we should leave it blank, or also put a '?' in that
column.

There is a partial explanation of this in the if you click on the
question mark next to the "Non-linked" section.  Unfortunately, the
help message is specific for executables:

	The analyzer has failed to determine which library (among
	those required by this application component) provides this
	interface. This may happen if the corresponding library
	wasn't found in the database or in the distribution on this
	machine, or if the list of libraries needed by this application
	component is incomplete. If this binary is executable, then
	most likely it will fail if launched on this machine.

We should have a different message for shared libraries that explains
about DT_NEEDED, and that the library probably does work if (and only
if) an application that uses this libraries happens to link the right
set of libraries needed, and/or if an application links against yet
another shared library that happens to drag in the needed toolkit.

Technically speaking, this is a bug in how libUil is built, and it
would be good to get a bug filed with upstream (if it is even being
maintained upstream).  But the Linux Application Checker could be made
to explain this situation much more clearly.  (And the 'no' in the "In
LSB?" column is just plain misleading.)

						- Ted