Date: Thu, 11 Dec 2008 11:03:45 -0800 From: Marcel Moolenaar <xcllnt@mac.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: des@des.no, freebsd-mips@freebsd.org Subject: Re: svn commit: r185925 - in head/contrib/binutils: bfd gas/config ld/emulparams Message-ID: <A3EBA690-6598-4007-8E65-24F50FA2ECE3@mac.com> In-Reply-To: <20081211.105808.-1186640207.imp@bsdimp.com> References: <200812110822.mBB8MKLd059320@svn.freebsd.org> <86oczjklk8.fsf@ds4.des.no> <20081211.100636.631212415.imp@bsdimp.com> <20081211.105808.-1186640207.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 11, 2008, at 9:58 AM, M. Warner Losh wrote: > In message: <20081211.100636.631212415.imp@bsdimp.com> > "M. Warner Losh" <imp@bsdimp.com> writes: > : In message: <86oczjklk8.fsf@ds4.des.no> > : Dag-Erling_Sm=F8rgrav <des@des.no> writes: > : : Warner Losh <imp@FreeBSD.org> writes: > : : > Author: imp > : : > Date: Thu Dec 11 08:22:20 2008 > : : > New Revision: 185925 > : : > URL: http://svn.freebsd.org/changeset/base/185925 > : : > > : : > Log: > : : > Push mips support into the tree. > : : > : : Just to pick a random mips commit - > : : > : : There is something wrong with the mips toolchain. The build =20 > breaks in > : : libpam, while building the static version, which includes all =20 > modules: > : > : Something is wrong either with the toolchain or with PAM's > : assumptions. I've not tracked it down further than that yet, but I > : think the latter. Let me explain. > : > : : ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x3c): In =20 > function `pam_sm_open_session': > : : /src/lib/libpam/modules/pam_deny/pam_deny.c:80: multiple =20 > definition of `pam_sm_open_session' > : : ../modules/pam_chroot/libpam_chroot.a(pam_chroot.o)(.text+0x14):/=20= > src/lib/libpam/modules/pam_chroot/pam_chroot.c:54: first defined here > : : [lather, rinse, repeat for every service function in every module] > : : > : : The service functions should be static. The logic PAM uses to =20 > determine > : : whether it is building static or shared modules is as follows: > : : > : : #if defined(__GNUC__) && !defined(__PIC__) && !=20 > defined(NO_STATIC_MODULES) > : > : I think the problem here is a confusion between 'static vs =20 > dynamic' and > : 'pic vs nonpic'. > : > : #ifdef __PIC__ > : int x; > : #else > : int y; > : #endif > : > : produces a .o with the symbol 'x' always. That was as far as I had > : got on looking into the problem. > > Ooops, looks like I neglected to add the following: > > The reason that it always produces 'x' has to do with the MIPS calling > conventions. Everything is always compiled PIC. There's a way to > disable this for the kernel, -mnoabicalls, but in userland that's what > all the tool chains expect. There may be other issues. I have a > fuzzy memory of some, but I can't recall any and explain them in a way > that makes sense, so I'll leave it at that. So if you are compiling > for a static library or a dynamic library doesn't matter: __PIC__ is > effectively always defined. > > Any suggestions on how to handle this problem? What about using OPENPAM_STATIC_MODULES for it? It's now defined in openpam.h as a consequence of the faulty logic. We might as well make it the pivotal flag... --=20 Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A3EBA690-6598-4007-8E65-24F50FA2ECE3>