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
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=a45bca4e6a691eb1552f284ab2a...
It is an upstream problem, just not a Trinity one. ;-)
Hope this helps!
Tim
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=a45bca4e6a691eb1552f284ab2a...
"Doctor, doctor, my arm hurts when I do this!"
"Don't do that anymore!"
Sure, I inadvertently tripped over the solution: build without the proprietary nvidia package installed.
The challenge is that we can't guarantee end-users downstream will comply. In the build scripts for those three packages I can insert a test for libGL.la. If found, then halt/pause the build with a warning message. If a person builds only for personal use, as I have done for the past many years, building packages with nvidia installed is harmless because that is the only person using the packages. Such people will never notice problems or build failures, as I never did.
With that said, the thread you linked is 6 years old. Thus the problem still exists and the problem never was successfully resolved as promised.
I can't provide build scripts to other users that way, or pre-built packages. As end-users can use upstream versions of these packages, just as I did, probably the best I can do is insert warning messages in the build scripts along with commentation.
Ideas anyone?
Sure, I inadvertently tripped over the solution: build without the proprietary nvidia package installed.
The challenge is that we can't guarantee end-users downstream will comply. In the build scripts for those three packages I can insert a test for libGL.la. If found, then halt/pause the build with a warning message. If a person builds only for personal use, as I have done for the past many years, building packages with nvidia installed is harmless because that is the only person using the packages. Such people will never notice problems or build failures, as I never did.
With that said, the thread you linked is 6 years old. Thus the problem still exists and the problem never was successfully resolved as promised.
I can't provide build scripts to other users that way, or pre-built packages. As end-users can use upstream versions of these packages, just as I did, probably the best I can do is insert warning messages in the build scripts along with commentation.
Ideas anyone?
Anybody know what other packages are OpenGL dependent?
Sure, I inadvertently tripped over the solution: build without the proprietary nvidia package installed.
The challenge is that we can't guarantee end-users downstream will comply. In the build scripts for those three packages I can insert a test for libGL.la. If found, then halt/pause the build with a warning message. If a person builds only for personal use, as I have done for the past many years, building packages with nvidia installed is harmless because that is the only person using the packages. Such people will never notice problems or build failures, as I never did.
With that said, the thread you linked is 6 years old. Thus the problem still exists and the problem never was successfully resolved as promised.
I can't provide build scripts to other users that way, or pre-built packages. As end-users can use upstream versions of these packages, just as I did, probably the best I can do is insert warning messages in the build scripts along with commentation.
Ideas anyone?
Anybody know what other packages are OpenGL dependent?
kdegraphics is one (for the POV ray modeller). Not sure on the others, but a search for #include <ql.h> or #include "gl.h" should turn up the remaining modules.
Tim
-
Darrell Anderson -
Timothy Pearson