Re: Test for dlloader API

[Peter Rosin]

Den 2010-01-28 21:08 skrev Ralf Wildenhues:
> * Peter Rosin wrote on Thu, Jan 28, 2010 at 09:06:10AM CET:
> > > The test fails for me when Libtool is configured with --disable-shared.
> > > I'm not sure that failure is specific to this test, whether we need to
> > > fix it before committing the test or so; looking at this is probably
> > > prudent.
>
> > Not sure how to proceed... When I added -dlopen module.la to the link
> > of the main program and a LTDL_SET_PRELOADED_SYMBOLS invocation it
> > *almost* works.
>
> These changes should be made in the test.

Ok, done.

> > But the test still fails since it isn't possible to add
> > a custom loader before the preopen loader. I get this diff in the
> > expected output when running the program:
> >
> > @@ -6,7 +6,6 @@
> >  first_sym (first): first_ctx
> >  result: first_symbol
> >  first_close (first): first_ctx
> > -first_open denies a request
> >  result: module_symbol
> >  first_open denies a request
> >  last_open ("last"): last_ctx
> >
> > I.e. the "first" loader doesn't see any request regarding opening
> > of module.la. Come to think of it, it only sees the request to open
> > the actual shared library when the preopen loader isn't involved,
> > and since that step don't happen with preopened modules the
> > behaviour is not that surprising...
> >
> > The test clearly expects too much from the current implementation, but I
> > kinda think you should be able to override the preopen loader as well.
> >
> > So, how to weaken^Wfix the test?
> >
> > What about just tossing the "real" module and settle for checking that
> > a prepended loader is in front of an appended loader?
>
> Well, if the idea of allowing a user-provided shared module loader was
> that it should be possible to extend libltdl like this on systems for
> which libltdl doesn't natively provide shared module opening facilities,
> and that doesn't work, then that's a failure, no?  OTOH, the user
> shouldn't use --disable-shared on those other systems, so our emulation
> is not perfect with this case; I'm thinking we should thus either let
> the test fail or skip in this case.

I don't know why the user-provided shared module loader API was added,
but I do know that the only user of the mechanism that I found in a
cursory search on the Internet (pulseaudio) uses it to wrap an existing
loader in order to do some extra book-keeping. That will not work in
the static case as it isn't possible to get in before the preopen
loader.

Anyway, I added a skip if there is no shared module built.

> Adding loaders before the preopen loader is probably problematic for
> other reasons.
>
> I'm fine with your other nits to my diff.

I'm unsure if that means that I should push it, so I'm attaching
what I have. Just say the magic word and I'll push :-)

Tested on debian and wine/mingw32/debian both with and without
CC=g++ and both with and without --disable-shared.

Cheers,
Peter

2010-01-29  Peter Rosin  <address@hidden>
            Ralf Wildenhues  <address@hidden>

        Testsuite exposure for dlloader API.
        * tests/dlloader-api.at: New file, new test.
        * Makefile.am (TESTSUITE_AT): Update.

test-dlloader-api-2.patch
Description: Text document