On Fri, Jan 03, 2020 at 10:33:28AM -0500, Chris Gorman via blfs-support wrote: > Hmm, > > Could be an error on my part somewhere. I don't recall how it got > there. Geoclue ended up there somehow. It isn't populated much. > Should I move the contents to /usr/lib and edit the pkgconfig files to > point to /usr/lib? > > Chris >
~Please do not top post, you're leading the rest of us into temptation by doing that. > On Fri, Jan 3, 2020 at 12:39 AM Bruce Dubbs via blfs-support > <[email protected]> wrote: > > > > On 1/2/20 9:34 PM, Chris Gorman via blfs-support wrote: > > > It appears that pkg-config doesn't look in /usr/lib64 by default. > > > WebKitGtk looks for geoclue-2.0 and can't find the .pc file in > > > /usr/lib64. Adding /usr/lib64 to the PKG_CONFIG_PATH allows for the > > > WebKitGtk configure to complete. > > > > > > The following fixes the problem for me. > > > > > > cat > /etc/profile.d/lib64.sh << EOF > > > # Begin /etc/profile.d/lib64.sh > > > > > > pathappend /usr/lib64/pkgconfig PKG_CONFIG_PATH > > > > > > # End /etc/profile.d/lib64.sh > > > EOF > > > > We don't use lib64 in LFS/BLFS. If you are creating a multilib system, > > then that is significantly different from the BLFS instructions. > > > > -- Bruce > > On a non-multilib BLFS, /usr/lib64 does not exist, and /lib64 contains only ld-linux-x86-64.so.2 ld-lsb-x86-64.so.3. So, anything which got installed in /usr/lib64 is a problem. You can probably move the libs, rerun ldconfig, and move and fix up the pkgconfig files, but you need to try to look at each package which got installed in /usr/lib64 and try to work out why that happened. So, before moving any of them, run ls -l on /usr/lib64 and identify the packages involved, and the order in which they were installed. Possibly whatever caused the first package to be installed there has "opened the gates". If your $history still shows the commands, or if you used scripts, comparing what you did agaisnt what is in the book will hopefully point to the problem. ISTR that in the past we've had to pass things to force lib rather than lib64, but I believe that in recent times only cmake packages have needed those defines. Perhaps libjpeg-turbo was the culprit (or else soemthing in kde if you built that). It also occurs to me that if any of the things in /usr/lib64 were optional for a package, it will probably not have used them (on multilib, there is a lot of faffing about with PKGCONFIG_PATH to find the right libs). Alternatively, if anything did manage to link to them, you probably need to rebuild that after moving them. Alternatively, having logs of what each package installed is useful, but a bit of a minefield (think of old docs and perhaps old headers which get omitted in 'find ... -newer' invocations). I guess that is why some people use DESTDIR installs for everything, or for everything that they install in BLFS. So, enjoy the learning ;-) ĸen -- The right of the people to keep and arm Bears, shall not be infringed. -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
