Created attachment 324876 [details] emerge --info As the summary states, I can't build / compile the latest unstable gdm with the latest unstable GCC. If I select my compiler using gcc-config and select i686-pc-linux-gnu-4.4.7 then it will build without a hitch. It fails with the following: /usr/lib/libgmodule-2.0.so.0: undefined reference to `g_rec_mutex_lock' /usr/lib/libgmodule-2.0.so.0: undefined reference to `g_private_get' /usr/lib/libgmodule-2.0.so.0: undefined reference to `g_rec_mutex_unlock' /usr/lib/libgmodule-2.0.so.0: undefined reference to `g_private_replace' collect2: ld returned 1 exit status make[3]: *** [test-settings-server] Error 1 make[3]: *** Waiting for unfinished jobs.... /usr/lib/libgmodule-2.0.so.0: undefined reference to `g_rec_mutex_lock' /usr/lib/libgmodule-2.0.so.0: undefined reference to `g_private_get' /usr/lib/libgmodule-2.0.so.0: undefined reference to `g_rec_mutex_unlock' /usr/lib/libgmodule-2.0.so.0: undefined reference to `g_private_replace' collect2: ld returned 1 exit status make[3]: *** [test-settings-client] Error 1 make[3]: Leaving directory `/var/tmp/portage/gnome-base/gdm-3.4.1-r1/work/gdm-3.4.1/common' make[2]: *** [all] Error 2 make[2]: Leaving directory `/var/tmp/portage/gnome-base/gdm-3.4.1-r1/work/gdm-3.4.1/common' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/gnome-base/gdm-3.4.1-r1/work/gdm-3.4.1' make: *** [all] Error 2
Please attach the entire build log to this bug report.
Created attachment 324930 [details] build.log
Stop doing that, please.
Jeroen says: "Stop doing that, please." What do you mean Jeroen? When I logged in to check this bug post, the title had changed to... "gnome-base/gdm-3.4.1-r1 - ?" Which was not my original post. In fact, it did not say anything about the fact gdm will not compile with gcc-4.6.3. So I changed it back. Is that why you say stop doing that? If so, I apologise. I see the bug "title" has changed again. What do you guys mean by, "garbled", as I can see the output of the build log and it does not seem to be garbled.
(In reply to comment #4) These lines are garbled: > //usrlib//liblibgmodule-/2.0.so.0: undefined reference to `libgmodule-2.0.so.0: undefined reference tog_rec_mutex_lock `'g_private_get /' > usr//lib/usr/lib/libgmodule-2.0.so.0: undefined reference to `g_rec_mutex_unlock' As for the cause of the bug: what version of dev-libs/glib are you using, and with what USE flags?
(In reply to comment #5) > (In reply to comment #4) > These lines are garbled: > > > //usrlib//liblibgmodule-/2.0.so.0: undefined reference to `libgmodule-2.0.so.0: undefined reference tog_rec_mutex_lock `'g_private_get > /' > > usr//lib/usr/lib/libgmodule-2.0.so.0: undefined reference to `g_rec_mutex_unlock' > > As for the cause of the bug: what version of dev-libs/glib are you using, > and with what USE flags? I use dev-libs/glib-2.32.4 (~) The only USE flag seems to be "xattr".
Please give the output of "ldd -d -r /usr/lib/libgmodule-2.0.so.0"
(In reply to comment #7) > Please give the output of "ldd -d -r /usr/lib/libgmodule-2.0.so.0" Hello Alexandre. as requested..... # ldd -d -r /usr/lib/libgmodule-2.0.so.0 linux-gate.so.1 (0xb77c6000) libdl.so.2 => /lib/libdl.so.2 (0xb778c000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7665000) libpthread.so.0 => /lib/libpthread.so.0 (0xb764b000) libc.so.6 => /lib/libc.so.6 (0xb74c2000) /lib/ld-linux.so.2 (0xb77c7000) librt.so.1 => /lib/librt.so.1 (0xb74b8000)
Could this perhaps be a problem with GCC as I have just encountered a similar problem trying to compile the latest ~ mjpegtools ? If I switch the compiler back to gcc-4.7.7 then it compiles fine. So this might not necessarily be a problem with gdm.
(In reply to comment #9) > Could this perhaps be a problem with GCC as I have just encountered a > similar problem trying to compile the latest ~ media-video/mjpegtools-2.0.0-r3 ? > If I switch the compiler back to gcc-4.4.7 then it compiles fine. > So this might not necessarily be a problem with gdm.
Please close this bug. It is just another example of user stupidity. I was only running source /etc/profile after updating GCC, instead of what the official Gentoo documentation states. i.e. env-update && source /etc/profile I think a gentle reminder from portage with regards to running env-update might have avoided all of this. My apologies for wasting your time.
(In reply to comment #11) OK, I'm closing as "invalid" then. Happy to hear that you had found a solution to the problem.
