> 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=a45bca4e6a691eb1552f284ab2a7036b&threadid=22875

It is an upstream problem, just not a Trinity one. ;-)

Hope this helps!

Tim