It looks like glib needs to be built with -fPIC. I plan to build all of glib with -fPIC unless somebody objects. Since there are no executables, only libraries, it should not be an issue. (I checked this with solar and he agreed) gcc -shared -L/var/tmp/portage/pam-0.77-r1/work/Linux-PAM-0.77/lib -o pam_console.so dynamic/pam_console.o //usr/lib/libglib.a -L../pammodutil -lpammodutil -lc /usr/lib/gcc-lib/ia64-unknown-linux-gnu/3.3.3/../../../../ia64-unknown-linux-gnu/bin/ld: //usr/lib/libglib.a(gmessages.o): @gprel relocation against dynamic symbol g_log_domain_glib /usr/lib/gcc-lib/ia64-unknown-linux-gnu/3.3.3/../../../../ia64-unknown-linux-gnu/bin/ld: //usr/lib/libglib.a(gmessages.o): @gprel relocation against dynamic symbol g_log_domain_glib /usr/lib/gcc-lib/ia64-unknown-linux-gnu/3.3.3/../../../../ia64-unknown-linux-gnu/bin/ld: //usr/lib/libglib.a(gmessages.o): @gprel relocation against dynamic symbol g_log_domain_glib /usr/lib/gcc-lib/ia64-unknown-linux-gnu/3.3.3/../../../../ia64-unknown-linux-gnu/bin/ld: //usr/lib/libglib.a(gmessages.o): @gprel relocation against dynamic symbol g_log_domain_glib /usr/lib/gcc-lib/ia64-unknown-linux-gnu/3.3.3/../../../../ia64-unknown-linux-gnu/bin/ld: //usr/lib/libglib.a(gmessages.o): @gprel relocation against dynamic symbol g_log_domain_glib /usr/lib/gcc-lib/ia64-unknown-linux-gnu/3.3.3/../../../../ia64-unknown-linux-gnu/bin/ld: //usr/lib/libglib.a(gmessages.o): @gprel relocation against dynamic symbol g_log_domain_glib collect2: ld returned 1 exit status make[2]: *** [pam_console.so] Error 1 make[2]: Leaving directory `/var/tmp/portage/pam-0.77-r1/work/Linux-PAM-0.77/modules/pam_console' make[1]: *** [all] Error 1 make[1]: Leaving directory `/var/tmp/portage/pam-0.77-r1/work/Linux-PAM-0.77/modules' make: *** [modules] Error 2 !!! ERROR: sys-libs/pam-0.77-r1 failed. !!! Function src_compile, Line 214, Exitcode 2 !!! PAM build failed
THATS WRONG WRONG WRONG! all of pam, except 'pam_console_apply'(*) should link to shared glib, just like the rest of the linux world does. works perfectly fine here on amd64 and hppa and our custom pam ebuild. (*) the only part of pam possibly needed until /usr and /home are mounted; and this *IS* and executable and works fine w/ non-pic glib objects
No need to shout. glib-1.2.10-r5 already had a conditional -fPIC on alpha, amd64 and hppa. For the moment, I just removed the condition so that -fPIC is used on all arches, which is better anyway (it just happens to work on x86 presently because of loader hacks to workaround non-PIC-ness). I committed this before I saw your comment. If you have a custom pam ebuild that solves this problem in a better way, please share. Maybe the reason it's working for you is because of the -fPIC hack which was already in glib-1.2.10-r5 for alpha, amd64 and hppa?
> No need to shout. Haha, sorry about that. > glib-1.2.10-r5 already had a conditional -fPIC on alpha, amd64 and hppa.. ..which is wrong. If an object is to be linked into a shared lib, it has to be -fPIC on all arches even if ld does not complain. ***BUT***: 1. including a static lib in a shared lib even though a shared lib of the same name is available defeats the whole purpose of dynamic linking. If one single pkg really needs something crazy like that, don't punish everything else. 2. said static linking is caused by a Gentoo specific patch which does not really make sense: PAM modules may be in /lib, but you never need them until bootup is complete, what means /usr is mounted. Linking to shared glib in /usr/lib is perfectly ok in this case and is what is every one else is doing. (sorry I referred to the whole rest of the Linux world in my previous comment; because pam_console is RH specific what I meant to say is (desktop) RH world) 3. pic objects in libglib*.a make Gentoo incompatible w/ other dists from a dev's POV, irregardless of $ARCH. Even on pam_console-less systems. > If you have a custom pam ebuild that solves this problem in a better way, > please share I'd really like to but I'm afraid it would be incompatible w/ default baselayout & other things. The most important change wrt this problem is pam(_console) links to shared glib just like RH and MDK. > Maybe the reason it's working for you is because of the - fPIC hack which was > already in glib-1.2.10-r5 for alpha, amd64 and hppa? (haha, like the term 'hack') but nope, removed that hack when it first showed up.
<whisper_mode> See what happens if I don't shout? Absolutely nothing in more than 2 weeks because noone can hear me. And it's still wrong wrong wrong! bam! </whisper_mode>
Hans, thanks for the reminder. Sorry I haven't been able to look at this for a while, I've been caught up in some other bugs.
I don't think this should be an issue with the latest profiles, PAM and compiler suite as I haven't had any problems compiling PAM, so I'm closing this bug as fixed; if you still have issues please try the 2005.0 IA-64 stages.
