URGENT: Please, backout change (Re: zsh-3.1.4 released)

URGENT: Please, backout change (Re: zsh-3.1.4 released)

[Andrej Borsenkow]

Because I am responsible for this change, I request to backout it:

Mon May 25 21:13:41 1998  Andrew Main  <zefram@zsh.org>

 * Src/mkmakemod.sh, configure.in, aczsh.m4: Link modules against
   $(LIBS), and include -lc in $(LIBS), in case a module requires
   a function that only exists in static libraries.


It breaks environment in ZSH. It happens as following:

as said, our systems have two libc - dynamic libc.so.1 and static libc.so
(yes, it *is* ar lib, but called so :) Unfortunately, _environ is located in
static libc. If I try to link shared libray, which is using _environ, with
libc, the following happens:

  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.

This problem is not specific to ZSH - every now and then it comes up e.g.
with Perl, or any software, which is using shared libs.

Unfortunately, there is no clean way to autoconf it. Dynamic loading runs on
MIPS line (Reliant UNIX) without this change; it is possible to make it
running on Intel line (SINIX-L/SINIX-M) but with many eforts (actually, only
one module has to be linked with -lc) ... I personally would simply disallow
dynamic loading on i386-sni-sysv4 - or at least to put it in NEWS or FAQ.

Thank you

A. Borsenkow

Re: URGENT: Please, backout change (Re: zsh-3.1.4 released)

[Zefram]

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