[jna-users] libc loading on solaris

[Anthony Green]

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.
>>