Subject | Re: [firebird-php] Building interbase.so on Mandriva |
---|---|
Author | Lester Caine |
Post date | 2007-10-28T21:12:43Z |
Jochem Maas wrote:
--without-pear
Seems to work OK as long as I go 'su' to build all the missing directories.
installation because it's copying to /usr/local/.. but it is also not creating
a working interbase.so module - only giving a 6.9k stub rather than an 87k
library :(
Is there no way to just build the one module you are working on :(
In any case, the problem seems to be a little more subtle. I suspect that the
blob_id string returned my actually not have the right 'endian' for the to 32
bit parts - at least that is what it looks like may be happening. A correctly
formatted 18 character string with the 0xnnnnnnnnnnnnnnnn format is returned (
unlike the previous fault which did not return a valid number ) but it is not
being accepted by the blob routines as a valid blob. But until I can actually
build a valid extension ......
--
Lester Caine - G8HFL
-----------------------------
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird - http://www.firebirdsql.org/index.php
> Lester Caine wrote:./configure --with-interbase=shared,/var/lib64/firebird/ --disable-all
>
> isn't there a 'modules' target for make?
>
> ./configure '--with-ibase' (or what ever the configure switch is)
--without-pear
Seems to work OK as long as I go 'su' to build all the missing directories.
> ./make modulesNope - no 'make' script in this install
> or you can just do make and then move the .so by hand rather thanmake install works - and fortunately it does not destroy the real PHP
> running 'make install', no?
installation because it's copying to /usr/local/.. but it is also not creating
a working interbase.so module - only giving a 6.9k stub rather than an 87k
library :(
Is there no way to just build the one module you are working on :(
In any case, the problem seems to be a little more subtle. I suspect that the
blob_id string returned my actually not have the right 'endian' for the to 32
bit parts - at least that is what it looks like may be happening. A correctly
formatted 18 character string with the 0xnnnnnnnnnnnnnnnn format is returned (
unlike the previous fault which did not return a valid number ) but it is not
being accepted by the blob routines as a valid blob. But until I can actually
build a valid extension ......
--
Lester Caine - G8HFL
-----------------------------
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird - http://www.firebirdsql.org/index.php