Xapian devel - Oct 2015 - Trying to get Search::Xapian perl module to compile on win32

Resurrecting an old thread from 2012!  Finally got back to working on this.  I
have been stuck in JavaScript land for too long.

Come to find out, on windows, perl does indeed define open to be win32_open and
close to be win32_close.  This is done in perl/lib/CORE/win3iop.h.  So, to get
past this problem, I had to modify Xapian.xs to do an #undef of open and close
if WIN32 is defined.

Also, I had to modify the Makefile.PL to not use xapian_config to get the values
it needs.

Attached is a work in progress patch for both files.  (hope the attachments come
through)  I am now getting linking errors.  I am working with the latest stable
version of xapian-core, which I cross-compiled on Ubuntu for win32.  I had to do
a couple of manual steps to convert the libxapian-22.dll into a libxapian-22.lib
using info from https://support.microsoft.com/en-us/kb/131313.  Specifically
using dumpbin /exports to create a definition file and then feeding the
definition file to lib /def to create the .lib and .exp files.

The call to generate the Makefile on win32 is now something like: 
    perl Makefile.PL CXX=cl.exe INC=-IC:\Install\include " LIBS=-lxapian-22
-lzlib" XAPIAN_VERSION=1.2.21 "CXXFLAGS=-EHsc -TP"
	
Now when I run nmake, it gets past the compile portion and dies when linking
with errors like:
Xapian.obj : error LNK2001: unresolved external symbol "public: __thiscall
Xapian::WritableDatabase:
:WritableDatabase(class Xapian::WritableDatabase const &)"
(??0WritableDatabase at Xapian@@QAE at ABV01@@Z)

Any clues on how to resolve the linking errors?
--
Dez.


-----Original Message-----
From: Olly Betts [mailto:olly at survex.com] 
Sent: Wednesday, October 24, 2012 12:07 PM
To: Desmond Daignault <desmond.daignault at oneil.com>
Cc: xapian-devel at lists.xapian.org
Subject: Re: [Xapian-devel] Trying to get Search::Xapian perl module to compile
on win32

On Wed, Oct 24, 2012 at 03:20:21PM +0000, Desmond Daignault
wrote:
> ./XS/WritableDatabase.xs(30) : error C2039: 'win32_open' : is not a
member of 'Xapian::InMemory'
> ./XS/WritableDatabase.xs(30) : error C2660: 'win32_open' : function
does not take 0 arguments
> ./XS/WritableDatabase.xs(50) : warning C4003: not enough actual parameters
for macro 'close'
> ./XS/WritableDatabase.xs(50) : error C2039: 'win32_close' : is not
a member of 'Xapian::WritableDatabase'
Sounds to me like something is playing macro games along the lines of:

#define open win32_open
#define close win32_close

And that is mangling the method names in our code.

I don't use windows, but I can tell you it isn't anything in Xapian
doing this.

Cheers,
    Olly

**********************************************************************
Confidentiality Notice
The information contained in this e-mail is confidential and intended for use
only by the person(s) or organization listed in the address. If you have
received this communication in error, please contact the sender at O'Neil
& Associates, Inc., immediately. Any copying, dissemination, or distribution
of this communication, other than by the intended recipient, is strictly
prohibited.
**********************************************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: search_xapian_xs.patch
Type: application/octet-stream
Size: 477 bytes
Desc: search_xapian_xs.patch
URL:
<http://lists.xapian.org/pipermail/xapian-devel/attachments/20151028/db06f391/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: search_xapian_makefile_pl.patch
Type: application/octet-stream
Size: 4016 bytes
Desc: search_xapian_makefile_pl.patch
URL:
<http://lists.xapian.org/pipermail/xapian-devel/attachments/20151028/db06f391/attachment-0005.obj>

On Wed, Oct 28, 2015 at 08:46:15PM +0000, Desmond Daignault
wrote:
> Come to find out, on windows, perl does indeed define open to be win32_open
and close to be win32_close.  This is done in perl/lib/CORE/win3iop.h.  So, to
get past this problem, I had to modify Xapian.xs to do an #undef of open and
close if WIN32 is defined.
> 
> Also, I had to modify the Makefile.PL to not use xapian_config to get the
values it needs.
> 
> Attached is a work in progress patch for both files.  (hope the attachments
come through)  I am now getting linking errors.  I am working with the latest
stable version of xapian-core, which I cross-compiled on Ubuntu for win32.  I
had to do a couple of manual steps to convert the libxapian-22.dll into a
libxapian-22.lib using info from https://support.microsoft.com/en-us/kb/131313. 
Specifically using dumpbin /exports to create a definition file and then feeding
the definition file to lib /def to create the .lib and .exp files.
> 
> The call to generate the Makefile on win32 is now something like: 
>     perl Makefile.PL CXX=cl.exe INC=-IC:\Install\include "
LIBS=-lxapian-22 -lzlib" XAPIAN_VERSION=1.2.21 "CXXFLAGS=-EHsc
-TP"
Presumably you're cross-compiling with GCC?
> Now when I run nmake, it gets past the compile portion and dies when
linking with errors like:
> Xapian.obj : error LNK2001: unresolved external symbol "public:
__thiscall Xapian::WritableDatabase:
> :WritableDatabase(class Xapian::WritableDatabase const &)"
(??0WritableDatabase at Xapian@@QAE at ABV01@@Z)
> 
> Any clues on how to resolve the linking errors?
I'd be surprised if you can mix C++ code compiled with GCC with C++ code
compiled with MSVC - you probably need to use either GCC or MSVC to
build both xapian-core and Search::Xapian.  C code should interwork
fine, so it shouldn't matter what perl was built with.

Before I can apply the patches, I need to check you're OK with the
licensing requirements:

http://trac.xapian.org/browser/trunk/xapian-core/HACKING#L1364

Actually for Search::Xapian it ought to be a "same licence as Perl" in
place of "GPL version 2 and all later versions".  (The dual licence
with
MIT/X is still useful there as it allows us to apply patches to the
SWIG-based Perl bindings on trunk).
> **********************************************************************
> Confidentiality Notice
> The information contained in this e-mail is confidential and intended for
use only by the person(s) or organization listed in the address. If you have
received this communication in error, please contact the sender at O'Neil
& Associates, Inc., immediately. Any copying, dissemination, or distribution
of this communication, other than by the intended recipient, is strictly
prohibited.
> **********************************************************************
Also, please explicitly confirm that this notice isn't intended to apply
to the patches.  If we apply them they'll definitely be used by people
you didn't address this email to...

Cheers,
    Olly

The disclaimer automatically added and is not intended to limit legitimate
discourse, and any code I write for this is expected to be licensed under
whatever license the original work is using.

I haven't tried compiling latest code under visual studio yet (is this
possible?).  I wonder if there is a way to tell gcc to not mangle the names
during cross compile.  I was able to successfully cross compile libxml and a few
others without impacting the perl module compile but that is probably due to
them being just a C project.

--
Dez.


-----Original Message-----	
From: Olly Betts [mailto:olly at survex.com] 
Sent: Wednesday, October 28, 2015 5:35 PM
To: Desmond Daignault <desmond.daignault at oneil.com>
Cc: Xapian Development <xapian-devel at lists.xapian.org>
Subject: Re: [Xapian-devel] Trying to get Search::Xapian perl module to compile
on win32

On Wed, Oct 28, 2015 at 08:46:15PM +0000, Desmond Daignault
wrote:
> Come to find out, on windows, perl does indeed define open to be win32_open
and close to be win32_close.  This is done in perl/lib/CORE/win3iop.h.  So, to
get past this problem, I had to modify Xapian.xs to do an #undef of open and
close if WIN32 is defined.
> 
> Also, I had to modify the Makefile.PL to not use xapian_config to get the
values it needs.
> 
> Attached is a work in progress patch for both files.  (hope the attachments
come through)  I am now getting linking errors.  I am working with the latest
stable version of xapian-core, which I cross-compiled on Ubuntu for win32.  I
had to do a couple of manual steps to convert the libxapian-22.dll into a
libxapian-22.lib using info from https://support.microsoft.com/en-us/kb/131313. 
Specifically using dumpbin /exports to create a definition file and then feeding
the definition file to lib /def to create the .lib and .exp files.
> 
> The call to generate the Makefile on win32 is now something like: 
>     perl Makefile.PL CXX=cl.exe INC=-IC:\Install\include "
LIBS=-lxapian-22 -lzlib" XAPIAN_VERSION=1.2.21 "CXXFLAGS=-EHsc
-TP"
Presumably you're cross-compiling with GCC?
> Now when I run nmake, it gets past the compile portion and dies when
linking with errors like:
> Xapian.obj : error LNK2001: unresolved external symbol "public:
__thiscall Xapian::WritableDatabase:
> :WritableDatabase(class Xapian::WritableDatabase const &)"
(??0WritableDatabase at Xapian@@QAE at ABV01@@Z)
> 
> Any clues on how to resolve the linking errors?
I'd be surprised if you can mix C++ code compiled with GCC with C++ code
compiled with MSVC - you probably need to use either GCC or MSVC to
build both xapian-core and Search::Xapian.  C code should interwork
fine, so it shouldn't matter what perl was built with.

Before I can apply the patches, I need to check you're OK with the
licensing requirements:

http://trac.xapian.org/browser/trunk/xapian-core/HACKING#L1364

Actually for Search::Xapian it ought to be a "same licence as Perl" in
place of "GPL version 2 and all later versions".  (The dual licence
with
MIT/X is still useful there as it allows us to apply patches to the
SWIG-based Perl bindings on trunk).
> **********************************************************************
> Confidentiality Notice
> The information contained in this e-mail is confidential and intended for
use only by the person(s) or organization listed in the address. If you have
received this communication in error, please contact the sender at O'Neil
& Associates, Inc., immediately. Any copying, dissemination, or distribution
of this communication, other than by the intended recipient, is strictly
prohibited.
> **********************************************************************
Also, please explicitly confirm that this notice isn't intended to apply
to the patches.  If we apply them they'll definitely be used by people
you didn't address this email to...

Cheers,
    Olly