loading of module's dependencies broken with '-z now' in LDFLAGS

loading of module's dependencies broken with '-z now' in LDFLAGS

[Kamil Dudka]

Hello,

the build system of Fedora recently started to call linker with '-z now'. 
The ld(1) man page regarding this option says:

    "When generating an executable or shared library, mark it to tell the
    dynamic linker to resolve all symbols when the program is started, or
    when the shared library is linked to using dlopen, instead of deferring
    function call resolution to the point when the function is first called."

This breaks loading of zsh modules that depend on other zsh modules.
For instance, the following command fails:

$ zsh -c 'zmodload zsh/zftp' 
zsh:1: failed to load module `zsh/zftp': /usr/lib64/zsh/5.1.1/zsh/zftp.so: 
undefined symbol: freehostent

... whereas the following command succeeds:

$ zsh -c 'zmodload zsh/net/tcp && zmodload zsh/zftp' 

Do I understand it correctly that the only solution is to tweak the build 
system not to use '-z now' while linking zsh modules?

The issue was originally reported here: https://bugzilla.redhat.com/1277996

Kamil

Re: loading of module's dependencies broken with '-z now' in LDFLAGS

[Peter Stephenson]

On Thu, 5 Nov 2015 11:59:42 +0100
Kamil Dudka <kdudka@redhat.com> wrote:
> the build system of Fedora recently started to call linker with '-z now'. 
> The ld(1) man page regarding this option says:
> 
>     "When generating an executable or shared library, mark it to tell the
>     dynamic linker to resolve all symbols when the program is started, or
>     when the shared library is linked to using dlopen, instead of deferring
>     function call resolution to the point when the function is first called."
> 
> This breaks loading of zsh modules that depend on other zsh modules.
> For instance, the following command fails:
> 
> $ zsh -c 'zmodload zsh/zftp' 
> zsh:1: failed to load module `zsh/zftp': /usr/lib64/zsh/5.1.1/zsh/zftp.so: 
> undefined symbol: freehostent

[from zsh/net/tcp].

There is certainly nothing in the current zsh build system as set up for
Linux that does this; however, there is some evidence that it got partly
thought about.  To pursue this example (I think it generalises), the
Src/Modules/zftp.mdd file that defines

moddeps="zsh/net/tcp"

to say that zftp depends on zsh/net/tcp.  In Src/Modules/Makefile, this
results in (together with the implicit dependency on the main shell):

LINKMODS_zftp =  tcp.$(DL_EXT)  $(dir_top)/Src/libzsh-$(VERSION).$(DL_EXT) 

So far so good --- however, LINKDMODS_zftp isn't actually mentioned
again.  A bit of research says that's because configuration says
we should use the alternative (empty) NOLINKMODS_zftp; the LINKMODS
version is only defined to be used for a few OSes in configure.ac.

I guess we need to generate something like LINKMODS_whatever that
tells it to link against the .so's as libraries?  If someone can say
definitively, it might not be too hard to implement.

> ... whereas the following command succeeds:
> 
> $ zsh -c 'zmodload zsh/net/tcp && zmodload zsh/zftp' 
> 
> Do I understand it correctly that the only solution is to tweak the build 
> system not to use '-z now' while linking zsh modules?

For now, that's probably the case.

pws

Re: loading of module's dependencies broken with '-z now' in LDFLAGS

[Peter Stephenson]

On Thu, 5 Nov 2015 11:58:29 +0000
Peter Stephenson <p.stephenson@samsung.com> wrote:
> I guess we need to generate something like LINKMODS_whatever that
> tells it to link against the .so's as libraries?

Hmm... actually, maybe it's not that simple.

The usually implication with a DLL is that it'll be found automatically
by the OS, but that's not what zsh is doing, which is:

- get instruction to load zsh/zftp
- Open this with dlopen().  Note we have RTLD_LAZY defined to
  support the following.
- Run setup_().
- This executes
    return (require_module("zsh/net/tcp", NULL) == 1);
- This causes us to load tcp.so.
- When we enounter any missing link from tcp.so, it gets resolved.

I don't know enough about DLLs to say whether resolving the links when
zftp.so is created means that dlopen() now expects to be able to load
tcp.so itself, in which case it's going to be problematic.

I'd suspect the "-z now" business isn't really designed for use with
the dlopen RTLD_LAZY flag?

pws

Re: loading of module's dependencies broken with '-z now' in LDFLAGS

[Kamil Dudka]

On Thursday 05 November 2015 12:17:44 Peter Stephenson wrote:
> On Thu, 5 Nov 2015 11:58:29 +0000
> 
> Peter Stephenson <p.stephenson@samsung.com> wrote:
> > I guess we need to generate something like LINKMODS_whatever that
> > tells it to link against the .so's as libraries?
> 
> Hmm... actually, maybe it's not that simple.
> 
> The usually implication with a DLL is that it'll be found automatically
> by the OS, but that's not what zsh is doing, which is:
> 
> - get instruction to load zsh/zftp
> - Open this with dlopen().  Note we have RTLD_LAZY defined to
>   support the following.
> - Run setup_().
> - This executes
>     return (require_module("zsh/net/tcp", NULL) == 1);
> - This causes us to load tcp.so.
> - When we enounter any missing link from tcp.so, it gets resolved.
> 
> I don't know enough about DLLs to say whether resolving the links when
> zftp.so is created means that dlopen() now expects to be able to load
> tcp.so itself, in which case it's going to be problematic.
> 
> I'd suspect the "-z now" business isn't really designed for use with
> the dlopen RTLD_LAZY flag?
> 
> pws

That was my original impression too.  Thanks for the detailed analysis!
I will just tweak our build system not to use the '-z now' linker flag
for zsh modules.

Kamil

Re: loading of module's dependencies broken with '-z now' in LDFLAGS

[Peter Stephenson]

On Thu, 5 Nov 2015 13:39:20 +0100
Kamil Dudka <kdudka@redhat.com> wrote:
> That was my original impression too.  Thanks for the detailed analysis!
> I will just tweak our build system not to use the '-z now' linker flag
> for zsh modules.

In the short term, that's the best bet.  (I now realise I got confused
and resolution at dlopen() is indeed the point, as it said in the manual
you quoted; resolution within the build system is irrelevant.)

I've just done a little more research while waiting for some machines to
spring back to life and if we *did* want to improve things with "-z
now", I think the answer is that in a GNU environment we can give the
module setup_() function the "constructor" attribute (and finish_ the
"desctructor" attribute).  Then the load of dependent modules happens
before dlopen()s final checks (I think --- I haven't tested this).  Then
we don't call setup_() and finish_() by hand.

I don't think that gains us all that much, however, and while it looks
easy to implement probing the configuration to see if it supports it is
a bit hairier.  So I'm not sure it's worth the effort.

pws