Date: Sat, 19 Sep 1998 11:37:01 +1000 (EST) From: John Birrell <jb@cimlogic.com.au> To: jbryant@unix.tfs.net Cc: freebsd-current@FreeBSD.ORG Subject: Re: ELF interpreter /usr/libexec/ld-elf.so.1 not found Message-ID: <199809190137.LAA19381@cimlogic.com.au> In-Reply-To: <199809182232.RAA08087@unix.tfs.net> from Jim Bryant at "Sep 18, 98 05:32:52 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Jim Bryant wrote: > okay, i've decided to catch up to elf... > > after a `make clean`, > > make aout-to-elf-build >& make.out & tail -f make.out > > has bombed twice here: > > ===> games/fortune/datfiles > ELF interpreter /usr/libexec/ld-elf.so.1 not found > ../strfile/strfile -rs /usr/src/games/fortune/datfiles/fortunes fortunes.dat ^^^^^^^^^^^ Version 1.10 of src/games/fortune/datfiles/Makefile should be backed out. It assumes that there is an installed shared loader to run strfile from the build tree. This assumption is invalid in a cross compiled environment which is what the aout-to-elf build (almost) is. The other poor assumption is that /usr/games/strfile is the second-most up-to-date build tool. Our build assumes that most of the build tools (cc, ld, ar, make etc) are in the user's path, so IMHO we shouldn't treat strfile and caesar any differently. In a cross-compiled environment, I don't like the idea of building tools in place to run on the host system when the cross build is generating objects in a (possibly) incompatible executable format. To do this means that we have to have two sets of build rules. I prefer that a `make world' on the host will bring all tools up-to-date, bootstrapping as required. Then, using these up-to-date tools, the cross compile (say alpha on i386) should not try to build and execute any tools from the build tree, just build things in the correct order. I've tried convincing a few people in private email to let me _install_ all build tools, including ones which have historically been built and executed in place. So far, I haven't found anyone who thinks that's a good idea. To get around the problem, I changed all these non-installed build tools to be statically linked to stop the aout-to-elf build from trying to use the shared loader before it is installed. This caused a certain amount of "don't do that" email. It isn't a solution to the cross-compile issue because it assumes that the host and the target are enough alike to be able to execute static target programs on the host. [ This is *frustrating* ] > > note that the line about the elf interpreter does not seem to be in > the make.out file, and appears to be the only such complaint in the > xterm's scrollback buffer [5k lines]. > > 5:24:51pm argus(116): grep "ELF" make.out > (echo "#define ELF_SYNTAX" ; echo "#include \"syntax.h\"") > asm-syntax.h > (echo "#define ELF_SYNTAX" ; echo "#include \"syntax.h\"") > asm-syntax.h > 5:30:03pm argus(117): > > this is using cvsups from both yesterday evening, as well as from > about noon [CDT] today. It is the kernel telling you it can't find the shared loader. PS: As it stands, the aout-to-elf build will fail in perl5 anyway, so there is no point trying at the moment. 8-( -- 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809190137.LAA19381>