Re: dev-14: ld.so: Src/zsh: relocation error: symbol not found: nbrbeg

Re: dev-14: ld.so: Src/zsh: relocation error: symbol not found: nbrbeg

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> .zshrc:9: failed to load module: zsh/complete
> 
> I tried this with two different OS/compiler versions.
> 
> The message in subject is from dlerror() that I added to try_load_module()

System type? Didn't we have this kind of problem (a dynamically loaded 
module could not get at the symbols of another dynamically loaded
module) on SunOS4.x?

At least, the code should be ok: nbrbeg and nbrend are defined and
mod_export'ed in zle_tricky.c and zsh/complete depends upon zsh/zle.

Have you tried it with a linked in zsh/zle module?

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

RE: dev-14: ld.so: Src/zsh: relocation error: symbol not found: nbrbeg

[Andrej Borsenkow]

>
> > .zshrc:9: failed to load module: zsh/complete
> >
> > I tried this with two different OS/compiler versions.
> >
> > The message in subject is from dlerror() that I added to try_load_module()
>
> System type? Didn't we have this kind of problem (a dynamically loaded
> module could not get at the symbols of another dynamically loaded
> module) on SunOS4.x?
>
> At least, the code should be ok: nbrbeg and nbrend are defined and
> mod_export'ed in zle_tricky.c and zsh/complete depends upon zsh/zle.
>
> Have you tried it with a linked in zsh/zle module?
>

Well, static (--disable-dynamic) build is O.K. I am really lost here. I also
tried to track down  nbrbeg - they appear to be the same in pws-12 and dev-14
(that is, undef in complete.so and complist.so ad defined in zle.so). I tried
testcase - it works. No idea so far.

/andrej

Found RE: dev-14: ld.so: Src/zsh: relocation error: symbol not found: nbrbeg

[Andrej Borsenkow]

>
> > .zshrc:9: failed to load module: zsh/complete
> >
> > I tried this with two different OS/compiler versions.
> >
> > The message in subject is from dlerror() that I added to try_load_module()
>
> System type? Didn't we have this kind of problem (a dynamically loaded
> module could not get at the symbols of another dynamically loaded
> module) on SunOS4.x?
>


This is due to 9200 + somewhat unusual behaviour of our compiler. 9200 makes
module.c prefer dl.h to dlfcn.h. We do not have /use/include/dl.h but we do have
/usr/include/sys/dl.h (that has nothing to do with dynamic loading at all). Our
compiler does search in both /usr/include and /use/include/sys by default -
hence, AC_CHECK_HEADER finds /usr/include/sys/dl.h. This makes RTLD_*
(RTLD_GLOBAL is important here) be missed. Hence, no symbol from other modules
is ever exported.

In any case, I do not understand the logic here. If dlfcn.h is missing on hpux
11.0, the branch should go under #ifdef HAVE_DL_H and not under #ifdef
HAVE_DLFCN_H.

Could anybody finally suggest reasonable order of include checking here? I
totally fail to understand how patch in 9200 fixed the problem in text.

/andrej