A different buildworld failure

[Adriaan de Groot]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 19 March 2004 22:45, David O'Brien wrote:
> On Fri, Mar 19, 2004 at 08:53:50PM +0100, Adriaan de Groot wrote:
> > that, and lots of other similar messages. Any ideas what's going on
> > there? I don't _think_ I'm saving any weird bits of the old world - I do
> > run cleanworld before makeworld.
>
> You're linking in two objects that define the same symbol.  Maybe you
> have old libs laying around, maybe you did a 'make -DNOCLEAN'.  You've

Well I can see _that_. I'll have to experiment a little, perhaps having 
CFLAGS=-g -fPIC in make.conf isn't such a bright idea - other than that, rm 
- -rf /usr/obj ; make cleanworld buildworld keeps on giving up at this same 
place.

> seen the tenderbox builds don't have this problem, nor do I on 3
> different machines.

Well, that assumes the tinderboxes get far enough to try to _build_ pam. 
Anyway, let's not quibble on a friday night. I can see that several of the 
pam modules in contrib/openpam/modules contain pam_sm_chauthtok:

/pam_deny/pam_deny.c:pam_sm_chauthtok(pam_handle_t *pamh, int flags,
./pam_permit/pam_permit.c:pam_sm_chauthtok(pam_handle_t *pamh, int flags,
./pam_unix/pam_unix.c:pam_sm_chauthtok(pam_handle_t *pamh, int flags,

after which in openpam/lib/ it tries to link everything together in a static 
lib:

ld -o openpam_static_modules.o -r --whole-archive 
openpam_static.o ../modules/pam_chroot/libpam_chroot.a ../modules/pam_deny/libpam_deny.a ../modules/pam_echo/libpam_echo.a ../modules/pam_exec/libpam_exec.a ../modules/pam_ftpusers/libpam_ftpusers.a ../modules/pam_group/libpam_group.a ../modules/pam_guest/libpam_guest.a ../modules/pam_krb5/libpam_krb5.a ../modules/pam_ksu/libpam_ksu.a ../modules/pam_lastlog/libpam_lastlog.a ../modules/pam_login_access/libpam_login_access.a ../modules/pam_nologin/libpam_nologin.a ../modules/pam_opie/libpam_opie.a ../modules/pam_opieaccess/libpam_opieaccess.a ../modules/pam_passwdqc/libpam_passwdqc.a ../modules/pam_permit/libpam_permit.a ../modules/pam_radius/libpam_radius.a ../modules/pam_rhosts/libpam_rhosts.a ../modules/pam_rootok/libpam_rootok.a ../modules/pam_securetty/libpam_securetty.a ../modules/pam_self/libpam_self.a ../modules/pam_ssh/libpam_ssh.a ../modules/pam_tacplus/libpam_tacplus.a ../modules/pam_unix/libpam_unix.a

which of course pulls in those multiple definitions. 

> Probably not.  The amd64 GENERIC is kept fairly in sync with the i386
> one.  I'm guessing the i386 GENERIC doesn't have 'ucom' eihter.

Indeed, none of them have ucom. Weird.

- -- 
pub  1024D/FEA2A3FE 2002-06-18 Adriaan de Groot <groot at kde.org>
                     Would you like a freem?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)

iD8DBQFAW33PdqzuAf6io/4RAmv8AJ9NxbB2Gl/8VIByBLP0ruqIzZOzNwCfUw8e
enmxXc7sj74OZlAu/eHkTjc=
=pg1u
-----END PGP SIGNATURE-----