Message: previous - next
Month: October 2010

Re: [trinity-devel] libkipi, libkdcraw, and libkexiv2 dependency

From: "Timothy Pearson" <kb9vqf@...>
Date: Mon, 4 Oct 2010 12:49:38 -0500
> 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
> not being available.
> =====================================
> grep: /usr/lib// No such file or directory
> /usr/bin/sed: can't read /usr/lib// No such file or directory
> libtool: link: `/usr/lib//' 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
> 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
> 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 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
> 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:

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

Hope this helps!