libtool-patches
[Top][All Lists]
Advanced

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

Re: 329-gary-allow-RTLD_GLOBAL


From: Gary V. Vaughan
Subject: Re: 329-gary-allow-RTLD_GLOBAL
Date: Sun, 8 Apr 2007 11:53:01 +0100

Hallo Ralf, Bob,

On 8 Apr 2007, at 01:56, Bob Friesenhahn wrote:
On Sun, 8 Apr 2007, Ralf Wildenhues wrote:
First, many many thanks for attacking this.

No problem.  I plan to spend a day or so each week tackling all of the
showstoppers so we can put out a final alpha release.

Incidentally, I'm don't know whether it would be wiser to go from 2.1a
to 2.2 when we do release to keep in line with our own version numbering
scheme, or whether it will be okay to release 1.9h from HEAD and reset
the number to 1.9i in CVS in readiness for a 2.0 release.  Thoughts?

Second, please allow me a
couple of days for review, I'll try to get to it soon.

Sure.  I won't have any more time to spend on libtool until Wednesday
at least.

Next, please be
aware that as important as documentation would be test exposure for the
functionality.

I have no idea how to write a reliable test for this.  I can certainly
test that the API is available, but since the best semantics I can
provide are "instead of the default symbol visibility request that the
underlying dlloader use global or local symbols at load time, iff that
is supported by the host OS and the underlying dlloader implementation".

Maybe I should test for the system default, and add a test that tries
to change it and succeeds only if lt_dlissym{global,local} fail, or
the default symbol visibility is successfully overridden.  That's
probably more work than the patch itself though!

Ideas?

Actually, test exposure would help facilitate review a
lot.  Also, Bob raised the question some time ago whether it would be
good to have opaque objects similar to what pthread uses, instead of an int (flags), in case we ever need more information than fits in there.
I'm undecided about it, merely pointing it out and asking for your
opinion on this.

It would certainly be interesting to see how many systems fail the test and in which way they fail.

If a flag composed via boolean OR is used, I prefer that it be an unsigned type rather than an signed type like 'int'.

ACK.  I've changed it in my local copy already.

Is there an easy way of composing a opaque object to pass to the api that
doesn't add unnecessary complication.  I don't really like this (stupid
symbol names aside):

   lt_dlopaque opaque = lt_dlopaque_new();

   lt_dlset_symglobal (opaque);

   handle = lt_dlopenopaque ("libmod.la", opaque);

Compared to:

   handle = lt_dlopenflags ("libmod.la", LT_DLSYMGLOBAL);

Although I'm open to persuasion. Or did you have something else in mind?


Cheers,
        Gary
--
  ())_.              Email me: address@hidden
  ( '/           Read my blog: http://blog.azazil.net
  / )=         ...and my book: http://sources.redhat.com/autobook
`(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912




Attachment: PGP.sig
Description: This is a digitally signed message part


reply via email to

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