Date: Tue, 22 Sep 1998 10:58:52 +1000 (EST) From: John Birrell <jb@cimlogic.com.au> To: garbanzo@hooked.net (Alex) Cc: jb@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/gnu/usr.bin/perl/libperl config.SH-aout.i386 config.SH-elf.alpha config.SH-elf.i386 Message-ID: <199809220058.KAA29177@cimlogic.com.au> In-Reply-To: <Pine.BSF.4.00.9809211741090.254-100000@zippy.dyn.ml.org> from Alex at "Sep 21, 98 05:44:22 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Alex wrote: > Oh it did. In fact the games still do crap like this. Best way to find > this is to take an a.out system (i.e. w/ a.out binaries) with ELF rtld & > libs (it can build both ELF and a.out binaries) and run buildworld. caeser > and strfile are built, but the old (a.out binaries) ones are run. This > results in a.out binaries trying to use ELF shared libs from the chroot'd > enviroment. 1. That's not the "supported" upgrade procedure, so you're on your own. 2. buildworld is not a chrooted environment. 3. The upgrade procedure uses a TOOLPATH which doesn't execute anything from WORLDTMP during the initial elf build. It has LD_LIBRARY_PATH pointing to the TOOLPATH (the aout obj tree), whereas LIBRARY_PATH points into WORLDTMP (the elf obj tree). This means that aout tools are executed during the initial elf build, creating things in elf format. > All in all, not fun, but not a huge deal either, as it's pretty much > assumed you're using binaries that are compatable with the ones you're > building. Please don't encourage people to go outside the procedure. I hope people will ignore what you've said. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809220058.KAA29177>