This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: What does LAV_CURRENT mean backwards compatibility of LD_AUDIT interface?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>, Ben Woodard <woodard at redhat dot com>
- Date: Thu, 19 Mar 2015 23:07:54 -0400
- Subject: Re: What does LAV_CURRENT mean backwards compatibility of LD_AUDIT interface?
- Authentication-results: sourceware.org; auth=none
- References: <54EFBC96 dot 7010608 at redhat dot com> <5507BE70 dot 4090800 at redhat dot com> <20150318215629 dot 2BA1D2C3B30 at topped-with-meat dot com> <550A1A30 dot 2020500 at redhat dot com> <20150319192738 dot D24212C3B11 at topped-with-meat dot com>
On 03/19/2015 03:27 PM, Roland McGrath wrote:
>> Does anyone know anyone else at Oracle working on Solaris core OS that
>> might be able to answer this question?
>
> What about Solaris documentation?
I read it over before, but felt that it was slightly ambiguous,
so I'm including it here for reference:
~~~
The runtime linker calls this interface with the highest
version of the rtld-audit interface the runtime linker is
capable of supporting. The audit library can verify this
version is sufficient for its use, and return the version
the audit library expects to use. This version is normally
LAV_CURRENT, which is defined in /usr/include/link.h.
If the audit library return is zero, or a version that is
greater than the rtld-audit interface the runtime linker
supports, the audit library is discarded.
~~~
It seems like each version could be completely orthogonal
and a totally different implementation. The audit library
then returns what interface it was designed for and thus
ld.so knows how to treat the audit module in question.
The wording does seem to indicate that if ld.so says
it supports verion 2, that it must also support version 1.
Thoughts?
Cheers,
Carlos.