headers
John Schult | 4 Feb 17:59
Picon
Gravatar

Java Bindings on a Mac

I had to make some changes (sorry no diff available) to "configure" in
0.9.9 of the bindings so that I could compile them for OS X 10.4.8.
Essentially I replaced the the paths to jni.h with
/System/Library/Frameworks/JavaVM.framework/Headers.  It compiled
without error and created both libxapian_jni.so and xapian_jni.jar in
the "built" subdirectory when I ran "make install".

When I ran the example code (from the "java" directory) I got the following:

$ java -Djava.library.path=built -classpath built/xapian_jni.jar:. \
>       org.xapian.examples.SimpleIndex ./test.db index words like java
Exception in thread "main" java.lang.UnsatisfiedLinkError: no
xapian_jni in java.library.path
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1682)
        at java.lang.Runtime.loadLibrary0(Runtime.java:822)
        at java.lang.System.loadLibrary(System.java:992)
        at org.xapian.XapianJNI.<clinit>(XapianJNI.java:44)
        at org.xapian.WritableDatabase.<init>(WritableDatabase.java:42)
        at org.xapian.examples.SimpleIndex.main(SimpleIndex.java:44)

It did not make any difference when I set LD_LIBRARY_PATH to the
absolute "built" path either.  I got the same results.  I am using the
Apple Java 5 J2SE.  Has anyone gotten the bindings to work under OS X?

--

-- 
john david schult
usa : georgia : buford
m: 404.510.5163
Permalink | Reply | 502 comments |
headers
John Schult | 4 Feb 19:30
Picon
Gravatar

Re: Java Bindings on a Mac

Well, thanks to a colleague I figured it out...  The Apple JVM looks
for libraries in
/System/Library/Frameworks/JavaVM.framework/Libraries/ and does not
seem to care about -Djava.library.path or LD_LIBRARY_PATH.  There is
probably some environment variable that it does examine, but I stopped
trying to figure it out.

The solution was to:

- Copy built/libxapian_jni.so to
/System/Library/Frameworks/JavaVM.framework/Libraries/libxapian_jni.jnilib
(note the extension)

After that it worked as advertised...

$ java -version
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-113)
Java HotSpot(TM) Client VM (build 1.5.0_06-68, mixed mode, sharing)

$ uname -a
Darwin apollo.local 8.8.2 Darwin Kernel Version 8.8.2: Thu Sep 28
20:43:26 PDT 2006; root:xnu-792.14.14.obj~1/RELEASE_I386 i386 i386

$ java -classpath built/xapian_jni.jar:.
org.xapian.examples.SimpleSearch ./test.db index words like java
Found 4 matching documents using Xapian::Query((index OR words OR like OR java))
25% [1] index
25% [2] words
25% [3] like
(Continue reading)

Permalink | Reply | 502 comments |
headers
Olly Betts | 6 Feb 07:28
Favicon
Gravatar

MSVC large file support (was Re: Re: [Xapian-commits] 7603: trunk/xapian-core/ trunk/xapian-core/backends/flint/ trunk/xapian-core/backends/quartz/)

On Mon, Jan 29, 2007 at 05:31:19PM +0000, Charlie Hull wrote:
> I've produced patches for xapian-compact.cc, quartzcompact.cc and 
> quartzcheck.cc (enclosed). Unfortunately I don't have any way of quickly 
> testing them here but we should soon have some kind of Xapian test 
> framework on Windows, complete with huge files, so I'll do it then.

I don't think this patch is quite correct - MSDN seems to say that
_stat64() only increases the size of the *TIMESTAMP* fields to 64 bit
- I think we actually want _stati64()!  That's consistent with needing
to use _lseeki64() instead of lseek() I guess.

I think it's cleaner, and more robust to future changes, to put the
magic in one place rather than fixing this in the files which use
stat(), so I've done a bit of refactoring of this patch and some of the
other MSVC specific bits and created a couple of new "safeXXX.h" headers
which is how we've been encapsulating other platform specific oddities.

The patched version builds cleanly on Linux, so I've checked in the
changes to SVN HEAD (revision 7605) to see if it builds on the tinderbox
machines.  Could you see if it at least builds on MSVC even if you can't
try it on 2GB+ files right now?

Cheers,
    Olly
Permalink | Reply | 4 comments |
headers
Olly Betts | 6 Feb 07:57
Favicon
Gravatar

Re: Re: [Xapian-commits]7603: trunk/xapian-core/trunk/xapian-core/backends/flint/trunk/xapian-core/backends/quartz/

On Wed, Jan 31, 2007 at 10:36:12AM +0100, Grzegorz Bogdanowicz wrote:
> What kind of result will interessed You?
> 
> quartzcheck -> (no errors found)
> quartzcompact -> (correct compact)

Thanks for testing.

The output is probably what's most interesting.  I don't know how stat()
reacts to a 2GB+ file on Windows (on Unix it fails returning -1 on the
platforms I've tested).

If stat fails, quartzcompact will work but won't report the compression
statistics but will say:

    Done (couldn't stat all the DB files)

If stat() returns successfully but with a bogus filesize, then the
compression statistics will also be bogus.  Seeing the uncompacted
and compacted filesizes as well as the output from quartzcompact
might allow us to spot that.

But I think Charlie's original patch isn't quite correct anyway.

Cheers,
    Olly
Permalink | Reply | 4 comments |
headers
Olly Betts | 6 Feb 08:32
Favicon
Gravatar

Re: Re: Java Bindings on a Mac

On Sun, Feb 04, 2007 at 01:30:15PM -0500, John Schult wrote:
> Well, thanks to a colleague I figured it out...  The Apple JVM looks
> for libraries in
> /System/Library/Frameworks/JavaVM.framework/Libraries/ and does not
> seem to care about -Djava.library.path or LD_LIBRARY_PATH.  There is
> probably some environment variable that it does examine, but I stopped
> trying to figure it out.

I'm not a Mac expert, but libtool seems to think OS X uses
DYLD_LIBRARY_PATH rather than LD_LIBRARY_PATH.

Does "make check" work in the java subdirectory of the built source
tree?

> >Essentially I replaced the the paths to jni.h with
> >/System/Library/Frameworks/JavaVM.framework/Headers.

When you say "essentially", was that the only change?  If so, we should
be able to do that automatically for OS X.  And similarly for the
installation location and different library extension.

Cheers,
    Olly
Permalink | Reply | 5 comments |
headers
Charlie Hull | 6 Feb 11:20

Re: MSVC large file support (was Re: Re: [Xapian-commits] 7603: trunk/xapian-core/ trunk/xapian-core/backends/flint/ trunk/xapian-core/backends/quartz/)

Olly Betts wrote:
> On Mon, Jan 29, 2007 at 05:31:19PM +0000, Charlie Hull wrote:
>> I've produced patches for xapian-compact.cc, quartzcompact.cc and 
>> quartzcheck.cc (enclosed). Unfortunately I don't have any way of quickly 
>> testing them here but we should soon have some kind of Xapian test 
>> framework on Windows, complete with huge files, so I'll do it then.
> 
> I don't think this patch is quite correct - MSDN seems to say that
> _stat64() only increases the size of the *TIMESTAMP* fields to 64 bit
> - I think we actually want _stati64()!  That's consistent with needing
> to use _lseeki64() instead of lseek() I guess.
> 
> I think it's cleaner, and more robust to future changes, to put the
> magic in one place rather than fixing this in the files which use
> stat(), so I've done a bit of refactoring of this patch and some of the
> other MSVC specific bits and created a couple of new "safeXXX.h" headers
> which is how we've been encapsulating other platform specific oddities.
> 
> The patched version builds cleanly on Linux, so I've checked in the
> changes to SVN HEAD (revision 7605) to see if it builds on the tinderbox
> machines.  Could you see if it at least builds on MSVC even if you can't
> try it on 2GB+ files right now?
> 
> Cheers,
>     Olly
> 
That's much better Olly; keeping the platform specific stuff out is a 
much tidier approach. I've had to make a small change to stop the MS 
headers barfing (attached), but apart from that it builds fine.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Olly Betts | 6 Feb 11:40
Favicon
Gravatar

Re: MSVC large file support (was Re: Re: [Xapian-commits] 7603: trunk/xapian-core/ trunk/xapian-core/backends/flint/ trunk/xapian-core/backends/quartz/)

On Tue, Feb 06, 2007 at 10:20:20AM +0000, Charlie Hull wrote:
> That's much better Olly; keeping the platform specific stuff out is a 
> much tidier approach. I've had to make a small change to stop the MS 
> headers barfing (attached), but apart from that it builds fine.

Hmm, what was the error?  Ideally these safeXXX.h headers should be
usable in the same order as the XXX.h headers they replace...

Cheers,
    Olly
Permalink | Reply | 2 comments |
headers
Charlie Hull | 6 Feb 11:49

Re: MSVC large file support (was Re: Re: [Xapian-commits] 7603: trunk/xapian-core/ trunk/xapian-core/backends/flint/ trunk/xapian-core/backends/quartz/)

Olly Betts wrote:
> On Tue, Feb 06, 2007 at 10:20:20AM +0000, Charlie Hull wrote:
>> That's much better Olly; keeping the platform specific stuff out is a 
>> much tidier approach. I've had to make a small change to stop the MS 
>> headers barfing (attached), but apart from that it builds fine.
> 
> Hmm, what was the error?  Ideally these safeXXX.h headers should be
> usable in the same order as the XXX.h headers they replace...
> 
> Cheers,
>     Olly
> 

wchar.h was complaining at this line:

typedef long off_t;                /* file offset value */

because you'd already defined off_t as __int64.

Charlie
Permalink | Reply | 1 comment |
headers
Grzegorz Bogdanowicz | 6 Feb 12:27
Picon
Favicon

Re: Re: [Xapian-commits]7603: trunk/xapian-core/trunk/xapian-core/backends/flint/trunk/xapian-core/backends/quartz/

hi,

This is result for one database which have 2G+ files:

C:\xapian>quartzcompact.exe c:\index_en2 f:\index_compact
postlist: INCREASED by -39.1461% 776392K (-1983320K -> -1206928K)
record: Reduced by 47.1947% 5720K (12120K -> 6400K)
termlist: INCREASED by -140.441% 451480K (-321472K -> 130008K)
position: Size unchanged (0K)
value: Size unchanged (0K)

source database:

C:\index_en2>

2007-02-06  09:25    <DIR>          .
2007-02-06  09:25    <DIR>          ..
2007-01-03  16:07                10 meta
2007-01-04  12:18                14 position_baseA
2007-01-04  12:08                14 position_baseB
2007-01-03  16:07                 0 position_DB
2007-01-04  12:18           100 104 postlist_baseA
2007-01-04  12:08            97 939 postlist_baseB
2007-01-04  12:18     6 559 014 912 postlist_DB
2007-01-04  12:18               207 record_baseA
2007-01-04  12:08               181 record_baseB
2007-01-04  12:18        12 410 880 record_DB
2007-01-04  12:18           126 070 termlist_baseA
2007-01-04  12:08           122 906 termlist_baseB
2007-01-04  12:18     8 260 747 264 termlist_DB
(Continue reading)

Permalink | Reply | 3 comments |
headers
Olly Betts | 7 Feb 02:17
Favicon
Gravatar

Re: MSVC large file support (was Re: Re: [Xapian-commits] 7603: trunk/xapian-core/ trunk/xapian-core/backends/flint/ trunk/xapian-core/backends/quartz/)

On Tue, Feb 06, 2007 at 10:49:12AM +0000, Charlie Hull wrote:
> wchar.h was complaining at this line:
> 
> typedef long off_t;                /* file offset value */
> 
> because you'd already defined off_t as __int64.

Apparently sys/types.h has a typedef for off_t too, so I think the best
fix is to just explicitly #include that from safeunistd.h before we
#define off_t to something else.  I've committed that change.

Cheers,
    Olly
Permalink | Reply | 0 comments |

Gmane