Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 131783

Summary: gnome-base/gdm-2.8.0.7-r1 configure fails due to mixage of PIC and non-PIC libraries
Product: Gentoo Linux Reporter: BlaisorBlade <blaisorblade_spam>
Component: [OLD] Core systemAssignee: The Gentoo Linux Hardened Team <hardened>
Status: RESOLVED NEEDINFO    
Severity: normal CC: blaisorblade_spam, gnome
Priority: High    
Version: 2006.0   
Hardware: AMD64   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: Log of the failed configure command for GDM

Description BlaisorBlade 2006-04-30 04:13:18 UTC
I think this is a toolchain related problem - I'm using GCC hardened and it compiles PIE executables.

I ran emerge -va1 =sys-devel/gcc-config-1.3.13-r2 =sys-devel/binutils-config-1.8-r7 =gnome-base/gdm-2.8.0.7-r1 =sys-apps/dbus-0.61-r1

and when merging GDM it failed with:

checking libgen.h usability... yes
checking libgen.h presence... yes
checking for libgen.h... yes
checking for X11/Xdmcp.h... yes
checking for XdmcpFlush in -lXdmcp... no
configure: error: XDMCP support requested but XDMCP libraries not found

!!! Please attach the config.log to your bug report:
!!! /var/tmp/portage/gdm-2.8.0.7-r1/work/gdm-2.8.0.7/config.log

!!! ERROR: gnome-base/gdm-2.8.0.7-r1 failed.
!!! Function econf, Line 495, Exitcode 0
!!! econf failed
!!! If you need support, post the topmost build error, NOT this status message.

I looked at the config.log (which I'll attach) and I found this (look at the second part):

configure:29793: checking for X11/Xdmcp.h
configure:29809: x86_64-pc-linux-gnu-gcc -c -march=athlon64 -O2 -pipe -fomit-frame-pointer -Wall -Wmissing-prototypes    co
nftest.c >&5
configure:29815: $? = 0
configure:29819: test -z
                         || test ! -s conftest.err
configure:29822: $? = 0
configure:29825: test -s conftest.o
configure:29828: $? = 0
configure:29839: result: yes
configure:29843: checking for XdmcpFlush in -lXdmcp
configure:29873: x86_64-pc-linux-gnu-gcc -o conftest -march=athlon64 -O2 -pipe -fomit-frame-pointer -Wall -Wmissing-prototy
pes     conftest.c -lXdmcp  -L/usr/lib64 -lX11   >&5
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object.
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libXdmcp.a(Flush.o): relocation R
_X86_64_PC32 against `sendto@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
configure:29879: $? = 1
configure: failed program was:
...

Now, I've recently learned the hard way that this error:

R_X86_64_PC32 against `sendto@@GLIBC_2.2.5' can not be used when making a shared object

 is caused by mixing of PIC and non-PIC (or PIE and non-PIE) objects - when they're compiled they use different kinds of relocations.

So, what should I do? There is the possibility that the solution is simply to recompile that library with GCC hardened so it's compiled with PIE, but I'm unsure.

Also, I'm curious why it's the first time I get such a failure? I have gnome-base/gdm-2.8.0.7 installed and I was installing gnome-base/gdm-2.8.0.7-r1; also no problem with other libraries ever surfaced, even when I yesterday installed gnome-2.12.3 and XFCE-4.2.3.2.

Indeed, both that library (in the xorg-x11 package) and the existing version of gdm were installed gcc hardened, and that library is only used for display managers, while most libraries are .so and there you can't have this problem, so I guess that it's not so strange.
Comment 1 BlaisorBlade 2006-04-30 04:15:00 UTC
Created attachment 85822 [details]
Log of the failed configure command for GDM
Comment 2 BlaisorBlade 2006-04-30 04:55:42 UTC
I've just reproduced the compilation failure for the program configure was trying to compile (config.log contain both the program and the command line used to compile it), and then I've verified that adding -fno-PIE to the cmd line makes the program compile:

Original command line:
x86_64-pc-linux-gnu-gcc -o conftest -march=athlon64 -O2 -pipe -fomit-frame-pointer -Wall -Wmissing-prototypes     conftest.c -lXdmcp  -L/usr/lib64 -lX11

Add -fno-pie and the program compiles.

So, unless I'm missing something (and that's why I'm asking) the problem is simply that installing GCC hardened means recompiling _everything_. Or at least everything providing a .a library (since .so library are always in PIC format, and we don't link against executable). Is this documented somewhere?
Comment 3 solar (RETIRED) gentoo-dev 2006-04-30 10:17:27 UTC
What provides libXdmcp.a on your system? 
Can you recompile that and see if you get a proper .so?
linking *.a and *.so have always been a bad idea and the -fno-pie is not ideal 
at all.
Comment 4 Saleem Abdulrasool (RETIRED) gentoo-dev 2006-06-28 02:01:38 UTC
reassigning to hardened as it seems to be a hardened issue, not a GNOME issue.  Due to lack of response from the reporter, marking as needinfo
Comment 5 Saleem Abdulrasool (RETIRED) gentoo-dev 2006-06-28 02:02:27 UTC
sorry for the bug spam, see previous comment
Comment 6 BlaisorBlade 2006-06-28 03:24:41 UTC
Since the box on which I worked crashed and I haven't had the time to reinstall Gentoo, I'm providing the following info off the top of my memory.
The libXdmcp.a library comes from the xorg-x11 package (as I mentioned in the first message) and it doesn't build a .so of that package (but this should be easy to verify).
I know -fno-pie isn't the optimal solution; I also tried recompiling X but met the dlloader problem, so I couldn't test if after that recompiling gdm would have worked.
Comment 7 Kevin F. Quinn (RETIRED) gentoo-dev 2006-06-28 03:59:59 UTC
Re-open when you have a system with the fault again.  When that happens, paste or attach the output of 'emerge --info'

I don't think this has anything to do with PIE as such; the problem is you don't/didn't have libXdmcp built as a shared object, which is from Xorg.
Comment 8 BlaisorBlade 2006-06-28 04:07:50 UTC
Assuming that on a normal system with xorg 6 that library is built as a shared object (have you got it on your system) what you say would be true.

However, without further hypotesis I could also suppose that library is never built as a .so and it works fine without hardened, fine with hardened when all the system is built like that, but not fine on mixed systems (like mine) where one switches hardened on in the middle of the system life.

Please at least verify what happens on _your_ system; if there is none of the above descrived situations then this resolution can be valid.
Comment 9 Kevin F. Quinn (RETIRED) gentoo-dev 2006-06-28 05:25:23 UTC
Of course it's normally used as a shared object.  Without data like 'emerge --info' we can't even guess why you didn't have it as a shared object.

The vast majority of libraries are be built as both shared (.so) and static (.a) libraries on arches that support shared libraries.  The static libraries should only used when building something as a static binary, which is rare.  However the standard build processes will link to a static library if the shared library is missing, which is what it looks like your system was doing.

We cannot proceed until the problem exists on an active system where it can be investigated and fixed.  There's really no point discussing it until then.