Bug 26943

Summary: libxt -- wrong dependencies in xt.pc.in
Product: xorg Reporter: Jonathan Landis <landijk-dev>
Component: Lib/XtAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: ldv
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Jonathan Landis 2010-03-07 16:26:33 UTC
The xt.pc.in file lists these requirements:

Requires: xproto x11 sm
Requires.private: x11 sm

There are two problems here.

1.  The dependency on libICE is not accounted for.

2.  The x11 and sm packages are on both Requires and Requires.private, which does not make sense.

Based on the Xt headers, it looks like the dependency on X11 is a regular dependency and the dependencies on SM and ICE are private, so the lines should look like this:

Requires: xproto x11
Requires.private: sm ice
Comment 1 Alan Coopersmith 2010-04-16 16:10:20 UTC
It appears the SM dependency should stay public, since Xt's <X11/Shell.h>
has #include <X11/SM/SMlib.h> so Xt users would need any -I flags from the
CFLAGS in the sm.pc file that may be needed to find the X11/SM/SMlib.h header.

The Requires.private changing from "x11 sm" to "ice" does appear to be 
correct, so I've pushed that change to git master:
http://cgit.freedesktop.org/xorg/lib/libXt/commit/?id=f3d2ac478918b99c51e0b4bff97935f2255ab537

Thanks for reporting this.
Comment 2 Jonathan Landis 2010-04-17 12:01:22 UTC
As of 0.21, pkg-config pulls in CFLAGS for Requires.private, so users of Xt will get the proper -I flags for SM if it is listed as Requires.private.

http://people.freedesktop.org/~dbn/pkg-config-guide.html#faq

Note FAQ 2.  It is my impression that a library should only use "Requires" if there isn't any practical way you can use the library without also linking directly to the dependent library.
Comment 3 Alan Coopersmith 2010-05-19 13:31:17 UTC
Okay, verified that everything the X build.sh builds works fine with:

Requires: xproto x11
Requires.private: ice sm

and no one objected when I put the patch out for review on the mailing
list, so I've gone ahead and pushed to git master:

 xt.pc.in |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

New commits:
commit 56621d3ec521dd30fabb1a77ad1c396baa740569
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Tue May 18 18:21:32 2010 -0700

    Move sm from Requires to Requires.private in xt.pc
    
    As explained in https://bugs.freedesktop.org/show_bug.cgi?id=26943
    since libXt callers need the SM headers but don't necessarily need to
    link directly to libSM, it should be in Requires.private, not Requires.
    
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
    Reviewed-by: Adam Jackson <ajax@redhat.com>

_______________________________________________
Comment 4 Dmitry V. Levin 2010-10-31 17:08:15 UTC
(In reply to comment #3)
> commit 56621d3ec521dd30fabb1a77ad1c396baa740569
> Author: Alan Coopersmith <alan.coopersmith@oracle.com>
> Date:   Tue May 18 18:21:32 2010 -0700
> 
>     Move sm from Requires to Requires.private in xt.pc
> 
>     As explained in https://bugs.freedesktop.org/show_bug.cgi?id=26943
>     since libXt callers need the SM headers but don't necessarily need to
>     link directly to libSM, it should be in Requires.private, not Requires.

Well, that's odd.  Is there any way now how libXt callers are expected to find out what packages have to be installed to #include <X11/Shell.h>?

$ pkg-config --print-requires xt
xproto
x11
$ echo '#include <X11/Shell.h>' | gcc -xc -E -o/dev/null - $(pkg-config --cflags xt) 2>&1 | fgrep 'No such file or directory'
/usr/include/X11/Shell.h:51:26: error: X11/SM/SMlib.h: No such file or directory

:(
Comment 5 Alan Coopersmith 2010-10-31 17:39:27 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > commit 56621d3ec521dd30fabb1a77ad1c396baa740569
> > Author: Alan Coopersmith <alan.coopersmith@oracle.com>
> > Date:   Tue May 18 18:21:32 2010 -0700
> > 
> >     Move sm from Requires to Requires.private in xt.pc
> > 
> >     As explained in https://bugs.freedesktop.org/show_bug.cgi?id=26943
> >     since libXt callers need the SM headers but don't necessarily need to
> >     link directly to libSM, it should be in Requires.private, not Requires.
> 
> Well, that's odd.  Is there any way now how libXt callers are expected to find
> out what packages have to be installed to #include <X11/Shell.h>?
> 
> $ pkg-config --print-requires xt
> xproto
> x11
> $ echo '#include <X11/Shell.h>' | gcc -xc -E -o/dev/null - $(pkg-config
> --cflags xt) 2>&1 | fgrep 'No such file or directory'
> /usr/include/X11/Shell.h:51:26: error: X11/SM/SMlib.h: No such file or
> directory
> 
> :(

If you don't like the way pkg-config is designed, please take it up with
the pkgconfig developers on their mailing list.
Comment 6 Julien Cristau 2010-10-31 18:32:01 UTC
> --- Comment #4 from Dmitry V. Levin <ldv@altlinux.org> 2010-10-31 17:08:15 PDT ---
> Well, that's odd.  Is there any way now how libXt callers are expected to find
> out what packages have to be installed to #include <X11/Shell.h>?
> 
'dpkg -s libxt-dev | grep ^Depends' tells me that.  I'm sure other
package managers have similar features.
Comment 7 Dmitry V. Levin 2010-10-31 19:38:34 UTC
(In reply to comment #6)
> > Well, that's odd.  Is there any way now how libXt callers are expected to find
> > out what packages have to be installed to #include <X11/Shell.h>?
> > 
> 'dpkg -s libxt-dev | grep ^Depends' tells me that.  I'm sure other
> package managers have similar features.

OK, the next question is quite obvious: how libxt-dev is going to get all necessary requirements?  By insight of the package maintainer, or there is a method to calculate it automatically?
Before that change, "pkg-config --print-requires" could be used (and actually was used) to do the job.  Does it mean that now one have to use "pkg-config --print-requires-private" to find out requirements for compilation and _dynamic_ linking?
It definitely violates the original purpose of Requires.private tag, and in other packages it may bring extra dependencies required only for static linking.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.