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.
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...
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]).
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.
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.
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.
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.
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.
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...
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.
Yes, symlinking to the nvidia libGL.so fixed it for me as well. I'm also using the rpmfusion akmod package. Thanks, Richard
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.
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.
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 ?
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
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.
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.
(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
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.
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
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.
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
(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.
(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
Just tried the Koji build, seems to work just fine. Richard
I can confirm the same. Suggest closing bug as fixed and pushing update to repos, unless 0.7.1 is ready for deployment.
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
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
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.