Bug 474964 - K-3D Fails to launch
K-3D Fails to launch
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: k3d (Show other bugs)
10
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Denis Leroy
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-05 22:47 EST by Orlando Arias
Modified: 2009-12-04 11:57 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-14 22:02:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output of glxinfo (21.20 KB, text/plain)
2008-12-05 22:47 EST, Orlando Arias
no flags Details

  None (edit)
Description Orlando Arias 2008-12-05 22:47:00 EST
Created attachment 325958 [details]
output of glxinfo

Description of problem:
K-3D fails to launch with the following error:

$ k3d
 No GLX capable visual found
 CRITICAL: Caught exception [St13runtime_error] - Could not connect to an OpenGL server.


Version-Release number of selected component (if applicable):
k3d-0.6.7.0-7.fc10.x86_64
xorg-x11-drv-nvidia-177.82-1.fc10.x86_64

(using the proprietary drive from the YouKnowWhichRepo)
I am sure the issue is with k-3d itself, and not with the driver, 3D acceleration works, glx is loaded (even explicitly defined in Xorg's configuration). No errors are found in Xorg's logs.

How reproducible:
Always

Steps to Reproduce:
1. Attempt to launch k-3d

  
Actual results:
K-3D fails to launch.

Expected results:
K-3D should launch...

Additional info:
See attachments for extra info. Let me know if more info is needed.
Comment 1 Denis Leroy 2008-12-06 03:55:01 EST
what happens when you run glxgears ?

almost certainly, you need to reinstall the Nvidia driver, or do:

rm -f /usr/lib/xorg/modules/extensions/libglx.so
ln -s /usr/lib/xorg/modules/extensions/libglx.so.177.* /usr/lib/xorg/modules/extensions/libglx.so

and restart X...
Comment 2 Orlando Arias 2008-12-06 09:36:41 EST
The nvidia driver is correctly installed. I get 3D acceleration and glx correctly loaded; glxgears works as expected. Tried your change anyway, didn't work, and 3D behaves the same (same framerate in glxgears and all [around 1600 fps, which is normal for the system in question]).
Comment 3 Orlando Arias 2008-12-07 01:36:26 EST
An update on this, I went ahead and built k3d from source using the code in subversion, after some dependency fetching, it compiled. I launched and it works.

To be fair, however, this is svn code (read: unstable, though as far as my testing went, it seemed pretty stable):

$ svn info
Path: .
URL: https://k3d.svn.sourceforge.net/svnroot/k3d/trunk
Repository Root: https://k3d.svn.sourceforge.net/svnroot/k3d
Repository UUID: 6c3b9138-102f-0410-aba5-b8adf0b7bd61
Revision: 1600
Node Kind: directory
Schedule: normal
Last Changed Author: barche
Last Changed Rev: 1600
Last Changed Date: 2008-12-06 16:55:52 -0500 (Sat, 06 Dec 2008)


And I am not sure if it's using OpenGL or not. I tried compiling the version on the repo (stable), and the configure script borks on OpenGL:

$ CFLAGS=-fpic ./configure
[lalalalala checking stuff]

Required libraries
------------------
checking for OpenGL... configure: error: OpenGL required but not found

Just where is this looking OpenGL from? I have all mesa headers, installed for indirect rendering just in case, and yet this borks O_o?

I'm not going to suggest pushing the subversion code into the repos without further testing though. Notice that I use K-3D for amusement purposes only, it's not required for me to have it, and I can live with the svn version just in case. If anybody else can replicate the bug, that'd be great. Any extra input will be appreciated.

Cheers and thanks, Orlando.
Comment 4 Denis Leroy 2008-12-07 04:33:50 EST
There used to be a patch for the correct OpenGL headers detection on x86_64, but it looks as though it needs to be revisited. Yes I've wondered about upgrading to the unstable branch. The problem is the big unstable warning dialog at launch, and the fact Fedora normally sticks to stable branches only.
Comment 5 Richard Shaw 2008-12-18 21:15:06 EST
I'm having the exact same problem. F10 x86_64, Athlon 64 X2 5200+, Nvidia 7600GT PCI-E, Nvidia 177.82 drivers.

glxinfo looks fine, glxgears shows ~9500 FPS.
Comment 6 Denis Leroy 2008-12-21 04:19:26 EST
Okay, I need some help to track this down as I don't have local access to an X64 system (remote system being no good to track down OpenGL issues). Please do use the latest F-10 build version (0.6.7.0-7). Looking at the Koji x64 build logs, it does look normal (it finds the OpenGL libraries in /usr/lib64).

What does 'ldd /usr/bin/k3d-bin' return ?


I'll work on packaging 0.7.10 for rawhide, but we need to track this issue first.
Comment 7 Orlando Arias 2008-12-21 05:37:27 EST
Ahoy there! I've got some interesting news.

Removed the k3d install I did from svn, but before I ldd'ed the binary.
$ cat k3d-build.ldd.out 
	linux-vdso.so.1 =>  (0x00007fffc2bfe000)
	libk3dsdk.so => /usr/local/lib/libk3dsdk.so (0x00007f58b9f19000)
	libboost_program_options.so.3 => /usr/lib64/libboost_program_options.so.3 (0x0000000000110000)
	libglibmm-2.4.so.1 => /usr/lib64/libglibmm-2.4.so.1 (0x000000358d600000)
	libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x000000357f800000)
	libsigc-2.0.so.0 => /usr/lib64/libsigc-2.0.so.0 (0x0000003597200000)
	libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x000000357f000000)
	libexpat.so.1 => /lib64/libexpat.so.1 (0x0000003581800000)
	libz.so.1 => /lib64/libz.so.1 (0x000000357e800000)
	libk3dsdk-half.so => /usr/local/lib/libk3dsdk-half.so (0x0000000000630000)
	libk3dsdk-sgi-tesselator.so => /usr/local/lib/libk3dsdk-sgi-tesselator.so (0x0000000000873000)
	libk3dsdk-glew.so => /usr/local/lib/libk3dsdk-glew.so (0x0000000000a83000)
	libGL.so.1 => /usr/lib64/nvidia/libGL.so.1 (0x0000003594200000)
	libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x0000003275600000)
	libk3dsdk-parallel.so => /usr/local/lib/libk3dsdk-parallel.so (0x00007f58b9d13000)
	libuuid.so.1 => /lib64/libuuid.so.1 (0x0000003589a00000)
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x000000358be00000)
	libm.so.6 => /lib64/libm.so.6 (0x000000357dc00000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003588e00000)
	libc.so.6 => /lib64/libc.so.6 (0x000000357d800000)
	libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x0000003581000000)
	libGLcore.so.1 => /usr/lib64/nvidia/libGLcore.so.1 (0x0000003443600000)
	libnvidia-tls.so.1 => /usr/lib64/nvidia/tls/libnvidia-tls.so.1 (0x0000003443400000)
	libXext.so.6 => /usr/lib64/libXext.so.6 (0x0000003581c00000)
	libX11.so.6 => /usr/lib64/libX11.so.6 (0x0000003580000000)
	libdl.so.2 => /lib64/libdl.so.2 (0x000000357e000000)
	/lib64/ld-linux-x86-64.so.2 (0x000000357d400000)
	libXau.so.6 => /usr/lib64/libXau.so.6 (0x000000357fc00000)
	libxcb-xlib.so.0 => /usr/lib64/libxcb-xlib.so.0 (0x0000003580800000)
	libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x0000003580c00000)
	libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x0000003580400000)


Those are the results, after I removed that, I installed the one on the repo as you asked, and here's the output of ldd:
$ cat k3d-distro.ldd.out 
	linux-vdso.so.1 =>  (0x00007ffff33ff000)
	libk3dsdk.so.0 => /usr/lib64/libk3dsdk.so.0 (0x00007f5beac20000)
	libz.so.1 => /lib64/libz.so.1 (0x000000357e800000)
	libglibmm-2.4.so.1 => /usr/lib64/libglibmm-2.4.so.1 (0x000000358d600000)
	libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x000000357f800000)
	libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x000000357f000000)
	libsigc-2.0.so.0 => /usr/lib64/libsigc-2.0.so.0 (0x0000003597200000)
	libGL.so.1 => /usr/lib64/libGL.so.1 (0x0000003272600000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x000000357e400000)
	libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x0000003275600000)
	libexpat.so.1 => /lib64/libexpat.so.1 (0x0000003581800000)
	libboost_date_time.so.3 => /usr/lib64/libboost_date_time.so.3 (0x0000003447a00000)
	libboost_regex.so.3 => /usr/lib64/libboost_regex.so.3 (0x0000003447e00000)
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x000000358be00000)
	libm.so.6 => /lib64/libm.so.6 (0x000000357dc00000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003588e00000)
	libc.so.6 => /lib64/libc.so.6 (0x000000357d800000)
	libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x0000003581000000)
	libX11.so.6 => /usr/lib64/libX11.so.6 (0x0000003580000000)
	libXext.so.6 => /usr/lib64/libXext.so.6 (0x0000003581c00000)
	libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x0000003595a00000)
	libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x0000003584c00000)
	libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x0000003585000000)
	libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x0000003581400000)
	libdl.so.2 => /lib64/libdl.so.2 (0x000000357e000000)
	/lib64/ld-linux-x86-64.so.2 (0x000000357d400000)
	libicui18n.so.40 => /usr/lib64/libicui18n.so.40 (0x0000003588600000)
	libicuuc.so.40 => /usr/lib64/libicuuc.so.40 (0x0000003587e00000)
	libxcb-xlib.so.0 => /usr/lib64/libxcb-xlib.so.0 (0x0000003580800000)
	libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x0000003580c00000)
	libXau.so.6 => /usr/lib64/libXau.so.6 (0x000000357fc00000)
	libicudata.so.40 => /usr/lib64/libicudata.so.40 (0x0000003063600000)
	libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x0000003580400000)


Now, here's where things get interesting:
-- my build
	libGL.so.1 => /usr/lib64/nvidia/libGL.so.1 (0x0000003594200000)
-- the one in the distro
	libGL.so.1 => /usr/lib64/libGL.so.1 (0x0000003272600000)

Digging a bit deeper, I found that /usr/lib64/libGL.so.1 is a symlink pointing to /usr/lib64/libGL.so.1.2, I removed this symlink and made a new one to /usr/lib64/nvidia/libGL.so.1 and k-3d launches now. To spare you the trouble of asking or checking

# yum provides /usr/lib64/libGL.so.1.2
mesa-libGL-7.2-0.15.fc10.x86_64 : Mesa libGL runtime libraries and DRI drivers
Repo        : installed
Matched from:
Filename    : /usr/lib64/libGL.so.1.2

# yum provides /usr/lib64/libGL.so.1
mesa-libGL-7.2-0.15.fc10.x86_64 : Mesa libGL runtime libraries and DRI drivers
Repo        : installed
Matched from:
Other       : Provides-match: /usr/lib64/libGL.so.1

Mesa is indirect rendering, whilst the libGL.so.1 provided by the nvidia driver should have direct rendering. Apps compiled towards libGL.so.1 should work the same with either one, I should think, so leaving the symlink as I have it now should cause no adverse consequences. I still don't know why k-3d wouldn't allow mesa to do its bidding though. In any case, there you have it. Let me know if more info is needed and whether or not I should go bug the guys at YouKnowWhichRepo :P.

Cheers and Thanks, Orlando.
Comment 8 Denis Leroy 2008-12-22 02:47:19 EST
This very much sounds like an NVIDIA installation problem. Did you install it manually with their provided script, or are you using the Livna/rpmfusion package ?

If you're using the nvidia driver, it's important the libGL symlink to Nvidia's versions. I'm going to close this as NOTABUG, unless somebody can reproduce the problem with the Intel or Radeon driver...
Comment 9 Orlando Arias 2008-12-22 03:09:55 EST
I am using the driver found at rpmfusion. I didn't want to explicitly say the repo name since Red Hat is based on the USA and all that legal mumbo-jumbo. Like I pointed out before, it seems like the issue is with Mesa's libGL and not K-3D. Once I switched the symlink /usr/lib64/libGL.so.1 from /usr/lib64/libGL.so.1.2 which is provided by the mesa-libGL packages to /usr/lib64/nvidia/libGL.so.1 (which in part symlinks to nvidia's own libGL) K-3D launches properly.

My old laptop has an ATI card (Radeon IGP 345M), but it's a pentium 4 (32bit processor) and the screen is busted so I can't test things out there. As you said before, it might be an x86_64 specific thing. It still boggles the mind though, the ./configure script even with the symlink changed won't detect OpenGL.

Do as you need to do. Like I said, K-3D is only a hobby to me, also, with the "fix" I made, I got the repo's version to work. In case an update breaks the symlink I can always redo the process of creating it again.

Cheers and Thanks, Orlando.
Comment 10 Richard Shaw 2008-12-22 09:49:52 EST
Yes, symlinking to the nvidia libGL.so fixed it for me as well. I'm also using the rpmfusion akmod package.

Thanks,
Richard
Comment 11 Denis Leroy 2008-12-22 11:12:52 EST
Closing then. May want to file a bug against the rpmfusion owner.

The manual build missing the lib64 opengl lib is a known problem: the Fedora SRPM hsa a patch to fix this already.
Comment 12 Alexey Torkhov 2008-12-23 06:10:13 EST
I have same problems with K-3D.

Following is invalid:
> If you're using the nvidia driver, it's important the libGL symlink to Nvidia's
> versions. I'm going to close this as NOTABUG, unless somebody can reproduce the
> problem with the Intel or Radeon driver...

libGL must _not_ be symlink to nvidia version because kmod package must not change anything in existing mesa packages. Kmod package does substitution of library by creating file in /etc/ld.so.conf.d that puts /usr/lib64/nvidia before /usr/lib64 in library loading path. That way mesa and nvidia libGL both live on one system.

But k3d binary contains rpath - hardcoded library search path to /usr/lib64 and because of this mesa lib is loaded. After removing it with chrpath utility all is working fine.

Please remove the rpath from k3d binary according to package guidelines: http://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath

Reopening the bug.
Comment 13 Denis Leroy 2008-12-26 07:03:18 EST
Sounds plausible, thanks for the explanation. It's strange that K-3D does not use RPATH on i386, but would on x86_64 though... Richard, could you give me the output of

> readelf -d /usr/bin/k3d-bin | grep RPATH

If the output is non-empty, could you try to rebuild the K-3D RPM on x86_64 when adding the "--disable-rpath" option to the configure line in the RPM spec file ?
Comment 14 Orlando Arias 2008-12-26 08:03:19 EST
Hey there, just when I thought I had a decent understanding on how this OS works, I get proven that I am not even quarter of a way right. Anyway, as per request:

$ readelf -d /usr/bin/k3d-bin | grep RPATH
 0x000000000000000f (RPATH)              Library rpath: [/usr/lib64]

I did some murking around the configure script to get it to recognize OpenGL libraries on my system and ran it with --disable-rpath, makefiles were created, but then make exited with errors.

/bin/sh ../../libtool --tag=CXX   --mode=compile g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"k3d\" -DVERSION=\"0.6.7.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSIZEOF_VOIDP=8 -DK3D_PLATFORM_POSIX=1 -DHAPY_HAVE_NUMERIC_LIMITS=1 -DHAPY_HAVE_STD_ITERATOR_TYPE=1 -DK3D_HAVE_EXPAT=1 -DHAVE_LIBBOOST_REGEX=1 -DHAVE_LIBBOOST_DATE_TIME=1 -DK3D_HAVE_SVG_ICONS=1 -I.  -I../.. -I../.. -I../../hapy/src/include  -Wall -Wno-ctor-dtor-privacy -g -O2 -MT Assert.lo -MD -MP -MF .deps/Assert.Tpo -c -o Assert.lo Assert.cc
 g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"k3d\" -DVERSION=\"0.6.7.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSIZEOF_VOIDP=8 -DK3D_PLATFORM_POSIX=1 -DHAPY_HAVE_NUMERIC_LIMITS=1 -DHAPY_HAVE_STD_ITERATOR_TYPE=1 -DK3D_HAVE_EXPAT=1 -DHAVE_LIBBOOST_REGEX=1 -DHAVE_LIBBOOST_DATE_TIME=1 -DK3D_HAVE_SVG_ICONS=1 -I. -I../.. -I../.. -I../../hapy/src/include -Wall -Wno-ctor-dtor-privacy -g -O2 -MT Assert.lo -MD -MP -MF .deps/Assert.Tpo -c Assert.cc  -fPIC -DPIC -o .libs/Assert.o
Assert.cc: In function 'void Hapy::Abort(const char*, int, const char*)':
Assert.cc:19: error: '::abort' has not been declared
Assert.cc: In function 'void Hapy::Exit(const char*, int, const char*)':
Assert.cc:25: error: '::exit' has not been declared
Assert.cc: In function 'void Hapy::Exit()':
Assert.cc:30: error: '::exit' has not been declared
Assert.cc:32: error: '::exit' has not been declared
make[3]: *** [Assert.lo] Error 1
make[3]: Leaving directory `/home/tron/src/tar/k3d-0.6.7.0/hapy/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/tron/src/tar/k3d-0.6.7.0/hapy/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/tron/src/tar/k3d-0.6.7.0/hapy'
make: *** [all-recursive] Error 1


I took a peek at the sources, and well, my knowledge of C is abysmal to fix this thing. This is not the kind of thing I sometimes do updating deprecated API in some old application, or at least it doesn't look like it. If you can provide me a patch (or somebody else can compile it with no issues), feel free to inform. Cheers and Thanks, Orlando.

PS. If anybody wants/needs my quick and dirty (emphasis on that last part) patch to detect OpenGL, here it is:

--- configure~	2008-12-26 07:36:09.000000000 -0500
+++ configure	2008-12-26 07:57:43.000000000 -0500
@@ -20382,7 +20382,11 @@
 echo $ECHO_N "checking for OpenGL... $ECHO_C" >&6; }
 
 k3d_check_opengl_lib_dir=""
-k3d_check_opengl_directories="/usr/lib64 /usr/local/lib64 /usr/X11R6/lib64"
+if [ $(./config.guess) = "x86_64-unknown-linux-gnu" ]; then
+	k3d_check_opengl_directories="/usr/lib64 /usr/local/lib64 /usr/X11R6/lib64"
+else
+	k3d_check_opengl_directories="/usr/lib /usr/local/lib /usr/X11R6/lib"
+fi
 for k3d_check_opengl_directory in $k3d_check_opengl_directories; do
 	if test -f $k3d_check_opengl_directory/libGL.so || test -f $k3d_check_opengl_directory/libGL.a || test -f $k3d_check_opengl_directory/libGL.dll.a; then
 		k3d_check_opengl_lib_dir=$k3d_check_opengl_directory
@@ -20416,7 +20420,11 @@
 echo $ECHO_N "checking for OpenGLU... $ECHO_C" >&6; }
 
 k3d_check_openglu_lib_dir=""
-k3d_check_openglu_directories="/usr/lib64 /usr/local/lib64 /usr/X11R6/lib64"
+if [ $(./config.guess) = "x86_64-unknown-linux-gnu" ]; then
+	k3d_check_openglu_directories="/usr/lib64 /usr/local/lib64 /usr/X11R6/lib64"
+else
+	k3d_check_openglu_directories="/usr/lib /usr/local/lib /usr/X11R6/lib"
+fi
 for k3d_check_openglu_directory in $k3d_check_openglu_directories; do
 	if test -f $k3d_check_openglu_directory/libGLU.so || test -f $k3d_check_openglu_directory/libGLU.a || test -f $k3d_check_openglu_directory/libGLU.dll.a; then
 		k3d_check_openglu_lib_dir=$k3d_check_openglu_directory
Comment 15 Orlando Arias 2008-12-26 08:12:17 EST
And where is the edit button when I need one :P. I knew something had to be wrong in that previous reply:

--- configure~ 2008-12-26 07:36:09.000000000 -0500
+++ configure 2008-12-26 07:57:43.000000000 -0500
@@ -20382,7 +20382,11 @@
 echo $ECHO_N "checking for OpenGL... $ECHO_C" >&6; }

 k3d_check_opengl_lib_dir=""
-k3d_check_opengl_directories="/usr/lib /usr/local/lib /usr/X11R6/lib"
+if [ $(./config.guess) = "x86_64-unknown-linux-gnu" ]; then
+ k3d_check_opengl_directories="/usr/lib64 /usr/local/lib64 /usr/X11R6/lib64"
+else
+ k3d_check_opengl_directories="/usr/lib /usr/local/lib /usr/X11R6/lib"
+fi
 for k3d_check_opengl_directory in $k3d_check_opengl_directories; do
  if test -f $k3d_check_opengl_directory/libGL.so || test -f
$k3d_check_opengl_directory/libGL.a || test -f
$k3d_check_opengl_directory/libGL.dll.a; then
   k3d_check_opengl_lib_dir=$k3d_check_opengl_directory
@@ -20416,7 +20420,11 @@
 echo $ECHO_N "checking for OpenGLU... $ECHO_C" >&6; }

 k3d_check_openglu_lib_dir=""
-k3d_check_openglu_directories="/usr/lib /usr/local/lib /usr/X11R6/lib"
+if [ $(./config.guess) = "x86_64-unknown-linux-gnu" ]; then
+ k3d_check_openglu_directories="/usr/lib64 /usr/local/lib64 /usr/X11R6/lib64"
+else
+ k3d_check_openglu_directories="/usr/lib /usr/local/lib /usr/X11R6/lib"
+fi
 for k3d_check_openglu_directory in $k3d_check_openglu_directories; do
  if test -f $k3d_check_openglu_directory/libGLU.so || test -f
$k3d_check_openglu_directory/libGLU.a || test -f
$k3d_check_openglu_directory/libGLU.dll.a; then
   k3d_check_openglu_lib_dir=$k3d_check_openglu_directory


I can't trust the filesystem cache that often.
Comment 16 Denis Leroy 2008-12-26 10:03:09 EST
Orlando, you should compile from the Fedora source RPM. If you compile from source directly, you should first apply the patches included in the Fedora SRPM (which fix the OpenGL detection issue), as well as use the configure script options used in the SRPM spec file.
Comment 17 Richard Shaw 2008-12-26 16:33:04 EST
(In reply to comment #13)
> Sounds plausible, thanks for the explanation. It's strange that K-3D does not
> use RPATH on i386, but would on x86_64 though... Richard, could you give me the
> output of
> 
> > readelf -d /usr/bin/k3d-bin | grep RPATH
> 
> If the output is non-empty, could you try to rebuild the K-3D RPM on x86_64
> when adding the "--disable-rpath" option to the configure line in the RPM spec
> file ?

I got the same result from readelf as Orlando.

My first build attempt was from the Fedora src.rpm but it failed at the check-rpaths step (now I know why). I could only get a successful build by allowing standard rpaths.

I added the "--disable-rpath" to the configure line as follows:

%build
#(Original) %configure --disable-static --with-external-boost
%configure --disable-static --with-external-boost --disable-rpath
make %{?_smp_mflags}

Is that the correct way to do it? If so, I still got the same rpath-error. Sorry, I don't build from source often so if I did something wrong let me know.

Richard
Comment 18 Orlando Arias 2008-12-26 20:57:18 EST
Richard, what you did there seems fine, it seems tho that the configure script will ignore the --disable-rpath switch.

I'm fairly new to rpmbuild (i.e. started using it today). I've followed pretty much all suggestions found in http://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath to no avail.

I did grep thru all the sources found on the srpm package and well, found quite a few instances of -rpath in them. I don't know how to use sed too well to remove them. I'll go manually later tonight and remove them to see what happens (this will take a while). If it works ok afterwards, I'll submit a patched spec file.

Cheers and Thanks, Orlando.
Comment 19 Richard Shaw 2008-12-27 00:13:29 EST
I followed the second option for removing rpath and the build was a success. I installed the binary RPM and ran k3d and everything seems all right. I no longer need libGL.so symlinked to nvidia/libGL.so.

I inserted the following two lines from the packaging guidelines[1] just after the stock %configure line in k3d.spec:
---
sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool
sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
---

Richard

[1] http://fedoraproject.org/wiki/Packaging/Guidelines#Removing_Rpath
Comment 20 Orlando Arias 2008-12-27 01:23:04 EST
Weird, I tried that twice and the problem wasn't fixed for me. I must be doing something wrong... I'll retry it again. If this works then we can song and dance and bury this issue for good.
Comment 21 Denis Leroy 2008-12-27 01:30:55 EST
I just launched a koji build with the proposed fix. Please let me know if the x86_64 RPM works for you:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1022657
Comment 22 Orlando Arias 2008-12-27 01:57:28 EST
(In reply to comment #19)
> I followed the second option for removing rpath and the build was a success. I
> installed the binary RPM and ran k3d and everything seems all right. I no
> longer need libGL.so symlinked to nvidia/libGL.so.
> 
> I inserted the following two lines from the packaging guidelines[1] just after
> the stock %configure line in k3d.spec:
> ---
> sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool
> sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
> ---
> 
> Richard
> 
> [1] http://fedoraproject.org/wiki/Packaging/Guidelines#Removing_Rpath

Excellent, like they say, third time is the charm. Tried this and it worked, must have had mistyped something in vim. For reference, here's the patch for k3d.spec

--- k3d.spec.old	2008-12-27 01:52:29.000000000 -0500
+++ k3d.spec	2008-12-27 01:34:28.000000000 -0500
@@ -82,7 +82,9 @@
 
 
 %build
-%configure --disable-static --with-external-boost
+%configure --disable-static --with-external-boost --disable-rpath
+sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool
+sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
 make %{?_smp_mflags}


Now all we have to do is wait for the koji job to be done.
Comment 23 Richard Shaw 2008-12-27 08:31:24 EST
(In reply to comment #22)
> (In reply to comment #19)
> > I followed the second option for removing rpath and the build was a success. I
> > installed the binary RPM and ran k3d and everything seems all right. I no
> > longer need libGL.so symlinked to nvidia/libGL.so.
> > 
> > I inserted the following two lines from the packaging guidelines[1] just after
> > the stock %configure line in k3d.spec:
> > ---
> > sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool
> > sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
> > ---
> > 
> > Richard
> > 
> > [1] http://fedoraproject.org/wiki/Packaging/Guidelines#Removing_Rpath
> 
> Excellent, like they say, third time is the charm. Tried this and it worked,
> must have had mistyped something in vim. For reference, here's the patch for
> k3d.spec
> 
> --- k3d.spec.old 2008-12-27 01:52:29.000000000 -0500
> +++ k3d.spec 2008-12-27 01:34:28.000000000 -0500
> @@ -82,7 +82,9 @@
> 
> 
>  %build
> -%configure --disable-static --with-external-boost
> +%configure --disable-static --with-external-boost --disable-rpath
> +sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g'
> libtool
> +sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
>  make %{?_smp_mflags}
> 
> 
> Now all we have to do is wait for the koji job to be done.

Not that it probably matters but I went ahead and removed the "--disable-rpath" configure option for my build since it didn't seem to do anything.

Richard
Comment 24 Richard Shaw 2008-12-27 08:38:07 EST
Just tried the Koji build, seems to work just fine.

Richard
Comment 25 Orlando Arias 2008-12-27 10:48:42 EST
I can confirm the same. Suggest closing bug as fixed and pushing update to repos, unless 0.7.1 is ready for deployment.
Comment 26 Fedora Update System 2008-12-28 04:35:07 EST
k3d-0.6.7.0-8.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/k3d-0.6.7.0-8.fc10
Comment 27 Fedora Update System 2008-12-30 18:50:37 EST
k3d-0.6.7.0-8.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update k3d'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2008-11915
Comment 28 Fedora Update System 2009-01-14 22:02:53 EST
k3d-0.6.7.0-8.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.