svn commit: r185925 - in head/contrib/binutils: bfd gas/config ld/emulparams

[Marcel Moolenaar]

On Dec 11, 2008, at 12:08 PM, M. Warner Losh wrote:

> In message: <A3EBA690-6598-4007-8E65-24F50FA2ECE3 at mac.com>
>            Marcel Moolenaar <xcllnt at mac.com> writes:
> :
> : On Dec 11, 2008, at 9:58 AM, M. Warner Losh wrote:
> :
> : > In message: <20081211.100636.631212415.imp at bsdimp.com>
> : >            "M. Warner Losh" <imp at bsdimp.com> writes:
> : > : In message: <86oczjklk8.fsf at ds4.des.no>
> : > :             Dag-Erling_Smørgrav <des at des.no> writes:
> : > : : Warner Losh <imp at 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  
> here
> : > : : [lather, rinse, repeat for every service function in every  
> module]
> : > : :
> : > : : 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 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...
>
> I'm not sure i follow your suggestion...

Sorry, I was a bit cryptic.

Currently openpam.h does something like:

#if defined(__GNUC__) && !defined(__PIC__) && ! 
defined(NO_STATIC_MODULES)
#define OPENPAM_STATIC_MODULES 1
... foo ...
#else
... bar ...
#endif

Why not make OPENPAM_STATIC_MODULES a define that you put
on the compiler command line and change the code to:

#ifdef OPENPAM_STATIC_MODULES
... foo ...
#else
... bar ...
#endif

It should be fairly easy for us to add it only when needed,
given that we have different rules for building static vs
shared libraries...

-- 
Marcel Moolenaar
xcllnt at mac.com