Attempting an upgrade as per summary line fails with the following diagnostic relating to nvidia support: [ebuild U ] gnome-extra/sensors-applet-2.2.1 [1.8.2] USE="hddtemp libnotify lm_sensors nvidia -debug" 0 kB [ebuild R ] x11-drivers/nvidia-drivers-169.09 USE="acpi gtk -custom-cflags (-multilib)" 0 kB ... x86_64-pc-linux-gnu-gcc -shared .libs/nvidia-plugin.o -Wl,--rpath -Wl,/var/tmp/portage/gnome-extra/sensors-applet-2.2.1/work/sensors-applet-2.2.1/lib/.libs /usr/lib64/libX11.so /usr/lib64/libXext.so /usr/lib64/libglib-2.0.so -lXNVCtrl ../../lib/.libs/libsensors-applet-plugin.so -march=nocona -mtune=nocona -mmmx -msse -msse2 -msse3 -mfpmath=sse -Wl,-soname -Wl,libnvidia.so -o .libs/libnvidia.so /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/../../../../lib64/libXNVCtrl.a(NVCtrl.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/../../../../lib64/libXNVCtrl.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[2]: *** [libnvidia.la] Error 1 make[2]: Leaving directory `/var/tmp/portage/gnome-extra/sensors-applet-2.2.1/work/sensors-applet-2.2.1/plugins/nvidia' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/gnome-extra/sensors-applet-2.2.1/work/sensors-applet-2.2.1/plugins' make: *** [all-recursive] Error 1 * * ERROR: gnome-extra/sensors-applet-2.2.1 failed. * Call stack: * ebuild.sh, line 46: Called src_compile * environment, line 2577: Called gnome2_src_compile * environment, line 1963: Called die * The specific snippet of code: * emake || diefunc "$FUNCNAME" "$LINENO" "$?" "compile failure" * The die message: * compile failure Reproducible: Always Steps to Reproduce: 1.emerge sensors-applet (upgrade to 2.2.1 with nvidia support) 2. 3. Actual Results: Build fails. Expected Results: Successful build.
Eh, nicely broken...
Sweet, I can confirm this exact same error for me on AMD64. Nice to know I'm not alone in my misery. Upstream's code sucketh mightily.
I've submitted this upstream. If there's no traction, I'll remove the nvidia flag.
(In reply to comment #3) > I've submitted this upstream. If there's no traction, I'll remove the nvidia > flag. Well, let's hope upstream fixes it then, since that's clearly not the best solution. It's better to simply not upgrade (at least never stabilize that version) than to upgrade but get some severe functionality loss.
Sensors Applet 2.2.0 changed to build separate shared libraries for each plugin, and to load these dynamically - it works for me - so the problem must be a combination of portage and sensors-applet - could it be a sandbox issue? Can you try building it outside of portage and tell me if the same error occurs, since it works for me under ubuntu and fedora.
This is the error I am getting both inside and outside of portage: x86_64-pc-linux-gnu-gcc -shared .libs/nvidia-plugin.o -Wl,--rpath -Wl,/var/tmp/portage/gnome-extra/sensors-applet-2.2.1/work/sensors-applet-2.2.1/lib/.libs /usr/lib64/libX11.so /usr/lib64/libXext.so /usr/lib64/libglib-2.0.so -lXNVCtrl ../../lib/.libs/libsensors-applet-plugin.so -march=nocona -Wl,-soname -Wl,libnvidia.so -o .libs/libnvidia.so /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../lib64/libXNVCtrl.a(NVCtrl.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
I can see the error, but atleast on x86 I can't reproduce it - as far as I know, the nvidia-plugin for sensors applet only dynamically links against the libXNVCtrl lib, so unless the portage version of libXNVCtrl is not built to be dynamically linked, then I can't see why this error is occurring - I am building nvidia-settings from source, rather than in portage, so from what I can see, this is either an x86_64 specific issue, or portage specific - I am a bit stumped on this one, so any insight any of you could give would be appreciated - more so than criticism.
(In reply to comment #7) Well, as you can see from that output above, it definitely tries to link libXNVCtrl statically into a shared object. You won't get the above -fPIC error on x86 since the -fPIC stuff doesn't affect x86 so it doesn't fail, nevertheless it's completely broken.
Well, and since media-video/nvidia-settings fails to provide a shared libXNVCtrl, obviously the bug is there. <snip> # for a rainy day, when we need a shared libXNVCtrl.so #-e 'a#define DoSharedLib YES\n' \ <snip>
Today I was trying to make a python wrapper for XNVCtrl but: swig -python -I/usr/include/ pyNVCtrl.i gcc -fPIC -c pyNVCtrl_wrap.c -I/usr/include/python2.4/ ld -shared pyNVCtrl_wrap.o -o pyNVCtrl.so -lXNVCtrl -lX11 -lXext ld: /usr/lib64/libXNVCtrl.a(NVCtrl.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib64/libXNVCtrl.a: could not read symbols: Bad value make: *** [all] Error 1 So I made a quick fix allowing me to relink against the static lib on AMD64. nvidia-settings also works with the fix. # SOF --- /usr/portage/media-video/nvidia-settings/nvidia-settings-169.07.ebuild 2008-03-06 23:06:44.000000000 +0000 +++ /usr/local/portage/media-video/nvidia-settings/nvidia-settings-169.07.ebuild 2008-03-08 19:11:51.397985413 +0000 @@ -64,6 +64,10 @@ cd "${S}/src/libXNVCtrl" xmkmf -a || die "Running xmkmf failed!" make clean || die "Cleaning old libXNVCtrl failed" + # See #207543 and #212536 + sed -i.orig \ + -e 's;$(CC) -c $(CFLAGS);$(CC) $(PICFLAGS) -c $(CFLAGS);' \ + Makefile emake CDEBUGFLAGS="${CFLAGS}" CC="$(tc-getCC)" all || die "Building libXNVCtrl failed!" cd "${S}" # EOF
Same error here on AMD64.
(In reply to comment #10) > Today I was trying to make a python wrapper for XNVCtrl but: > > swig -python -I/usr/include/ pyNVCtrl.i > gcc -fPIC -c pyNVCtrl_wrap.c -I/usr/include/python2.4/ > ld -shared pyNVCtrl_wrap.o -o pyNVCtrl.so -lXNVCtrl -lX11 -lXext > ld: /usr/lib64/libXNVCtrl.a(NVCtrl.o): relocation R_X86_64_32 against `a local > symbol' can not be used when making a shared object; recompile with -fPIC > /usr/lib64/libXNVCtrl.a: could not read symbols: Bad value > make: *** [all] Error 1 > > So I made a quick fix allowing me to relink against the static lib on AMD64. > nvidia-settings also works with the fix. > > # SOF > --- /usr/portage/media-video/nvidia-settings/nvidia-settings-169.07.ebuild > 2008-03-06 23:06:44.000000000 +0000 > +++ > /usr/local/portage/media-video/nvidia-settings/nvidia-settings-169.07.ebuild > 2008-03-08 19:11:51.397985413 +0000 > @@ -64,6 +64,10 @@ > cd "${S}/src/libXNVCtrl" > xmkmf -a || die "Running xmkmf failed!" > make clean || die "Cleaning old libXNVCtrl failed" > + # See #207543 and #212536 > + sed -i.orig \ > + -e 's;$(CC) -c $(CFLAGS);$(CC) $(PICFLAGS) -c $(CFLAGS);' \ > + Makefile > emake CDEBUGFLAGS="${CFLAGS}" CC="$(tc-getCC)" all || die "Building > libXNVCtrl failed!" > > cd "${S}" > # EOF > So, you mean that with that patch. Emerge nvidia-settings followed by emerge sensors-applet should work in AMD64? If that's the idea I'll give it a try.
(In reply to comment #12) > > So, you mean that with that patch. Emerge nvidia-settings followed by emerge > sensors-applet should work in AMD64? > > If that's the idea I'll give it a try. > It doesn't work for me. I tried with nvidia-settings-173.14.05 from bug http://bugs.gentoo.org/show_bug.cgi?id=224617 and applied above patch. (amd64, gcc 4.3.1) Still the same error
Patch worked here. I patched against media-video/nvidia-settings-171.05
Maybe this should depend on bug 246364
for some reason, peper isn't in metadata.xml so I'll reassign to gnome herd.
It now merges fine as bug 246364 got finally resolved :-)
thanks for the update. Closing then.
