Extension Development :: pkgconfig



Quote
Just to get even more off-topic.... what do you do when pkg-config fails as it can't find the .pc files? I have been trying to compile the lastest gtkam & running into numerous problems with  pkg-config when executing the configure scripts for gtkam, gphoto & the libraries they depend on (e.g. libexif etc).


I guess the first thing is to check that the format of the pkgconfig variable is correct, eg:
Code Sample
$ export PKG_CONFIG_PATH=/opt/myapp1/lib/pkgconfig:/opt/myapp2/lib/pkgconfig:/opt/myapp3/lib/pkgconfig


If this doesn't work (and sometimes it doesn't even when the pc files are present), then there are a couple of other options:

1. set compiler and library flags, eg:
Code Sample
$ export CPPFLAGS="-I/opt/myapp1/include -I/opt/myapp2/lib"
$ export LDFLAGS="-L/opt/myapp1/include -L/opt/myapp2/lib"


2. set ./configure switches if possible, eg:
Code Sample
$ ./configure --prefix=/opt/myapp --xincludes=/opt/myapp/include --xlibs=/opt/myapp/lib


3. set other environment variables (usually listed by ./configure --help) eg:
Code Sample
$ export XMLCFLAG=-I/opt/myapp/include
$ export XMLLDFLAG=-L/opt/myapp/lib


4. (if the ./configure script completes) edit the Makefile(s) directly to add the location of headers/libs

5. (last option, since this is not a good idea) symlink the appropriate headers and libs to /usr/include and /usr/lib
OK,

I've gone back to the start with compiling gtkam, with the latest downloads of gtkam, libgphoto2, libexif, libexif-gtk & libusb.

I use the compile -3.3.5.uci & gtk+-2.10.9.unc & gtk+-2.10.9.unc extensions loaded onto an otherwise base frugal install of DSL 4.3.

I can compile & install libusb & libexif, but when compiling libexif-gtk the  configure script exits with the following:

Code Sample


config.status: creating po/Makefile
./configure: line 1: srcdir: command not found


Configuration (libexif-gtk):

       Source code location:    
       Version:                 0.3.5
       Compiler:                gcc

       libexif:                 < 0.6.12 (think about upgrading)


dsl@box:/mnt/hda/libexif-gtk-0.3.5$


but make then fails with:

Code Sample
/bin/sh ../libtool --mode=link gcc  -g -O2 -Wall -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith   -o libexif-gtk.la -rpath /usr/local/lib -version-info 5:0:0 gtk-exif-browser.lo gtk-exif-content-list.lo gtk-exif-entry.lo gtk-exif-entry-ascii.lo gtk-exif-entry-copyright.lo gtk-exif-entry-date.lo gtk-exif-entry-generic.lo gtk-exif-entry-flash.lo gtk-exif-entry-number.lo gtk-exif-entry-option.lo gtk-exif-entry-rational.lo gtk-exif-entry-resolution.lo gtk-exif-entry-user-comment.lo gtk-exif-entry-version.lo ../gtk-extensions/libgtk-extensions.la -L/usr/local/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lexif -lm  
libtool: link: cannot find the library `/usr/lib/libXrender.la'
make[2]: *** [libexif-gtk.la] Error 1
make[2]: Leaving directory `/mnt/hda/libexif-gtk-0.3.5/libexif-gtk'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/mnt/hda/libexif-gtk-0.3.5'
make: *** [all] Error 2
dsl@box:/mnt/hda/libexif-gtk-0.3.5$


libXrender seems to be in /usr/X1R6/lib. I've created a symlink to /usr/lib, but it doesn't seem to make any difference. (there is no ".la" file there - just the .so.1.2 file & a symlink to it in .so.1)
Quote
libXrender seems to be in /usr/X1R6/lib

- I don't think libXrender is in the base dsl, did it come from an old version of gnu-utils or XFree86 maybe? This being said, this is the first time I saw an error complaining of missing the *.a version of a library.

As a test, you could try loading the latest xorg72.uci (the headers/pc files are in it),  including it in PKG_CONFIG_PATH and trying again to compile.
A response (from the other thread):
Quote
In fact (not to get too far off topic), I realised that I should probably remove the headers/pc files for the compile utilities that are not in the dsl base (textinfo, bison, flex, etc).
Couldn't removing the .pc also possibly have problems for some configure software looking for some bin/libs?  I don't think dev files are split into their own .pc, so there might be some manual tweaking needed?
In fact looking in /opt/compile-3.3.5/lib/pkgconfig, there are:
Code Sample
$ ls /opt/compile-3.3.5/lib/pkgconfig
freetype2.pc  glib.pc       gthread.pc    libpng.pc     libpng12.pc
gdk.pc        gmodule.pc    gtk+.pc       libpng10.pc   openssl.pc

- all of which appear to refer to the base dsl libs, so I guess bison, flex, etc did not create any pc files and it's OK to leave what there is in place.
Next Page...
original here.