trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: October 2010

libkipi, libkdcraw, and libkexiv2 dependency

From: Darrell Anderson <humanreadable@...>
Date: Mon, 4 Oct 2010 10:41:46 -0700 (PDT)
I ran into an interesting quirk with libkipi, libkdcraw, and libkexiv2.

I'm trying to build gwenview and digikam for Slackware 12.2. Two popular non-core apps.

Digikam has a required dependency on libkipi and libkipi is optional in gwenview. Unless explicitly declared otherwise in the configure options, gwenview will build with kipi support when those packages are installed.

As the libkipi, libkdcraw, and libkexiv2 library packages are available upstream as well in Trinity SVN and tarballs, and these packages are not dependent upon tqtinterface, non-core packages should build with either the upstream or Trinity version of these libraries.

As I am using these same packages in KDE 3.5.10 on Slackware, and I have yet to create and test build scripts for the Trinity library packages, I proceeded to build both digikam and gwenview using my previous upstream version of libkipi, libkdcraw, and libkexiv2.

Both digikam and gwenview failed to build with those versions of libkipi, libkdcraw, and libkexiv2. The build always failed with an error about libGL.la not being available.

=====================================
grep: /usr/lib//libGL.la: No such file or directory
/usr/bin/sed: can't read /usr/lib//libGL.la: No such file or directory
libtool: link: `/usr/lib//libGL.la' is not a valid libtool archive
=====================================

I traced that file to the proprietary nvidia package. The stock X11 OpenGL provides no such la file.

In the past I must have compiled libkipi, libkdcraw, and libkexiv2 with the proprietary nvidia package installed. The packages then build somehow linked to libGL.la.

In my chroot build environment I do not have the proprietary nvidia package installed. Only the stock X11. Thus the failure when using the previous versions of libkipi, libkdcraw, and libkexiv2.

In my chroot environment I built and installed a new libkipi, libkdcraw, and libkexiv2 packages from the same upstream sources.

Gwenview and digikam then built without errors regarding libGL.la.

Gwenview only needed the newer libkipi. Digikam needed all three.

I presume the same build error will occur when using the Trinity version of libkipi, libkdcraw, and libkexiv2. That is, when a person has the proprietary nvidia package installed, then libkipi, libkdcraw, and libkexiv2 will somehow link to the libGL.la file.

I have not yet tested this with the Trinity versions of the library files. A side comment: I submitted a bug report that perhaps Trinity should not maintain versions of these libraries because they are maintained and available upstream.

I checked the libkipi, libkdcraw, and libkexiv2 configure options and did not notice anything obvious or helpful. I'm not a developer and perhaps an option exists to ignore the proprietary OpenGL.

One solution seems to be to modify the build process to prevent that linking to libGL.la.

Another solution is to always build libkipi, libkdcraw, and libkexiv2 in an environment without the proprietary nvidia package installed.

Another option is to install the proprietary nvidia package in my chroot build environment. I'm guessing then the packages will not fail to build with that particular error, but then I am no longer creating generic packages for users not using nividia. Or perhaps the final binary will still work without the proprietary nvidia package installed. I haven't any idea.

This would seem to be an upstream problem. Therefore possibly only the generic build environment is the only tenable solution.

I can add commentation in my build scripts and documentation.

Comments and advice appreciated.

Darrell