Timothy Wall wrote:
You might try pulling down the official standalone libffi sources to
see if those build properly without mods. The JNA version has a few
local mods and was last pulled from a tagged GCC release. The JNA
patches haven't yet been applied to the standalone libffi, and there
have been some changes to standalone libffi that haven't been rolled
into the JNA version.
On Jul 9, 2008, at 10:04 AM, Cauchie, Julien wrote:
Ok, we made a build on our Solaris 8 - SunOS 5.8 box, and
after a few changes, we successfully obtained a jar file.
Julian - what toolchain were you using to build libffi?
If we can't get the preprocessor to omit the space, then I suppose we
can change the code look more like...
#define NWORD .long
#define UANWORD .uaword
and use NWORD instead of .nword.
AG
The interesting bit is that, in the end, that jar worked
successfully to locate and load libc.so.1
To reach that point, we had to make a few changes:
- the Makefile.in had to be modified to correctly reference where
libtool was stored
- some #define in native/libffi/src/sparc/v8.S where
problematic:
#ifdef SPARC64
#define WS 8
#define nword xword
#define uanword uaxword
#else
#define WS 4
#define nword long
#define uanword uaword
#endif
after the preprocessor ran, the few lines that showed
.nword
and
.uanword
ended up with: . long
and . uaword
with an extra space. Something the compiler didn't like. To make sure
it compiled, we just cheated and made the replacement that the
pre-processor
should have made.
Once this was done (and a few other changes in the Makefile to refer
to our local gcc),
we got our jar, which we could use.
10 messages in net.java.dev.jna.usersRe: [jna-users] libc loading on solaris
