libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Test for dlloader API


From: Ralf Wildenhues
Subject: Re: Test for dlloader API
Date: Thu, 28 Jan 2010 21:08:54 +0100
User-agent: Mutt/1.5.20 (2009-10-28)

* Peter Rosin wrote on Thu, Jan 28, 2010 at 09:06:10AM CET:
> Den 2010-01-28 07:16 skrev Ralf Wildenhues:
> 
> >There are several more instances that fail when using CC=g++.  The patch
> >below makes it pass in this case for me, please look over it that I
> >haven't made any mistakes.
> 
> Ouch, didn't think of that. The loadlibrary.at test as similar issues.
> I'll fix that up too.

Thanks; a separate patch to fix CC=g++ in loadlibrary.at is preapproved.

> >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.

> 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.

Adding loaders before the preopen loader is probably problematic for
other reasons.

I'm fine with your other nits to my diff.

Thanks,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]