Date: Sat, 20 Mar 2004 00:10:01 +0100 From: Adriaan de Groot <adridg@cs.kun.nl> To: freebsd-amd64@freebsd.org Subject: Re: A different buildworld failure Message-ID: <200403200010.07287.adridg@cs.kun.nl> In-Reply-To: <20040319214512.GA54549@dragon.nuxi.com> References: <200403192053.55584.adridg@cs.kun.nl> <20040319214512.GA54549@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
=2D----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=20
CFLAGS=3D-g -fPIC in make.conf isn't such a bright idea - other than that, =
rm=20
=2D -rf /usr/obj ; make cleanworld buildworld keeps on giving up at this sa=
me=20
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.=20
Anyway, let's not quibble on a friday night. I can see that several of the=
=20
pam modules in contrib/openpam/modules contain pam_sm_chauthtok:
/pam_deny/pam_deny.c:pam_sm_chauthtok(pam_handle_t *pamh, int flags,
=2E/pam_permit/pam_permit.c:pam_sm_chauthtok(pam_handle_t *pamh, int flags,
=2E/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 stati=
c=20
lib:
ld -o openpam_static_modules.o -r --whole-archive=20
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/libpa=
m_group.a ../modules/pam_guest/libpam_guest.a ../modules/pam_krb5/libpam_kr=
b5.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_opieacces=
s/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 ../module=
s/pam_securetty/libpam_securetty.a ../modules/pam_self/libpam_self.a ../mod=
ules/pam_ssh/libpam_ssh.a ../modules/pam_tacplus/libpam_tacplus.a ../module=
s/pam_unix/libpam_unix.a
which of course pulls in those multiple definitions.=20
> 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.
=2D --=20
pub 1024D/FEA2A3FE 2002-06-18 Adriaan de Groot <groot@kde.org>
Would you like a freem?
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQFAW33PdqzuAf6io/4RAmv8AJ9NxbB2Gl/8VIByBLP0ruqIzZOzNwCfUw8e
enmxXc7sj74OZlAu/eHkTjc=3D
=3Dpg1u
=2D----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403200010.07287.adridg>