On Nov 27, 2007, at 11:36 AM, Thomas E Enebo wrote:
On Mon, 26 Nov 2007, Timothy Wall defenestrated me:
Looks like GCC maps "stat" (and fstat/lstat) to an inline function,
which would explain why it doesn't show up in libc.so:
extern __inline__ int
__attribute__ ((__nothrow__)) stat (__const char *__path, struct stat
*__statbuf
)
{
return __xstat (3, __path, __statbuf);
}
Library.Handler.invoke or Function.invoke seem like the logical
points to tweak the invocation. If this is common, it might make
sense to make a function mogrifier option for the library.
So would the invoke capture the UnsatisifiedLink and then try and
invoke __xstat? Would I need to add __xstat to the Library
interface too?
I think the easiest thing would be that if you're on Linux, wrap the
original library in an extended interface which includes __xstat (so
you don't clutter the original interface), then generate a new proxy
using the extended interface. the invocation handler for the new
proxy forwards most calls to the original, but intercepts stat/fstat/
lstat and redirects them to __xstat, after fiddling with the
arguments the way the inline function does. The extended interface
can be used interchangeably with the generic one, so everything is
transparent.
19 messages in net.java.dev.jna.usersRe: [jna-users] stat() not mapping on...
