Date: Wed, 23 Jun 2010 14:05:34 +0100 From: Anton Shterenlikht <mexas@bristol.ac.uk> To: Marcel Moolenaar <xcllnt@mac.com> Cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= <des@des.no>, freebsd-current@freebsd.org, Anton Shterenlikht <mexas@bristol.ac.uk>, freebsd-ia64@freebsd.org Subject: Re: r209240 ia64 -> buildworld -> undefined reference to `lzma_physmem' Message-ID: <20100623130534.GA69821@mech-cluster241.men.bris.ac.uk> In-Reply-To: <754D875E-48AB-423D-B309-9415EA2867E4@mac.com> References: <20100617101541.GA90363@mech-cluster241.men.bris.ac.uk> <4C1A117A.9060608@dataix.net> <20100618085018.GA94427@mech-cluster241.men.bris.ac.uk> <4C1B63A1.3010604@dataix.net> <8639wgfnrk.fsf@ds4.des.no> <20100621150445.GA50194@mech-cluster241.men.bris.ac.uk> <754D875E-48AB-423D-B309-9415EA2867E4@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 21, 2010 at 01:27:52PM -0700, Marcel Moolenaar wrote: >=20 > On Jun 21, 2010, at 8:04 AM, Anton Shterenlikht wrote: >=20 > > On Mon, Jun 21, 2010 at 04:45:03PM +0200, Dag-Erling Sm=F8rgrav wrote: > >> jhell <jhell@dataix.net> writes: > >>> Anton Shterenlikht <mexas@bristol.ac.uk> writes: > >>>> What do you mean by "updating your headers"? > >>> cd /usr/src/include && make obj && make depend && make all && make in= stall > >>=20 > >> wrong. > >>=20 > >> % cd /usr/src > >> % make obj > >> % make cleandepend > >> % make depend > >> % make buildincludes > >> % make installincludes > >>=20 > >> DES > >> --=20 > >> Dag-Erling Sm=F8rgrav - des@des.no > >=20 > > Sorry, just to take one step back, why has this become > > necessary for this particular box? If /usr/obj is empty, > > and "svn up", followed by "svn diff", doesn't show any > > local changes, why can't I go straight to make buildworld? > > In other words, why do my headers need updating on this > > particular box, and not on other ia64 boxes? > > I must've screwed something up, haven't I? >=20 > Anton, >=20 > My suggestion would be to destroy the sandbox entirely > and simply checkout a new one from scratch, provided > you're not sharing sandboxes across NFS. I would also > manually destroy your object tree under /usr/obj (or > whereever you have it) before doing the buildworld. >=20 > It's not impossible (double negative to emphasize that > the possibility may not be big enough to worry about, > but that I don't want to go there), that you have some > corruption that is not exposed by "svn diff", but that > is causing the build-breakages. A clean slate helps... Marcel, I did just that - removed the whole of /usr/src and started from scratch. I got the same error as before: cc -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date= =2Elo dd.lo df.lo echo.lo ed.lo exp .lo getfacl.lo hostname.lo kenv.lo kill= =2Elo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.l rm= dir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo= badsect.lo camcontrol.lo ccdc nfig.lo clri.lo devfs.lo dmesg.lo dump.lo du= mpfs.lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fs rand.lo gb= de.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunl= oad.lo ldconfig.lo md5. o mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd96= 60.lo mount_msdosfs.lo mount_nfs.lo mount_ntfs.lo mount_n llfs.lo mount_udf= =2Elo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo= restore.lo rcorde .lo route.lo routed.lo rtquery.lo rtsol.lo savecore.lo s= pppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.l atmconfig.lo ping6.lo= ipf.lo zfs.lo zpool.lo mca.lo dhclient.lo head.lo mt.lo sed.lo tail.lo tee= =2Elo gzip.lo bzip2.lo xz.lo tar.lo vi.lo id.lo chroot.lo chown.lo /usr/obj= /usr/src/rescue/rescue/../librescue/exec.o /usr obj/usr/src/rescue/rescue/.= =2E/librescue/getusershell.o /usr/obj/usr/src/rescue/rescue/../librescue/lo= gin_clas .o /usr/obj/usr/src/rescue/rescue/../librescue/popen.o /usr/obj/us= r/src/rescue/rescue/../librescue/rcmdsh.o usr/obj/usr/src/rescue/rescue/..= /librescue/sysctl.o /usr/obj/usr/src/rescue/rescue/../librescue/system.o -l= c ypt -ledit -lkvm -ll -ltermcap -lutil -lalias -lcam -lcurses -ldevstat -l= ipsec -lipx -lzfs -lnvpair -luutil lavl -lgeom -lbsdxml -ljail -lkiconv -l= md -lreadline -lsbuf -lufs -lz -lbz2 -llzma -larchive -lcrypto -lm xz.lo(.text+0x5202): In function `hardware_init': : undefined reference to `lzma_physmem' I think it's possible that at some point, in anger, I did "make installworld" after a failed, or otherwise interrupted "make buildworld". Perhaps I got an inconsistent set of binaries as a result... Would that explain an error like this? PS: I'm now at # svn info Path: . URL: svn://svn.freebsd.org/base/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 209429 Node Kind: directory Schedule: normal Last Changed Author: rwatson Last Changed Rev: 209429 Last Changed Date: 2010-06-22 11:46:57 +0100 (Tue, 22 Jun 2010) many thanks anton --=20 Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100623130534.GA69821>