Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: URGENT: Please, backout change (Re: zsh-3.1.4 released)
- X-seq: zsh-workers 4012
- From: Zefram <zefram@xxxxxxxxx>
- To: borsenkow.msk@xxxxxx (Andrej Borsenkow)
- Subject: Re: URGENT: Please, backout change (Re: zsh-3.1.4 released)
- Date: Mon, 1 Jun 1998 12:03:02 +0100 (BST)
- Cc: zsh-workers@xxxxxxxxxxxxxxx
- In-reply-to: <000d01bd8d4a$379e4ee0$21c9ca95@xxxxxxxxxxxxxxx> from "Andrej Borsenkow" at Jun 1, 98 02:44:11 pm
Andrej Borsenkow wrote:
> the code in libzsh gets its own static copy of _environ
> startup code in zsh is linked with it's own static copy of _environ
> which results in every copy of ZSH starting with blank (at the best)
>environment pointer.
Hmmmm.
We need to link modules against $LIBS for other reasons too (it's the
only way to being in the right libraries in some cases), so we can't
really back that out. It seems that this is a problem where static
modifiable library data (such as environ) appears only in statically
linked libraries. My feeling is that this arrangement of libraries
means that shared libraries are hopelessly broken, so we shouldn't try
to cater for these systems (not that we reasonably can).
>Unfortunately, there is no clean way to autoconf it.
We can, but only for specific symbols. All we need is to compile an
executable and library with references to environ, load them both, and
compare the environ pointers. If they differ, then shared libraries
are broken. Do this for all symbols that are a problem on any system.
Until someone writes this autoconf test, just don't use --enable-dynamic
on systems that exhibit this lossage.
-zefram
Messages sorted by:
Reverse Date,
Date,
Thread,
Author