Date: Thu, 11 Dec 2008 13:08:30 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: xcllnt@mac.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: <20081211.130830.1365011002.imp@bsdimp.com> In-Reply-To: <A3EBA690-6598-4007-8E65-24F50FA2ECE3@mac.com> References: <20081211.100636.631212415.imp@bsdimp.com> <20081211.105808.-1186640207.imp@bsdimp.com> <A3EBA690-6598-4007-8E65-24F50FA2ECE3@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <A3EBA690-6598-4007-8E65-24F50FA2ECE3@mac.com>
Marcel Moolenaar <xcllnt@mac.com> writes:
: =
: 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 =
: > breaks in
: > : : libpam, while building the static version, which includes all =
: > 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 =
: > function `pam_sm_open_session':
: > : : /src/lib/libpam/modules/pam_deny/pam_deny.c:80: multiple =
: > definition of `pam_sm_open_session'
: > : : ../modules/pam_chroot/libpam_chroot.a(pam_chroot.o)(.text+0x14)=
:/ =
: > src/lib/libpam/modules/pam_chroot/pam_chroot.c:54: first defined he=
re
: > : : [lather, rinse, repeat for every service function in every modu=
le]
: > : :
: > : : The service functions should be static. The logic PAM uses to =
=
: > determine
: > : : whether it is building static or shared modules is as follows:
: > : :
: > : : #if defined(__GNUC__) && !defined(__PIC__) && ! =
: > defined(NO_STATIC_MODULES)
: > :
: > : I think the problem here is a confusion between 'static vs =
: > 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 h=
ad
: > : 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 call=
ing
: > conventions. Everything is always compiled PIC. There's a way to
: > disable this for the kernel, -mnoabicalls, but in userland that's w=
hat
: > 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 compilin=
g
: > for a static library or a dynamic library doesn't matter: __PIC__ i=
s
: > 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...
I'm not sure i follow your suggestion...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081211.130830.1365011002.imp>