<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0"> </HEAD> <BODY> On Wed, 2009-12-02 at 09:48 -0800, Carl Worth wrote: <BLOCKQUOTE TYPE=CITE> <PRE> On Wed, 02 Dec 2009 08:14:36 -0800, Alan Coopersmith <<A HREF="mailto:Alan.Coopersmith@Sun.COM">Alan.Coopersmith@Sun.COM</A>> wrote: > Carl Worth wrote: > > My big concern is with making the build even more fragile than it > > already is. We already have lots of documentation teaching people to add > > ${prefix}/lib/pkgconfig to PKG_CONFIG_PATH and I've not ever seen > > documentation telling people to add ${prefix}/share/pkgconfig as > > well. So the change makes a lot of existing instructions stop working. > > Welcome to last month. All the tinderboxes & build scripts had to be > updated when this change hit libxtrans, since otherwise libX11 & xserver > stopped building. Yes, that's madness. How did people allow that to go through? Can we stop it now? -Carl </PRE> </BLOCKQUOTE> I'd like to set aside the 'work required for the transition' issue and focus on the architecture issue for a moment. Fedora states that their packages must comply with the File System Hierarchy Standard (<A HREF="http://www.pathname.com/fhs/).">http://www.pathname.com/fhs/).</A> This standard states the location of files on the filesystem. For /usr/share (<A HREF="http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA)">http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA)</A> it says: <BLOCKQUOTE> <TT>"This hierarchy is intended to be shareable among all architecture platforms of a given OS; thus, for example, a site with i386, Alpha, and PPC platforms might maintain a single /usr/share directory that is centrally-mounted. Note, however, that /usr/share is generally not intended to be shared by different OSes or by different releases of the same OS."</TT> </BLOCKQUOTE> When a standard is adopted and followed, there is an expectation to find certain things at certain locations. I suspect this is what happens with cross-compiling. I also found this on Mozilla about compiling a 32 bit version on a 64 bit OS: <BLOCKQUOTE> <TT>For Fedora 8 it is necessary to add /usr/share/pkgconfig to PKG_CONFIG_LIBDIR:</TT> <TT>export PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig:/usr/share/pkgconfig</TT> <TT>For ubuntu 9, it is also necessary to add /usr/share/pkgconfig to PKG_CONFIG_LIBDIR, and few more work:</TT> </BLOCKQUOTE> <OL TYPE=1> <BLOCKQUOTE> <LI TYPE=1 VALUE=1><TT>export PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig:/usr/share/pkgconfig</TT> <LI TYPE=1 VALUE=2><TT>export CROSS_COMPILE=1</TT> <LI TYPE=1 VALUE=3><TT>32bit DEV package is name like lib32XXXX.dev, like lib32asound2-dev</TT> <LI TYPE=1 VALUE=4><TT>need to change 'ac_add_options --x-libraries=/usr/lib' to 'ac_add_options --x-libraries=/usr/lib32'.</TT> <LI TYPE=1 VALUE=5><TT>need to install  ia32-libs , gcc-multilib and g++-multilib package.</TT> </BLOCKQUOTE> </OL> Starting in 2005, pkg-config looks in libdir followed by datadir by default. I don't think it's even our choice to make. Whether or not it works in our build is pretty much irrelevant. (In the above example they have chosen to replace the default search pad rather than, or in addition to, prepend to it. It will be some work to make the change, but others have done it. I am willing to create appropriate patches and collect the review tags. So far we have one tool (cross-compile) that relies on this architecture. I'd be interested to learn about more scenarios like this one. If anyone sees documented reasons for not following the standard, please share them. </BODY> </HTML>