From owner-freebsd-current Fri Jun 5 14:22:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA18505 for freebsd-current-outgoing; Fri, 5 Jun 1998 14:22:57 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp04.primenet.com (daemon@smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA18382; Fri, 5 Jun 1998 14:22:23 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id OAA07219; Fri, 5 Jun 1998 14:22:04 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpd007047; Fri Jun 5 14:21:50 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id OAA04575; Fri, 5 Jun 1998 14:21:39 -0700 (MST) From: Terry Lambert Message-Id: <199806052121.OAA04575@usr08.primenet.com> Subject: Re: lorder problem: aout vs. elf (and GNU Configure problem too) To: ache@nagual.pp.ru (=?koi8-r?B?4c7E0sXKIP7F0s7P1w==?=) Date: Fri, 5 Jun 1998 21:21:39 +0000 (GMT) Cc: peter@netplex.com.au, current@FreeBSD.ORG, ports@FreeBSD.ORG In-Reply-To: <19980605123736.A20838@nagual.pp.ru> from "=?koi8-r?B?4c7E0sXKIP7F0s7P1w==?=" at Jun 5, 98 12:37:36 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I expect lots of problems with GNU Configure scripts (for ports), they > > never search nm,ar,ranlib in .../aout > > > > We must provide symlinks from > > /usr/bin/xxx -> /usr/libexec/{elf or aout}/xxx > > otherwise lots of ports will be broken. > > /usr/lib/libc.a (now moved to /usr/lib/aout) is also often parsed by GNU > Configure :-( > > It sounds like almost every GNU Configure port should be changed to > reflect new aout subdirectories to preserve previous state. It is wrong > move indeed for elf version. It looks like libraries and /usr/bin symlinks > are only solution. I have not considered (yet) how one should interpret variant symbolic links based not on data in the environment, but on data known to the kernel. This is problematic. My gut feeling would be to put variant symbolic links in, and use a dollarsign ("$") to designate a kernel variant keyword: ln -s "/usr/lib.\${\$imgact}" /usr/lib The a.out images would get /usr/lib.aout, the ELF would get /usr/lib.elf. The gzip and shell would set it apropriately for the interpreter. Pretty obviously, the semantics are "${}", so the lookup code can definitively tell the end of the . Since "$" is not allowed in an environment variable, we can steal it as a name-space escape. To escape the "${" escape, "${$$" could be used. So: ln -s "/usr/lib.\${\$\$imgact}" /usr/lib ls -l /usr/lib ... /usr/lib -> /usr/lib.${$$imgact} which would actually reference the file /usr/lib.${imgact}, instead of expanding the imgact variable. This would typically never be needed, since re-quotation in a shell script would tend to blow away the value anyway. --- Unfortunately, variant symbolic links would still not be useful based on environment variables, since FreeBSD programs don't force the environment variables to use some rational standard referential model (like "logical names" -- basically, the env is hung off the proc structure instead of stuffed into kernel-inaccessible data space). The main "bugaboo" here is the use of the "envp" in the execve(2) system call. The way I would deal with this is to note that POSIX does not mandate its functions be system calls rather than library routines. But this would lose binary backward compatability. 8-(. Far be it for me to stand in the way of the code being backward. Compatible. This means that you would need an envp-to-logical name translator in the kernel; it would need to know "atom=value" rules, at a minimum. This is a tiny amount of code, but would displease some people. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message