Olly Betts | 4 Jul 2003 23:30
Favicon
Gravatar

Xapian on Microsoft Windows

Xapian now compiles cleanly using a Linux hosted mingw cross-compiler.
The remote backend doesn't work (no fork() or socketpair()) but at
least configure now notices this and automatically disables that
backend.

The test suite programs build, but obviously don't run on Linux.

Is anyone interested in trying to run the test cases and see if they
work?  If you have the Debian mingw cross-compiler installed, just
configure with:

./configure --host=i586-mingw32msvc

If you've rolled your own, the configure runes may be slightly
different.

Then "make" and "make check".  Then I assume you can tar or zip up
the build tree, unpack on windows, and run all the *test.exe programs
in tests/ and extra/.

I can supply a suitable tarball or zip if that helps.

Cheers,
    Olly

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
(Continue reading)

James Aylett | 8 Jul 2003 22:50

Build problems with CVS

libomqueryparser is giving me problems, complaining about:

----------------------------------------------------------------------
/u1/james/install/lib/libomqueryparser.so.0: undefined symbol: __gxx_personality_v0
----------------------------------------------------------------------

which presumably means it isn't fully linked, or something. This is
only happening in the Python bindings, but wasn't happening fairly
recently (whenever my last burst of checkins before this one happened
- about a month ago).

I'm guessing this is down to the line:

----------------------------------------------------------------------
_xapian_la_LDFLAGS = -avoid-version -module
----------------------------------------------------------------------

which I can only assume works fine on higher versions of G++ (I'm
using 3.0.4 from Debian stable). It's not the -module bit though.

I'm fishing somewhat here - any ideas?

J

--

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  james <at> tartarus.org                               uncertaintydivision.org

-------------------------------------------------------
(Continue reading)

Olly Betts | 8 Jul 2003 23:02
Favicon
Gravatar

Re: Build problems with CVS

On Tue, Jul 08, 2003 at 09:50:58PM +0100, James Aylett wrote:
> libomqueryparser is giving me problems, complaining about:
> 
> ----------------------------------------------------------------------
> /u1/james/install/lib/libomqueryparser.so.0: undefined symbol: __gxx_personality_v0

Smells to me like mismatched GCC versions.

> which presumably means it isn't fully linked, or something. This is
> only happening in the Python bindings, but wasn't happening fairly
> recently (whenever my last burst of checkins before this one happened
> - about a month ago).

What's the actual command which outputs this message?

Cheers,
    Olly

-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps
Olly Betts | 9 Jul 2003 01:38
Favicon
Gravatar

Re: Build problems with CVS

On Tue, Jul 08, 2003 at 09:50:58PM +0100, James Aylett wrote:
> libomqueryparser is giving me problems, complaining about:
> 
> /u1/james/install/lib/libomqueryparser.so.0: undefined symbol: __gxx_personality_v0

A bit of poking round the web suggests the problem could be caused by
linking with gcc instead of g++.  This message may be helpful:

http://gcc.gnu.org/ml/gcc-help/2002-07/msg00186.html
Cheers,
    Olly

-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps
Olly Betts | 9 Jul 2003 12:36
Favicon
Gravatar

Bindings

I had a go last night at getting the bindings going for other languages
which we used to have support for.  This reminded me of an unresolved
issue with the PHP4 bindings - they currently need Xapian to be
installed before they can be built, but they try to build as part of
the Xapian build process.

They need Xapian installed because of the way they are built - SWIG
creates a mini autoconf-based project, which we then configure and
build.  This project needs to locate Xapian, and Xapian needs to be
installed because of the configure code SWIG generates.

We could try to trick SWIG's configure to work with uninstalled headers
and libraries, but that would essentially be returning to the whole
"xapian-config --uninst" can of worms, and I really don't want to go
back there.

I wonder if the simplest approach is to split the bindings into a
separate module, similar to the way Omega and xapian-examples are.  The
bindings use the same public API which Omega and xapian-examples do so
this does seem appropriate.  And Alex's XS Perl bindings are similarly
separate.

Thoughts?

Cheers,
    Olly

-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
(Continue reading)

Sam Liddicott | 9 Jul 2003 11:59

Re: Bindings

Olly Betts wrote:

>I wonder if the simplest approach is to split the bindings into a
>separate module, similar to the way Omega and xapian-examples are.  The
>bindings use the same public API which Omega and xapian-examples do so
>this does seem appropriate.  And Alex's XS Perl bindings are similarly
>separate.
>
>Thoughts?
>  
>
That makes sense to me.
The php config allows specification of where xapian libraries and such 
can be found, but I'm not sure how much of that information is embedded 
in the built binaries.

I'm happy for bindings to be moved to a seperate module.

Sam

-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps
Arjen van der Meijden | 9 Jul 2003 13:03
Picon
Picon

RE: Bindings

> Olly Betts wrote:
> 
> We could try to trick SWIG's configure to work with 
> uninstalled headers and libraries, but that would essentially 
> be returning to the whole "xapian-config --uninst" can of 
> worms, and I really don't want to go back there.
Do you mean, by this, to build the php-binding against the libraries and
includes in the working-directory?

If not, why don't you use that approach?
Afaik you don't need the headers afterwards and you'll need the
xapian-libraries to be findable by ldconfig anyway if you want to use
the libraries that get created by this process.

> I wonder if the simplest approach is to split the bindings 
> into a separate module, similar to the way Omega and 
> xapian-examples are.  The bindings use the same public API 
> which Omega and xapian-examples do so this does seem 
> appropriate.  And Alex's XS Perl bindings are similarly separate.
Perhaps it's the easiest way. If I'd have to use the php-bindings it'd
be nice if they got installed along with the buildprocess of xapian but
if that isn't possible, that's just to bad :)
As long as the php-bindings are useable after some easy build process,
that'd be ok with me at least ;)

Regards,

Arjen

-------------------------------------------------------
(Continue reading)

James Aylett | 9 Jul 2003 13:19

Re: Build problems with CVS

On Wed, Jul 09, 2003 at 12:38:06AM +0100, Olly Betts wrote:

> > libomqueryparser is giving me problems, complaining about:
> > 
> > /u1/james/install/lib/libomqueryparser.so.0: undefined symbol: __gxx_personality_v0
> 
> A bit of poking round the web suggests the problem could be caused by
> linking with gcc instead of g++.  This message may be helpful:
> 
> http://gcc.gnu.org/ml/gcc-help/2002-07/msg00186.html

Okay, well this is libtool's fault, because even when told to use
g++-3.0 it uses gcc-3.0 to do the link. Running the commands by hand
doesn't help much, because libtool in install mode relinks the library
anyway. I don't know nearly enough about autotools to fix this ... :-(

J

--

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  james <at> tartarus.org                               uncertaintydivision.org

-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps
James Aylett | 9 Jul 2003 13:20

Re: Bindings

On Wed, Jul 09, 2003 at 11:36:11AM +0100, Olly Betts wrote:

> I had a go last night at getting the bindings going for other languages
> which we used to have support for.  This reminded me of an unresolved
> issue with the PHP4 bindings - they currently need Xapian to be
> installed before they can be built, but they try to build as part of
> the Xapian build process.

Yeah, this is quite horrible :-(

I vote for having xapian-bindings as a separate module; Richard and I
discussed it a while ago, and it seemed to make sense then.

J

--

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  james <at> tartarus.org                               uncertaintydivision.org

-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps
Olly Betts | 9 Jul 2003 13:54
Favicon
Gravatar

Re: Bindings

On Wed, Jul 09, 2003 at 01:03:10PM +0200, Arjen van der Meijden wrote:
> Olly Betts wrote:
> > We could try to trick SWIG's configure to work with 
> > uninstalled headers and libraries, but that would essentially 
> > be returning to the whole "xapian-config --uninst" can of 
> > worms, and I really don't want to go back there.

> Do you mean, by this, to build the php-binding against the libraries and
> includes in the working-directory?

Yes.

> If not, why don't you use that approach?

There are a myriad of problems with trying to do so - xapian-config used
to support various --uninst* options to attempt to allow this, but it
was a real bug mine, so we concluded that it was better to require
Xapian to actually be installed (under some user-chosen prefix if you
don't have root access) and spend the developer time saved on more
productive and less soul-destroying Xapian work.

> Afaik you don't need the headers afterwards and you'll need the
> xapian-libraries to be findable by ldconfig anyway if you want to use
> the libraries that get created by this process.

Libtool tries to take care of cross-platform library variations, but
that gets in the way if you don't want to (or can't) use libtool.
That's the case here.  The configure code which phpize generates
looks for libXXX.a or libXXX.so - to link with libtool it needs to
look for libXXX.la instead.  So to humour phpize, we need to dig
(Continue reading)


Gmane