Xapian discuss - Feb 2006 - Compiling the PHP bindings with Cygwin ?

Has anyone successfully compiled the PHP bindings with Cygwin (on W2K) ?

I usually use OS X and the PHP bindings work fine there (thanks for the
astonishing work on Xapian !), but my web site is now production-ready and my
web server runs Windows 2000.

I've successfully compiled xapian-core with cygwin (worked out of the box)
and I
almost got the PHP bindings to compile : I had to remove the '-g -O2'
CXXFLAGS
because when they are on, cc runs out of memory ; now they are compiled, but
the link fails : it says that all the PHP _zend symbols are undefined (and
that's correct, we don't link with any PHP DLL).

I know the same error can be fixed on OS X with -undefined dynamic_lookup (since
PHP will load our bindings...) but if I've googled correctly there is no
such
option on Windows, since the DLL system is different from the dynamic libraries
system on Unix and the bundles system on Mac OS X.

So, has anyone managed to find the right commands to get these bindings compiled
? I thought of using pexport (from mingw) and dlltool to build a .a version of
the PHP DLL that Apache loads, but statically linking with it does not seem to
be the proper way....

Thank you in advance,

-- 
Thomas Deniau

On Tue, Feb 14, 2006 at 10:38:42AM +0100, Thomas Deniau
wrote:
> Has anyone successfully compiled the PHP bindings with Cygwin (on W2K) ?
I know people have tried to build the Python bindings (and I've applied
a few patches to help that work).  I don't think I've heard from anyone
who's tried the PHP bindings.
> I usually use OS X and the PHP bindings work fine there (thanks for the
> astonishing work on Xapian !), but my web site is now production-ready and
my
> web server runs Windows 2000.
> 
> I've successfully compiled xapian-core with cygwin (worked out of the
box) and I
> almost got the PHP bindings to compile : I had to remove the '-g
-O2' CXXFLAGS
> because when they are on, cc runs out of memory
I discovered that enormous compile-time memory requirements when
optimising are caused by the exception handling in each wrapped method.
In SVN HEAD I've factored out as much of the exception handling as I
could into a single function, which is then hooked by a minimal
exception handler from each wrapper.  I haven't measured the compiler
memory use, but for the Tcl bindings on x86_64 this change cut the
compile time by around a factor of 3 and halved the size of the stripped
library.
> now they are compiled, but the link fails : it says that all the PHP
> _zend symbols are undefined (and that's correct, we don't link with
> any PHP DLL).
> 
> I know the same error can be fixed on OS X with -undefined
> dynamic_lookup (since PHP will load our bindings...) but if I've
> googled correctly there is no such option on Windows, since the DLL
> system is different from the dynamic libraries system on Unix and the
> bundles system on Mac OS X.
Windows doesn't allow you to build a DLL with unresolved symbols.

And incidentally, OS X should work out of the box in the next release.
> So, has anyone managed to find the right commands to get these
> bindings compiled ? I thought of using pexport (from mingw) and
> dlltool to build a .a version of the PHP DLL that Apache loads, but
> statically linking with it does not seem to be the proper way....
I think this is the correct way.  The .a that you generate like this
isn't actually a static version of the DLL - it's what they call an
"import library", and effectively contains stub definitions which
you link against.  But at run time the DLL is loaded and used.

If you've a fairly recent Cygwin (binutils 2.13.90-20030111-1 or later),
you should be able to just link against the PHP DLL (ld can sort out the
imports on the fly).  You can check the binutils version with:

ld --version

You may need to pass this flag when linking to get that to work:

-Wl,--enable-runtime-pseudo-reloc

You can easily try this by building PHP's xapian-bindings with:

make xapian_la_LDFLAGS='-avoid-version -module -no-undefined
-Wl,--enable-runtime-pseudo-reloc'

If that works, I can change configure to always pass this where
appropriate (xapian-core already does this).

Cheers,
    Olly

Keep discussion on the list please.

On Tue, Feb 14, 2006 at 01:51:42PM +0100, Thomas Deniau
wrote:
> Olly Betts <olly@survex.com> a ecrit :
> 
> >I think this is the correct way.  The .a that you generate like this
> >isn't actually a static version of the DLL - it's what they
call an
> >"import library", and effectively contains stub definitions
which
> >you link against.  But at run time the DLL is loaded and used.
> 
> pexports fails when I try to use it on the php5apache2.dll anyway (sorry, I
> don't have the exact error, the machine I'm using to connect to the
Net is
> severed from our internal network).
Never mind, --enable-runtime-pseudo-reloc route is the better route
anyway since if we can get it to work we can avoid the user needing
to perform any extra steps.  You already need it to build a
xapian-core DLL on windows, so it's not a problem to use it here too.
> >You can easily try this by building PHP's xapian-bindings with:
> >
> >make xapian_la_LDFLAGS='-avoid-version -module -no-undefined 
> >-Wl,--enable-runtime-pseudo-reloc'
> 
> That fails too. When I add '-Lmyphpdir -lphp5apache2' to these
flags, the
> link succeeds, but it produces a static xapian.a file that PHP can't
load
> instead of a DLL file.
Ah yes, you'll need those too.

I'm very suprised it builds a ".a" since we disable static
libraries
explicitly in configure.  If you failed to specify "-no-undefined" I
can see this might happen though perhaps, so that's something to check.
> So I tried to use dllwrap to make it a dll, but I get again the same 
> unresolved symbols error (in addition, the Xapian symbols are now
> undefined, too), even when I add the flags above (and -lxapian
> -L/usr/local/lib) to --driver-flags .
I think we need to work out why we don't get a DLL in the first place.
Could you save the output from "make xapian_la_LDFLAGS=[...]" as well
as
"config.log" on a floppy and then email them?

Cheers,
    Olly