Desmond Daignault
2015-Oct-28 20:46 UTC
[Xapian-devel] 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>
Olly Betts
2015-Oct-28 21:35 UTC
[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
Desmond Daignault
2015-Oct-29 13:51 UTC
[Xapian-devel] Trying to get Search::Xapian perl module to compile on win32
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