Date: Thu, 11 Dec 2008 10:58:08 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: des@des.no Cc: freebsd-mips@freebsd.org Subject: Re: svn commit: r185925 - in head/contrib/binutils: bfd gas/config ld/emulparams Message-ID: <20081211.105808.-1186640207.imp@bsdimp.com> In-Reply-To: <20081211.100636.631212415.imp@bsdimp.com> References: <200812110822.mBB8MKLd059320@svn.freebsd.org> <86oczjklk8.fsf@ds4.des.no> <20081211.100636.631212415.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 modul=
es:
: =
: 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 funct=
ion `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):/sr=
c/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 dete=
rmine
: : whether it is building static or shared modules is as follows:
: :
: : #if defined(__GNUC__) && !defined(__PIC__) && !defined(NO_STATIC_MO=
DULES)
: =
: I think the problem here is a confusion between 'static vs dynamic' a=
nd
: '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?
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081211.105808.-1186640207.imp>