Date: Fri, 5 Jun 1998 21:21:39 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: ache@nagual.pp.ru (=?koi8-r?B?4c7E0sXKIP7F0s7P1w==?=) Cc: peter@netplex.com.au, current@FreeBSD.ORG, ports@FreeBSD.ORG Subject: Re: lorder problem: aout vs. elf (and GNU Configure problem too) Message-ID: <199806052121.OAA04575@usr08.primenet.com> In-Reply-To: <19980605123736.A20838@nagual.pp.ru> from "=?koi8-r?B?4c7E0sXKIP7F0s7P1w==?=" at Jun 5, 98 12:37:36 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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 "${<var>}", so the lookup code
can definitively tell the end of the <var>. 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-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806052121.OAA04575>