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.
I didn't get a chance to read the entire message yet, but I thought I'd
fire this off to you as you have run across a very common nVidia problem.
You should not build gl-dependent programs against the nVidia proprietary
drivers (or the ATI proprietary drivers for that matter). There is
absolutely no guarantee that they will work without the nVidia GL library;
e.g. on Intel or other non-proprietary GL-enabled graphics.
That being said, here is the fix:
http://www.nvnews.net/vbulletin/showthread.php?s=a45bca4e6a691eb1552f284ab2…
It is an upstream problem, just not a Trinity one. ;-)
Hope this helps!
Tim