When I try to compile a libwnck ebuild (part of gnome 2.6-beta 1 from BreakMyGentoo) it complains about /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/X11R6/lib/libXRes.a(XRes.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC Reproducible: Always Steps to Reproduce: 1. Try to emerge libwnck-2.5.90 Actual Results: it fails with /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/X11R6/lib/libXRes.a(XRes.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC Expected Results: it should build marking major as it blocks upcomming gnome 2.6
this problem still exists, with the libwnck in portage and xfree 4.3.0-r6
*** Bug 46215 has been marked as a duplicate of this bug. ***
slightly off topic, but this bug doesnt exist in xorg (not in portage, but hopefully within a few weeks(?) when xorg makes a release) or xfree 4.3.99.902-r2.
Right. It said that in the duplicate.
eek. well, at least not the xorg part and we seem to be moving in that direction with hopefully xorg in use on livecds by 2004.2 :) I only finished compiling and testing both 14 minutes after you marked the other as a dupe.
See, that's what you get for not procrastinating.
Travis could you provide a fix for this please?
sorry about the delay, I was procrastinating. ;) (actually, I was just away for a day or two) I'll get right on it, just give me a few hours. more if I fall asleep before then ^^; (it's just after midnight)
the possible fix for this is in your dev space: http://dev.gentoo.org/~spyderous/xfree/redhat/XFree86-4.3.0-50/XFree86-4.3.0-XRes-IncludeSharedObjectInNormalLib.patch
this will take a while to test since i'm downgrading from xorg and i have to recompile just about everything... as almost anything that uses X is linked against libXinerama, which isn't provided by xfree 4.3.0 however, during my reinstall I noticed a few other problems in xfree-4.3.0-r6 that need fixing: /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/X11R6/lib/libXft.a(xftdraw.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC /usr/X11R6/lib/libXft.a: could not read symbols: Bad value collect2: ld returned 1 exit status I'm /hoping/ my fixes didnt introduce this new problem...
the patch in comment #9 fixes the libXRes error in libwnck. i'm working on the other stuff, but this bug can be closed if that patch is committed.
the host.def already has: /* Need this to build libs with -fPIC */ #undef StaticNeedsPicForShared #undef BuildLibGlxWithoutPIC #define StaticNeedsPicForShared YES #define BuildLibGlxWithoutPIC NO so .a files should already be getting -fPIC objects... am I missing something?
the generated makefile for Xft has the following: .c.o: $(_NULLCMD_) $(_NULLCMD_) $(RM) $@ unshared/$@ $(CC) -c $(CCOPTIONS) $(THREADS_CFLAGS) $(ALLDEFINES) $(CDEBUGFLAGS) $(CLIBDEBUGFLAGS) $(_NOOP_) $*.c -o unshared/$@ $(_NULLCMD_) $(RM) $@ $(CC) -c $(CFLAGS) $(_NOOP_) $(SHLIBDEF) $(SHAREDCODEDEF) $(PICFLAGS) $*.c I'm thinking I want to edit the Imakefile so that it adds "$(PICFLAGS)" to the line that compiles it's objects into "unshared"? *goes to unpack -r5 and see what changed since then to break Xft...*
the only major difference I see so far is "SHLIBLDFLAGS = -shared -Wl,-z,defs $(SHLIBGLOBALSFLAGS)".... it used to be "SHLIBLDFLAGS = -shared $(SHLIBGLOBALSFLAGS)". except for the new version of Xft, things are pretty similar... so it's not a makefile or settings thing. I'm removing that new entry from host.def, but are there any comments from someone who knows xfree better than I do? I'm starting to really dislike Imake.
Ok, "#define StaticNeedsPicForShared" doesnt get respected by Imake. The reason for that is this part of Library.tmpl: #if !DoNormalLib # define _NormalLibMkdir() $(_NULLCMD_) # define _NormalObjCompile(options) $(_NULLCMD_) # define _NormalObjCplusplusCompile(options) $(_NULLCMD_) # define _NormalCleanDir() $(_NULLCMD_) #else # if DoSharedLib && SeparateSharedCompile # define _NormalLibMkdir() _LibMkdir(unshared) # define _NormalObjCompile(options) UnsharedLibObjCompile(options) # define _NormalObjCplusplusCompile(options) UnsharedLibObjCplusplusCompile(options) # define _NormalCleanDir() LibCleanDir(unshared) # else # define _NormalLibMkdir() $(_NULLCMD_) # if !DoSharedLib && defined(IncludeSharedObjectInNormalLib) # define _NormalObjCompile(options) NormalRelocLibObjCompile(options) # else # define _NormalObjCompile(options) NormalLibObjCompile(options) # endif # define _NormalObjCplusplusCompile(options) NormalLibObjCplusplusCompile(options) # define _NormalCleanDir() $(_NULLCMD_) # endif #endif As SeparateSharedCompile is default YES, we always get to # if DoSharedLib && SeparateSharedCompile # define _NormalLibMkdir() _LibMkdir(unshared) # define _NormalObjCompile(options) UnsharedLibObjCompile(options) # define _NormalObjCplusplusCompile(options) UnsharedLibObjCplusplusCompile(options) # define _NormalCleanDir() LibCleanDir(unshared) Sadly, UnsharedLibObjCompile doesnt respect StaticNeedsPicForShared ... I'm currently testing a patch to change that. FYI: UnsharedLibObjCompile resides in xc/config/cf/Imake.rules
Created attachment 28771 [details, diff] fpic fix-o-rama This patch contains various PIC-related fixes for 4.3.0-r6: XRes, Xau, Xft, Xinerama, Xss, Xv, Xxf86dga, Xxf86misc, Xxf86vm
ok, with the fpic fix-o-rama patch I've managed to get rid of the Xres and Xft errors. However, attempting to emerge gtk+ gives me a new one: gcc -shared .libs/gdk.o .libs/gdkcolor.o .libs/gdkcursor.o .libs/gdkdisplay.o .libs/gdkdnd.o .libs/gdkdraw.o .libs/gdkevents.o .libs/gdkfont.o .libs/gdkgc.o .libs/gdkglobals.o .libs/gdkkeys.o .libs/gdkkeyuni.o .libs/gdkimage.o .libs/gdkdisplaymanager.o .libs/gdkpango.o .libs/gdkpixbuf-drawable.o .libs/gdkpixbuf-render.o .libs/gdkpixmap.o .libs/gdkpolyreg-generic.o .libs/gdkrgb.o .libs/gdkrectangle.o .libs/gdkregion-generic.o .libs/gdkscreen.o .libs/gdkselection.o .libs/gdkvisual.o .libs/gdkwindow.o .libs/gdkenumtypes.o -Wl,--whole-archive x11/.libs/libgdk-x11.a -Wl,--no-whole-archive -Wl,--rpath -Wl,/usr/lib -Wl,--rpath -Wl,/var/tmp/portage/gtk+-2.4.0/work/gtk+-2.4.0/gdk-pixbuf/.libs -Wl,--rpath -Wl,/usr/lib -L/usr/lib64 -L/usr/lib -L/usr/X11R6/lib -lXrandr -lXi -lXinerama -lXext -lXft /usr/lib/libfreetype.so -lXrender /usr/lib/libfontconfig.so -lX11 -lXcursor /usr/lib/libpangoxft-1.0.so /usr/lib/libpangox-1.0.so /usr/lib/libpango-1.0.so /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so -ldl /usr/lib/libglib-2.0.so -lm ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so -Wl,-soname -Wl,libgdk-x11-2.0.so.0 -o .libs/libgdk-x11-2.0.so.0.400.0 /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/X11R6/lib/libXrender.a(Xrender.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC /usr/X11R6/lib/libXrender.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[4]: *** [libgdk-x11-2.0.la] Error 1 make[4]: Leaving directory `/var/tmp/portage/gtk+-2.4.0/work/gtk+-2.4.0/gdk' Of course the one thing I /didnt/ touch has to break on me... but at least I think I've finally figured it out.
a quick ldd on libgtk-x11-2.0.so reveals that it would expect the following libs not fixed in the previous patch to be PIC: Xcursor, Xrender, Xext, Xi, and Xrandr. I'll make a quick patch for those and attempt yet another xfree compile...
Created attachment 28772 [details, diff] fpic fix-o-rama part 2 This patch attempts to fix: Xcursor, Xext, Xi, Xrandr, Xrender
with those two patches xfree 4.3.0-r6 appears to be fixed on amd64. gtk+-2.4.0 compiles, libwnck compiles, the server actually works, etc. with the first patch, the XRes specific one, xfree 4.3.0-r5 appears to be fixed. can somebody apply these, test them, and hopefully commit to CVS? spyderous: any comments?
while compiling xine-lib I get: gcc -shared .libs/deinterlace.o .libs/alphablend.o .libs/video_out_xvmc.o -Wl,--rpath -Wl,/var/tmp/portage/xine-lib-1_rc3-r2/work/xine-lib-1-rc3b/src/xine-engine/.libs -L/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/../../../ -L/usr/X11R6/lib -lXv -lXvMC -lXvMCNVIDIA -lXinerama -lXext ../../src/xine-engine/.libs/libxine.so -Wl,-soname -Wl,xineplug_vo_out_xvmc.so -o .libs/xineplug_vo_out_xvmc.so /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/X11R6/lib/libXvMC.a(XvMC.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC /usr/X11R6/lib/libXvMC.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[4]: *** [xineplug_vo_out_xvmc.la] Error 1 this is mentioned in more detail in bug #40646 (so it's in both r5 and r6)
This is in patchset 2.1.26.16. As of that patchset, to check your version run xdpyinfo | grep vendor. donnie@supernova xfree $ xdpyinfo | grep vendor vendor string: Gentoo Linux (The X.Org Foundation 6.7.0, revision r0-0.5) The last string (0.5) is patchset. Please confirm it's working.
This has been working great for me since the day the patches were submitted (almost two weeks ago). It is important to the amd64 devteam to get (at the very least) 4.3.0-r6 out in the wild in time for 2004.1, since Gnome 2.6 will not compile against 4.3.0-r5.
*** Bug 48261 has been marked as a duplicate of this bug. ***
xfree is officially deprecated on amd64. the fix for this bug has been added to xfree 4.3.0-r5. either recompile xfree after doing an emerge sync, or uninstall xfree and install xorg-x11 (which is, IMHO, a better solution).
"uninstall xfree and install xorg-x11" This worked although xorg-x11, xterm-184 and another dependency all needed to be manually unmasked for building on amd64. After this xine-lib-1_rc3-r3 did build correctly.
xorg-x11 and all it's dependencies (xterm+utempter) are marked as stable on amd64... it is also now the default virtual for x11. emerge sync.
