[haiku-development] Re: cmake dynamicloader should make use of dl*?
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 29 Jan 2009 17:24:25 +0100
On 2009-01-29 at 05:42:32 [+0100], scott mc <scottmc2@xxxxxxxxx> wrote:
> On Wed, Jan 28, 2009 at 3:33 PM, Ingo Weinhold <ingo_weinhold@xxxxxx>
wrote:
> > On 2009-01-28 at 23:30:34 [+0100], scott mc <scottmc2@xxxxxxxxx> wrote:
> >> In working on the cmake port I've run into a failure of the dashboard
> >> test "Plugin":
> >> http://www.cdash.org/CDash/testDetails.php?test=15727830&build=254059
> >
> > The runtime loader apparently says
> >
> > resolve symbol "example_exe_function" returned: -2147478780
> >
> > while relocating the library to load. A look into the example (and the
> > library) should clarify where that symbol is supposed to live and why it
> > isn't found.
> >
> >> I think it traces back to DynamicLoader.cxx:
> >> http://public.kitware.com/cgi-bin/viewcvs.cgi/Source/kwsys/DynamicLoader.cxx?revision=1.22.10.2&root=CMake&view=markup
> >> I've tried removing the __HAIKU__ cases so that it falls through and
> >> uses the default unix functions in section 6, but that didn't seem to
> >> work either.
> >
> > To answer your question in the subject: Yes, in doubt use the dl*() API.
> > The
> > BeOS API (load_add_on() and friends) behaves differently (it's not even
> > possible to correctly emulate the dl*() API with the BeOS API) which
might
> > not work as portable applications could expect.
>
> >From Bill:
>
> I guess this tells us the problem:
>
> http://dev.haiku-os.org/ticket/1948
>
> The flags passed to dlopen() are ignored. That is OK for
> RTLD_LAZY/RTLD_NOW (we always relocate everything when loading), but
> probably not for RTLD_GLOBAL/RTLD_LOCAL.
>
> The RTLD_GLOBAL is key to this test passing. On other systems this
> means that the shared object being loaded can resolve symbols from the
> exe that is loading it.
According to the POSIX specs RTLD_GLOBAL does not have this meaning. It's
the other way around: Symbols in objects dlopen()ed with RTLD_GLOBAL are
available for later symbol resolution.
The specs also say:
"Any object loaded by dlopen() that requires relocations against global
symbols can reference the symbols in the original process image file, any
objects loaded at program start-up, from the object itself as well as any
other object included in the same dlopen() invocation, and any objects that
were loaded in any dlopen() invocation and which specified the RTLD_GLOBAL
flag."
which would suggest that symbols of the program are always used for
relocation. But our test
src/tests/system/runtime_loader/test_suite/dlopen_resolve_basic1 shows that
Linux (at least openSuse 10.3, which I'm using) fails to dlopen() liba.so
since it cannot resolve the symbol "b" which happens to be exported by the
executable. I've also tested this in FreeBSD with the same results. Hence
I've implemented it this way in Haiku, too.
As written before it would be helpful to see the failing CMake test.
CU, Ingo
Other related posts: