Jeff,
Thanks for the comments. My own attempts to understand the gcc and ld
'man' files had led me to the sorts of points you were making, and
my attempts to understand $popsrc/extern_symbols.p had led me to
the conclusion that everything there was probably as it should be
including this, as far as I could tell
#_ELSEIF DEF OSF1 or DEF LINUX_ELF
lconstant macro DLOPEN_FLAGS = 16:001; ;;; RTLD_LAZY
> >1. Compile file foo.c to produce shareable foo.so
> >
> > gcc -o foo.so -fpic -shared foo.c
> >
> >2. Compile file baz.c to produce shareable baz.so
> >
> > gcc -o baz.so -fpic -shared baz.c
> >
>
> Shouldn't there be a "-ldl" in there, if both are calling symbols from
> shared libraries?
I've tried and it doesn't help. Moreover, the above works on a sun.
> In your example that works, you have resolved the two libraries into one
> shared one, hence the symbol references are all correct.
>
> In your example that fails, you haven't told the compiler that each
> library needs to be dynamically loadable, and I suspect that the
> run-time linking performed by the LD library is not in place, (e.g.
> dlopen(), dlclose(), dlsym(), etc.).
Yet it works on a Sun.
> Have you tried using the Gnu compiler and linker on Solaris to verify
> that this fails?
It works with gcc on the sun.
> You may be able to compare the Link Command Language
> output from the two systems (Solaris native vs Gnu) to identify
> appropriate differences.
> In the "Linux No Motif" version (labelled 15.53, but given the number of
> changes to 15.53 over the last couple of years, the version is now
> meaningless), there is a specific block for Linux/ELF to set the default
> dlopen() flags (to RTLD_LAZY). Provided the DLOPEN_FLAGS is defined, the
> remaining mechanisms should work. SunOS/Solaris uses
> RTLD_LAZY|RTLD_GLOBAL. This may lead to a behaviour difference.
I wondered about that. Maybe I should try changing the linux poplog
source and recompilng. I'll have to search the .h files for a value for
RTLD_GLOBAL
> This reinforces the suggestion that foo should be calling baz() via
> dlopen("baz.so") and dlsym().
I thought that was happening.
> Then I suspect you need to use the dynamic loading mechanisms.
>
> Without changing any code, you could try specifying the linker option -E
> (or --export-dynamic) to produce a dynamic symbol table from the
> original compile and link. This may match Solaris behaviour.
I've just tried it, and it did not help. (I used two stages,
gcc -c to produce the .o files, followed by ld, using -E to produce the
.so.
The files are externally loaded OK, and pop11 can can call the required
procedure baz, defined in baz.so directly, but attempting to call it
via foo, defined in foo.so produces, as before
pop11: relocation error: ./foo.so: undefined symbol: baz
> Again, without any code changes, have you tried preloading the second
> library by specifying it in $LD_PRELOAD?
Wow!
That makes it work on lnux.
But I don't see why that should be necessary on linux, but not on a Sun
I'll investigate further when I have time.
Thanks
Aaron
|