On Mon, Feb 24, 2020 at 08:10:10PM +0100, Cliff McDiarmid via blfs-support wrote: > >On Sun, Feb 23, 2020 at 11:18:58PM +0100, Cliff McDiarmid via blfs-support > >wrote: > > > >> Hi> > Can anyone help here? I'm building Gtk+-2.24.13. All > > >> dependencies have been built as per book, but I'm getting:> > > 'Pango not found. Pango built with Cairo support is required to build GTK+'> > > According to the> > >Meson output Pango is being built with Cairo support:> [...]>> > >Which version of the book?>> Version 9.0 stable>> > > >Just in case: was libglade installed when you built pycairo (it should be) ? > > Thanks ken, but it was something simple in the end. A lot of these packages > install to /usr. But not to /usr/lib in some cases, but to /usr/lib64. > > Therefore the .pc files are there too. I just needed to update my > PKG_CONFIG_PATH env.variable. > > You can see I only do these builds every year! > > Cliff
Hi Cliff, I'm glad you solved it, but /usr/lib64 should not be in use by packages in the books (unless you are looking at multilib, I forget which libs that uses, but you would definitely need to set PKG_CONFIG_PATH differently for 32-bit and 64-bit if you were using that). In LFS-9.0 and 9.1 on a 64-bit machine we have ld-linux-x86-64.so.2 and ld-lsb-x86-64.so.3 (both symlinks to /lib) and /usr/lib64 does not exist. I recall that at times we've had some cmake packages defaulting to /usr/lib64 unless overridden, but for everything else *in the books* /usr/lib64 should not exist. Unfortunately, once it does exist, packages have a tendency to use it by default. And at times (some) cmake packages tended to use lib64. As you discovered, expanding PKG_CONFIG_PATH works around this for most packages. In the packages I build I can see libdir being forced to /usr/lib in eudev, kmod, procps and to 'lib' in openssl (LFS) and in BLFS I see lua and PAM. For cmake book packages I currently have lib forced in libjpeg_turbo (and it was used by some qt packages which I have now archived), and also in the non-book package oiio (OpenImageIO) which uses a _different_ variable for this - my current view on cmake is that although we usually have it under control in the book, for everything else cmake is still a vale of tears. (Sorry, I'm still struggling to get blender, and what I think are the deps _I_ need, to all use _my_ CFLAGS and CXXFLAGS). ĸen -- We hope and trust that our valued and loyal customers will bear with us in the coming months as we interact synergistically with change management in our striving for excellence. That is our mission. -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
