[krbdev.mit.edu #3176]

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[krbdev.mit.edu #3176]

Greg Hudson via RT


Note that the patch to shlib.conf breaks our ABI on AIX.  This may be
acceptable or even desirable but it should be considered.


_______________________________________________
krb5-bugs mailing list
[hidden email]
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
Reply | Threaded
Open this post in threaded view
|

Re: [krbdev.mit.edu #3176]

Greg Hudson via RT
>>>>> "Marc" == Marc Aurele La France <[hidden email]> writes:

    Marc> On Tue, 13 Sep 2005, Sam Hartman via RT wrote:
    >> Note that the patch to shlib.conf breaks our ABI on AIX.

    Marc> How so?  How can wrapping, or not, a shared object into an
    Marc> archive affect a programming interface?  And why is this
    Marc> wrapping preferable to producing dlopen'able objects?

Because it changes the name that appears in the liblist section of the
xcoff object.

    Marc> Quite frankly, I find it odd that this wrapping is only
    Marc> being done for AIX, and only by mit-krb5.  Even GNU doesn't
    Marc> do this.  Is this a remnant of the historical
    Marc> misundertanding of how AIX shared objects are supposed to
    Marc> work?

No.  It's because I actually understood conventions used for the C
libraries on AIX 3.1, 3.2 and 4.  AIX 4.3 did add optional conventions
for non-wrapped objects, although it was not clear the linker did a
good job of finding them when first introduced.


_______________________________________________
krb5-bugs mailing list
[hidden email]
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
Reply | Threaded
Open this post in threaded view
|

Re: [krbdev.mit.edu #3176]

Greg Hudson via RT
In reply to this post by Greg Hudson via RT
On Tue, 13 Sep 2005, Sam Hartman via RT wrote:
>>>>>> "Marc" == Marc Aurele La France <[hidden email]> writes:
>    Marc> On Tue, 13 Sep 2005, Sam Hartman via RT wrote:
>    >> Note that the patch to shlib.conf breaks our ABI on AIX.

>    Marc> How so?  How can wrapping, or not, a shared object into an
>    Marc> archive affect a programming interface?  And why is this
>    Marc> wrapping preferable to producing dlopen'able objects?

> Because it changes the name that appears in the liblist section of the
> xcoff object.

... of the _referencing_ xcoff objects, yes.  That's a good point WRT
compatibility with previous releases of mit-krb5 and/or AIX.  But, at least
on AIX 5.3, the run-time loader doesn't seem to care whether a referenced .a
contains shared or static objects.  So old binaries should be OK.

You must admit, though, that the current scheme, before my patch, prevents
shared/static co-existence, which is not a Good Thing (tm).

>    Marc> Quite frankly, I find it odd that this wrapping is only
>    Marc> being done for AIX, and only by mit-krb5.  Even GNU doesn't
>    Marc> do this.  Is this a remnant of the historical
>    Marc> misundertanding of how AIX shared objects are supposed to
>    Marc> work?

> No.  It's because I actually understood conventions used for the C
> libraries on AIX 3.1, 3.2 and 4.  AIX 4.3 did add optional conventions
> for non-wrapped objects, although it was not clear the linker did a
> good job of finding them when first introduced.

Well, I still have an AIX 3.2.5 system around.  So I can offer to try this
out there and get back to you.

Marc.

+----------------------------------+-----------------------------------+
|  Marc Aurele La France           |  work:   1-780-492-9310           |
|  Academic Information and        |  fax:    1-780-492-1729           |
|    Communications Technologies   |  email:  [hidden email]          |
|  352 General Services Building   +-----------------------------------+
|  University of Alberta           |                                   |
|  Edmonton, Alberta               |     Standard disclaimers apply    |
|  T6G 2H1                         |                                   |
|  CANADA                          |                                   |
+----------------------------------+-----------------------------------+
XFree86 developer and VP.  ATI driver and X server internals.

_______________________________________________
krb5-bugs mailing list
[hidden email]
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
Reply | Threaded
Open this post in threaded view
|

Re: [krbdev.mit.edu #3176]

Greg Hudson via RT
In reply to this post by Greg Hudson via RT
>>>>> "Marc" == Marc Aurele La France <[hidden email]> writes:

    Marc> You must admit, though, that the current scheme, before my
    Marc> patch, prevents shared/static co-existence, which is not a
    Marc> Good Thing (tm).

Not really.  There is an AIX linker flag to treat shared objects (or
particular shared objects) as static.

The OS for example tends not to distribute static libs for anything.


_______________________________________________
krb5-bugs mailing list
[hidden email]
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
Reply | Threaded
Open this post in threaded view
|

Re: [krbdev.mit.edu #3176]

Greg Hudson via RT
In reply to this post by Greg Hudson via RT
On Tue, 13 Sep 2005, Marc Aurele La France wrote:
> On Tue, 13 Sep 2005, Sam Hartman via RT wrote:
>>>>>>> "Marc" == Marc Aurele La France <[hidden email]> writes:
>>    Marc> On Tue, 13 Sep 2005, Sam Hartman via RT wrote:
>>    >> Note that the patch to shlib.conf breaks our ABI on AIX.

>>    Marc> How so?  How can wrapping, or not, a shared object into an
>>    Marc> archive affect a programming interface?  And why is this
>>    Marc> wrapping preferable to producing dlopen'able objects?

>> Because it changes the name that appears in the liblist section of the
>> xcoff object.

> ... of the _referencing_ xcoff objects, yes.  That's a good point WRT
> compatibility with previous releases of mit-krb5 and/or AIX.  But, at least
> on AIX 5.3, the run-time loader doesn't seem to care whether a referenced .a
> contains shared or static objects.  So old binaries should be OK.

This assertion of mine turns out to be completely out-to-lunch.

Anyway, after spending more time on this, I'd like to propose the following.

--enable-shared builds a dlopen'able lib.so as I have it;  --disable-shared
doesn't build a lib.so at all.  --enable-static builds a lib.a as an archive
of static objects;  --disable-static builds a lib.a as a wrapped shared
object as you have it.  This for all AIXen.

One issue I already have with this is that more intrusive changes than I
would like are needed for the --enable-shared --disable-static case.  Also,
this might limit, or least affect, your options in dealing with the
--enable-static issue in src/lib/kdb/kdb5.c.

But, on the whole, this strikes me as a viable compromise.

Marc.

+----------------------------------+-----------------------------------+
|  Marc Aurele La France           |  work:   1-780-492-9310           |
|  Academic Information and        |  fax:    1-780-492-1729           |
|    Communications Technologies   |  email:  [hidden email]          |
|  352 General Services Building   +-----------------------------------+
|  University of Alberta           |                                   |
|  Edmonton, Alberta               |     Standard disclaimers apply    |
|  T6G 2H1                         |                                   |
|  CANADA                          |                                   |
+----------------------------------+-----------------------------------+
XFree86 developer and VP.  ATI driver and X server internals.

_______________________________________________
krb5-bugs mailing list
[hidden email]
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
Reply | Threaded
Open this post in threaded view
|

Re: [krbdev.mit.edu #3176]

Greg Hudson via RT
In reply to this post by Greg Hudson via RT
Currently, the patch only uses the new shared library build process
for AIX 5.3.  Is it also applicable to earlier AIX 5.x?  I suspect it
is, but confirmation would be appreciated.

---Tom

_______________________________________________
krb5-bugs mailing list
[hidden email]
https://mailman.mit.edu/mailman/listinfo/krb5-bugs