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.
Created attachment 85822 [details] Log of the failed configure command for GDM
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?
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.
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
sorry for the bug spam, see previous comment
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.
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.
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.
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.
