Hi guys:
Thank you very much for your comments.
Chris Staub wrote on Tue Dec 15 22:56:48 MST 2009:
> unless there are duplicate files in both directories.
My original post:
>> xtrans-1.2.5 (of the Xorg-7.5 lib).
>> The previous xtrans (1.2.1 - of the Xorg-7.4)
>> was placed, together with all the others,
>> in '/usr/lib/pkgconfig/'.
[Alex: this phenomenon was what triggered my opening post]
> Second, as noted in the manpage, /usr/lib/pkgconfig
> and /usr/share/pkgconfig are both searched by default anyway
> so they don't need to be in PKG_CONFIG_PATH.
I'll second Simon Geard's comments on Wed Dec 16 01:18:41 MST 2009:
> ... you won't find any mention of /usr/share anywhere ...
Ironically (and coincidentally), the otherwise pretty common
word "share" cannot be found anywhere in the manual.
Chris, for a more expanded (and verbose) treatment of your
"... it doesn't matter what order ..." and
",.. both searched by default anyway ..." statements,
please refer to my answer to Andrew below.
Regarding Simon Geard's comment of Wed Dec 16 01:14:16 MST 2009
> "... most of the examples I can see in /usr/share are data ...
> Arguably xtrans too, since that package contains only headers,
> no binary content.
> If this is a standard though, it doesn't seem to be clearly
> documented anywhere."
The Udev developers, in their relentless quest for perfection
decided to join the crowd with their own pc file in 149.
cat /usr/share/pkgconfig/udev.pc
Name: udev
Description: udev
Version: 149
udevdir=/lib/udev
Doesn't look like "data" (although that's debatable and
frankly irrelevant here).
To me it appears like the beginning of a "trend" to
start a "regular" pc package for Udev too.
I can hardly wait for version 175 or so when we'll have
full fledged lines like "Description" and "Cflags" :)
In a "standard" directory, perhaps?
(BTW, for more of my words of wisdom on Udev, youse are
gracefully invited to thread
"UDEV - Not Leaving Well Enough Alone"
November 2009, "lfs-support" archive).
Andrew Benton wrote on Wed Dec 16 05:25:26 MST 2009
> Alex had written:
>> For a couple of packages their 'pc' files ended up
>> in '/usr/share/pkgconfig' instead of the tried and true
>> '/usr/lib/pkgconfig'. ...
>> this will cause errors for some packages
>> looking in the wrong place.
> Why? Can you give examples of these errors?
Yes [the trigger for my opening post].
Failure of 'xorg-server-1.7.1' (Xorg-7.5) on configure:
<< checking for XSERVERCFLAGS... configure: error: Package requirements
(randrproto >= 1.2.99.3 renderproto >= 0.11 fixesproto >= 4.1
damageproto >= 1.1 xcmiscproto >= 1.2.0 xextproto >= 7.0.99.3
xproto >= 7.0.13 xtrans >= 1.2.2 bigreqsproto >= 1.1.0
fontsproto inputproto >= 1.9.99.902 kbproto >= 1.0.3
videoproto compositeproto >= 0.4 scrnsaverproto >= 1.1
resourceproto xineramaproto xkbfile xfont xau pixman-1 >= 0.15.20
xdmcp openssl) were not met:
Requested 'xtrans >= 1.2.2' but version of XTrans is 1.2.1
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix (sic).
Alternatively, you may set the environment variables XSERVERCFLAGS_CFLAGS
and XSERVERCFLAGS_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details (sic). >>
-----
Alex's words now:
PKG_CONFIG_PATH was
/usr/lib/pkgconfig:/usr/local/lib/pkgconfig:/opt/qt/lib/pkgconfig
cat /usr/share/pkgconfig/xtrans.pc
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: XTrans
Description: Abstract network code for X
Version: 1.2.5
Cflags: -I${includedir} -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT
---
cat /usr/lib/pkgconfig/xtrans.pc
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: XTrans
Description: Abstract network code for X
Version: 1.2.1
Cflags: -I${includedir} -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT
---
Note: It's not a fluke that the "new" (1.2.5) xtrans pc ends up in
the new directory (as opposed to the good, old '/usr/lib/pkgconfig')
An excerpt from the 'make install' shows this was deliberate:
<< test -z "/usr/share/pkgconfig" || /bin/mkdir -p "/usr/share/pkgconfig"
/usr/bin/install -c -m 644 xtrans.pc '/usr/share/pkgconfig' >>
i.e, even if Udev had not started the new, strange trend.
---
echo $PKG_CONFIG_PATH
/usr/local/lib/pkgconfig:/opt/qt/lib/pkgconfig
(i.e. without /usr/lib/pkgconfig)
results in the same server configure error.
---
echo $PKG_CONFIG_PATH
/usr/share/pkgconfig/:/usr/local/lib/pkgconfig:/opt/qt/lib/pkgconfig
(i.e. prepending the new path /usr/share/pkgconfig but implicitly
using the pkg-config manual default, /usr/lib/pkgconfig).
NO error, meaning that the default is brought into play sometime
(who knows when), AFTER the first component, /usr/share/pkgconfig/,
is searched! Who would've thunk it!
In direct contradiction with the manual - Excerpt:
<< By default, pkg-config looks in the directory
prefix/lib/pkgconfig for these files; it will
ALSO (my emphasis) look in the colon-separated
list of directories specified by the
PKG_CONFIG_PATH environment variable. >>
For any reasonable(?) reader, "also" implies
",sometime after that," in the above context.
Thanks again,
-- Alex
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
