Can be a module linked to library to which Zsh isn't linked?

Can be a module linked to library to which Zsh isn't linked?

[Sebastian Gniazdowski]

Hello,
on Ubuntu terminfo is separate from ncurses. As it is preferred over
ncurses (but not ncursesw) it is selected as the terminal handling
library. This results in "initscr" function not being found in $LIBS
and in not building of the zsh/curses module. As it can be seen, there
are one LIBS for Zsh and for modules.

Interesting is that when making ncurses preferred by
--with-term-lib=ncurses, the line executes:

gcc  -s -rdynamic -o zsh main.o  `cat stamp-modobjs`   -ldl -lncurses
-lrt -lm  -lc

but the result file is linked to:
    linux-gate.so.1 =>  (0xb77a6000)
    libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7787000)
    libtinfo.so.5 => /lib/i386-linux-gnu/libtinfo.so.5 (0xb7768000)
    libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb773b000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7590000)
    /lib/ld-linux.so.2 (0xb77a7000)

and curses.so to:
    linux-gate.so.1 =>  (0xb7737000)
    libncurses.so.5 => /lib/i386-linux-gnu/libncurses.so.5 (0xb76f3000)
    libtinfo.so.5 => /lib/i386-linux-gnu/libtinfo.so.5 (0xb76d4000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7528000)
    libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7523000)
    /lib/ld-linux.so.2 (0xb7738000)

Curses is linked to a library that zsh isn't and this is working fine
– zsh starts, module loads. Could it be that "one LIBS" isn't in fact
required? Modules gdbm and pcre aren't built by default and they make
zsh binary linked to libgdbm, libpcre. I thought that's why they
aren't build by default – because they add dependencies to zsh binary
– but maybe it's result of not flexible enough configure?

Best regards,
Sebastian Gniazdowski

Re: Can be a module linked to library to which Zsh isn't linked?

[Bart Schaefer]

On Oct 3,  4:24pm, Sebastian Gniazdowski wrote:
} Subject: Can be a module linked to library to which Zsh isn't linked?
}
} Curses is linked to a library that zsh isn't and this is working fine
} - zsh starts, module loads. Could it be that "one LIBS" isn't in fact
} required?

I think this is dependent on compiler/linker/loader version and flags,
e.g., it might work with dynamic linkage but not static (symbol name
clashes), or might work with newer linkers but not older ones.

} Modules gdbm and pcre aren't built by default and they make
} zsh binary linked to libgdbm, libpcre. I thought that's why they
} aren't build by default - because they add dependencies to zsh binary

It's because they add *licensing* dependencies, IIRC, not because they
add shared-object dependencies.

Re: Can be a module linked to library to which Zsh isn't linked?

[Sebastian Gniazdowski]

On 3 October 2015 at 20:55, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Oct 3,  4:24pm, Sebastian Gniazdowski wrote:
> } Modules gdbm and pcre aren't built by default and they make
> } zsh binary linked to libgdbm, libpcre. I thought that's why they
> } aren't build by default - because they add dependencies to zsh binary
>
> It's because they add *licensing* dependencies, IIRC, not because they
> add shared-object dependencies.

The shared-object dependencies can also be a problem. Uninstalling
libpcre could yield zsh unworking. Having modified LIBS for pcre, gdbm
modules would solve this. Packagers would build such modules instead
of leaving them inactive. However for those two the licensing aspect
overlaps as you wrote, so it's a lost battle for them anyway (BTW
libpcre is BSD, isn't it compatible with Zsh?).

What bothers me is that someone who builds zsh against termcap or
terminfo loses curses module. Having a bit of separate tests in
configure against libraries needed by modules but not zsh itself would
solve this. Is Zsh open for such change?

Best regards,
Sebastian Gniazdowski

Re: Can be a module linked to library to which Zsh isn't linked?

[Bart Schaefer]

On Oct 4,  6:49pm, Sebastian Gniazdowski wrote:
}
} What bothers me is that someone who builds zsh against termcap or
} terminfo loses curses module. Having a bit of separate tests in
} configure against libraries needed by modules but not zsh itself would
} solve this. Is Zsh open for such change?

Certainly, we'll take improvements to the configure script.  I've also
noticed that it checks more than once for some dependencies; there's
probably a lot that could be done.

Re: Can be a module linked to library to which Zsh isn't linked?

[Mikael Magnusson]

On Sun, Oct 4, 2015 at 10:53 PM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
> On Oct 4,  6:49pm, Sebastian Gniazdowski wrote:
> }
> } What bothers me is that someone who builds zsh against termcap or
> } terminfo loses curses module. Having a bit of separate tests in
> } configure against libraries needed by modules but not zsh itself would
> } solve this. Is Zsh open for such change?
>
> Certainly, we'll take improvements to the configure script.  I've also
> noticed that it checks more than once for some dependencies; there's
> probably a lot that could be done.

I've been using this patch for ages,
http://cgit.mika.l3ib.org/cgit/zsh-cvs/commit/?h=mika&id=c6a582b4c4f84677cb096a8d2223707545779d58
as the commit says, it's a hack though. I remember someone mentioning
when I brought it up last time that there could be systems where the
main binary has to link the libraries, but as far as I know that only
applies if the main binary actually uses symbols from those libraries
directly. I only know about linux libcs though, so maybe I'm wrong. It
would be nice to have the option for it though.

-- 
Mikael Magnusson

Re: Can be a module linked to library to which Zsh isn't linked?

[Peter Stephenson]

On Sun, 4 Oct 2015 13:53:43 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Oct 4,  6:49pm, Sebastian Gniazdowski wrote:
> } What bothers me is that someone who builds zsh against termcap or
> } terminfo loses curses module. Having a bit of separate tests in
> } configure against libraries needed by modules but not zsh itself would
> } solve this. Is Zsh open for such change?
> 
> Certainly, we'll take improvements to the configure script.  I've also
> noticed that it checks more than once for some dependencies; there's
> probably a lot that could be done.

We've been pretty conservative with terminal libraries because getting
it all going on some earlier systems was decidely icky, with lots of
order dependencies.  That's gradually disappearing into history, but
you don't find out how fast until someone complains.  I think this
would be worth doing now, though.

pws