When trying to compile pyxf86config on amd64, the compile fails. The ebuild does not have amd64 keywords yet, but I believe having these is desireable. The reason is that by default, it does not compile its shared libraries with -fPIC. When adding -fPIC to the ebuild, it still fails because it links to xorg's (non-fPIC) /usr/lib64/libxf86config.a. I tried this with both the current pyxf86config-0.3.30 and with a bumped ebuild for pyxf86config-0.3.33 (see attachments). Also tried with xorg-server-1.2.0-r3 and 1.3.0.0. If this is a bug in xorg-server, please reassign.
Created attachment 122482 [details] pyxf86config-0.3.33.ebuild Ebuild that was (also) used for compiling this with -fPIC. You could use this to version bump :-)
Created attachment 122483 [details, diff] pyxf86config-0.3.33.ebuild Patch to add -fPIC
Created attachment 122485 [details] Output of compile with -fPIC
Created attachment 122486 [details] Output of compile without -fPIC
Created attachment 122487 [details] emerge --info
Reassigning to x11, as I believe this is a xorg bug. I'll attach a patch that Redhat includes in their xorg-server sources since 1.0.1. The attached patch fixes the problem (along with the pyxf86config-0.3.33.ebuild + patch earlier).
Created attachment 122490 [details, diff] xorg-x11-server-1.0.1-fpic-libxf86config.patch from fedora
Created attachment 122842 [details, diff] 1.3.0.0-shared-xf86config.patch Second solution that libtools the library so a non-PIC .a and a PICed .a can be built.
(In reply to comment #8) > Created an attachment (id=122842) [edit] > 1.3.0.0-shared-xf86config.patch > > Second solution that libtools the library so a non-PIC .a and a PICed .a can be > built. Looks mostly good. I assume you meant "PICed .so" above. In the patch, the reference to ../../...foo.la should be relative to $(top_builddir) instead of using ..'s.
What's the current status of this?
(In reply to comment #10) > What's the current status of this? I'd like a way to split this into an entirely standalone package upstream with separate releases etc. But I suspect git will, at best, force me to have a humongous repo with all history from the full X server. My goal is to somehow get it separate, but apparently file slicing of this type is not yet available in git (and may never be?).
(In reply to comment #11) > I'd like a way to split this into an entirely standalone package upstream with > separate releases etc. I appreciate the effort, but for the current release splitting the package is not option anymore. If the bug could be fixed before 1.3.0 enters stable, it would avoid stable systems from recompiling to fix the issue and would enable amd64 to use the virt-manager.
I agree, but I'm not interested in adding patches that will be in Gentoo indefinitely. That's why I want a clear route to an upstream solution.
Added the simple PIC .a patch to 1.3.0.0. I'm going to mark this UPSTREAM now for a better solution.