#34339 [WFx]: linking probleme oci8 in 32bit with oracle 64bit...
ID: 34339 User updated by: info at ch2o dot info Reported By: info at ch2o dot info Status: Wont fix Bug Type: OCI8 related Operating System: HP-UX -PHP Version: 4.4.0 +PHP Version: 4.4.0 and 5.0.4 New Comment: have tested backport to php4.4 and 5.0 of oci8/config.m4 from PHP 5.1 with add of the PHP_CHECK_64BIT in acinclude.m4 and work fine on hp-ux 11.11 with oracle 9i 64Bit... checking for Oracle (OCI8) support using ORACLE_HOME installation... yes checking Oracle Install Directory... /usr/local/oracle/ checking for long int... yes checking size of long int... 4 checking checking if we're at 64-bit platform... no checking OCI8 libraries dir... lib32 checking Oracle version... 9.0 checking for OCIEnvNlsCreate in -lclntsh... yes checking for OCINlsCharSetNameToId in -lclntsh... yes checking for OCILobIsTemporary in -lclntsh... yes checking for OCICollAssign in -lclntsh... yes in fact the 64Bit test work fine, is my fault have focalized on the size of the long int of 4 byte for 64Bit... but is reverse test : if not sized 4 byte is 64Bit! ... have tested also with instant client... and work fine also... Previous Comments: [2005-09-02 20:07:19] info at ch2o dot info i can't test the 64bit completely the 64Bit compile mode on hp-ux, in case i must compile all depandancy of php in 64Bit mode and is very long operation for my little time i have...but i can test the cli compile with hp-ux compiler but with only the included module... i while try it if i have some time in the near future... but in 32bit compile mode on hp-ux 64Bit, with the autodetecting of the good Oracle lib dir (lib or lib32), with the oci8/config.m4 (version 1.51) provided by php5.1 (a good solution) they dont work because the macro PHP_CHECK_64BIT detect that php are compiled in 64Bit not in 32Bit... because "long int" are 4 bit on hp-ux 11.11 on 64Bit hardware in 32bit compiled binary... but the compiler bloc the setting of variable with value lager than 32Bit...is why i sugest to modify the detection scheme of the 64Bit on hp-ux with the example have maked before... or if php4 and php5 are not compiled in 64bit environement, to modify oci8/config.m4 like that have sugested (in first) for php 4.4 and 5.0 (the two have the same problem!) for privileging 32bit version of oracle library... i'm testing backport to 4.4 and 5.0 of this modification... with modification of the detecting method of the 64BIT mode... [2005-09-02 08:34:32] [EMAIL PROTECTED] If the way it checks 64bit platform doesn't work for you @ HP-UX and you're able to test it - please provide a patch as we don't have HP-UX anywhere. [2005-09-02 07:19:36] [EMAIL PROTECTED] We start supporting 64bit at PHP 5.1. -------- [2005-09-02 02:18:13] info at ch2o dot info i think that the modification 1.51 (51 branch) of config.m4 of oci8 (in relation i think with bug #29402) while be ok... but i'm not sure that the PHP_CHECK_64BIT (in acinclude.m4) is ok! because "int" and "long int" are 4 bytes in 32bit mode...on hp-ux 64bit (HP-UX 11.11 on PA RISC)...(tested with gcc 32Bit and HP-UX cc in 32bit and 64Bit!) the only way i found to detect 64bit on hp-ux is to test macro __LP64__ (on pa risc, beceause on itanium i thnik is differente..)... ------------ [2005-09-02 01:30:08] info at ch2o dot info Description: all oracle 64Bit version are delivered with 32bit and 64bit client... on hp-ux with Oracle 9i 64Bit, the $ORACLE_HOME/lib have 64bit client library and $ORACLE_HOME/lib32 the 32Bit version... (seem to be the same on AIX, and i think is the same probleme on other 64bit plateforme with oracle 64bit) with Oracle 8i 64bit the $ORACLE_HOME/lin containt 32bit version and $ORACLE_HOME/lib64 the 64Bit version... when you whant compile php + oci8 in 32bit with oracle 8i 64bit have no probleme... but with 9i they dont work beceause the 32bit client lib are in $ORACLE_HOME/lib32 not in $ORACLE_HOME/lib... with the detection schema used in oci8 ext, they cannot compile php + oci8 in 32bit with oracle 9i 64Bit... why i whant to compile php in 32Bit with Oracle 64Bit... on hp-ux there no precompiled version for 64Bit of all opensource needed for compiling php and all the nessary for use php... i think the probleme is the same with the 10g... Reproduce code: --- na Expected result: na Actual result: -- have modified the config.m4 of the oci8... have replace $OCI8_DIR/lib with $OCI8_LIBDIR... and have added at the start of AC_OCI8_VERSION: OCI8_LIBD
#34339 [WFx]: linking probleme oci8 in 32bit with oracle 64bit...
ID: 34339 User updated by: info at ch2o dot info Reported By: info at ch2o dot info Status: Wont fix Bug Type: OCI8 related Operating System: HP-UX PHP Version: 4.4.0 New Comment: i can't test the 64bit completely the 64Bit compile mode on hp-ux, in case i must compile all depandancy of php in 64Bit mode and is very long operation for my little time i have...but i can test the cli compile with hp-ux compiler but with only the included module... i while try it if i have some time in the near future... but in 32bit compile mode on hp-ux 64Bit, with the autodetecting of the good Oracle lib dir (lib or lib32), with the oci8/config.m4 (version 1.51) provided by php5.1 (a good solution) they dont work because the macro PHP_CHECK_64BIT detect that php are compiled in 64Bit not in 32Bit... because "long int" are 4 bit on hp-ux 11.11 on 64Bit hardware in 32bit compiled binary... but the compiler bloc the setting of variable with value lager than 32Bit...is why i sugest to modify the detection scheme of the 64Bit on hp-ux with the example have maked before... or if php4 and php5 are not compiled in 64bit environement, to modify oci8/config.m4 like that have sugested (in first) for php 4.4 and 5.0 (the two have the same problem!) for privileging 32bit version of oracle library... i'm testing backport to 4.4 and 5.0 of this modification... with modification of the detecting method of the 64BIT mode... Previous Comments: [2005-09-02 08:34:32] [EMAIL PROTECTED] If the way it checks 64bit platform doesn't work for you @ HP-UX and you're able to test it - please provide a patch as we don't have HP-UX anywhere. [2005-09-02 07:19:36] [EMAIL PROTECTED] We start supporting 64bit at PHP 5.1. -------- [2005-09-02 02:18:13] info at ch2o dot info i think that the modification 1.51 (51 branch) of config.m4 of oci8 (in relation i think with bug #29402) while be ok... but i'm not sure that the PHP_CHECK_64BIT (in acinclude.m4) is ok! because "int" and "long int" are 4 bytes in 32bit mode...on hp-ux 64bit (HP-UX 11.11 on PA RISC)...(tested with gcc 32Bit and HP-UX cc in 32bit and 64Bit!) the only way i found to detect 64bit on hp-ux is to test macro __LP64__ (on pa risc, beceause on itanium i thnik is differente..)... ------------ [2005-09-02 01:30:08] info at ch2o dot info Description: all oracle 64Bit version are delivered with 32bit and 64bit client... on hp-ux with Oracle 9i 64Bit, the $ORACLE_HOME/lib have 64bit client library and $ORACLE_HOME/lib32 the 32Bit version... (seem to be the same on AIX, and i think is the same probleme on other 64bit plateforme with oracle 64bit) with Oracle 8i 64bit the $ORACLE_HOME/lin containt 32bit version and $ORACLE_HOME/lib64 the 64Bit version... when you whant compile php + oci8 in 32bit with oracle 8i 64bit have no probleme... but with 9i they dont work beceause the 32bit client lib are in $ORACLE_HOME/lib32 not in $ORACLE_HOME/lib... with the detection schema used in oci8 ext, they cannot compile php + oci8 in 32bit with oracle 9i 64Bit... why i whant to compile php in 32Bit with Oracle 64Bit... on hp-ux there no precompiled version for 64Bit of all opensource needed for compiling php and all the nessary for use php... i think the probleme is the same with the 10g... Reproduce code: --- na Expected result: na Actual result: -- have modified the config.m4 of the oci8... have replace $OCI8_DIR/lib with $OCI8_LIBDIR... and have added at the start of AC_OCI8_VERSION: OCI8_LIBDIR=$OCI8_DIR/lib and have added : elif test -f $OCI8_DIR/lib32/libclntsh.$SHLIB_SUFFIX_NAME.9.0; then OCI8_VERSION=9.0 OCI8_LIBDIR=$OCI8_DIR/lib32 before: elif test -f $OCI8_LIBDIR/libclntsh.$SHLIB_SUFFIX_NAME.9.0; then and they worked fine... but with that, they privilege the 32bit version vs the default version (the 64bit version with oracle 9i 64Bit) the seconde posibility is to add --oci8-32bit to force the use of lib32 in place of lib...for use with >=9i 64Bit in 32bit mode... and --oci8-64bit to force the use of lib64 in place of lib for compile with Oracle 8i 64bit in 64Bit mode... -- Edit this bug report at http://bugs.php.net/?id=34339&edit=1
#34339 [Opn]: linking probleme oci8 in 32bit with oracle 64bit...
ID: 34339
User updated by: info at ch2o dot info
Reported By: info at ch2o dot info
Status: Open
Bug Type: OCI8 related
Operating System: HP-UX
PHP Version: 4.4.0
New Comment:
with hp-ux cc (have make bad cut and past!):
>cc -o essai essai.c
cc: "essai.c", line 5: warning 602: Integer constant exceeds its
storage.
Previous Comments:
[2005-09-02 02:26:28] info at ch2o dot info
i found a way to detect 64Bit on hp-ux is to try to set value larger
than 32bit in int variable...
in 64bit they don't make error...
and on 32bit (cc and gcc) they make error:
evroult:/varsoft/delivery/CEGTOOL/src/php5-STABLE-200508291635
[rootmca]> gcc +DD32 -o essai essai.c
gcc: +DD32: No such file or directory
essai.c: In function `main':
essai.c:5: warning: integer constant is too large for "long" type
essai.c:5: warning: overflow in implicit constant conversion
essai.c:4: warning: return type of 'main' is not `int'
evroult:/varsoft/delivery/CEGTOOL/src/php5-STABLE-200508291635
[rootmca]> gcc -o essai essai.c
essai.c: In function `main':
essai.c:5: warning: integer constant is too large for "long" type
essai.c:5: warning: overflow in implicit constant conversion
essai.c:4: warning: return type of 'main' is not `int'
#include
like that:
void main(void)
{
int t=0xf;
#ifdef __LP64__
printf("64bit detected\n");
#endif
}
------------
[2005-09-02 02:18:13] info at ch2o dot info
i think that the modification 1.51 (51 branch) of config.m4 of oci8 (in
relation i think with bug #29402) while be ok...
but i'm not sure that the PHP_CHECK_64BIT (in acinclude.m4) is ok!
because "int" and "long int" are 4 bytes in 32bit mode...on hp-ux 64bit
(HP-UX 11.11 on PA RISC)...(tested with gcc 32Bit and HP-UX cc in 32bit
and 64Bit!)
the only way i found to detect 64bit on hp-ux is to test macro __LP64__
(on pa risc, beceause on itanium i thnik is differente..)...
[2005-09-02 01:30:08] info at ch2o dot info
Description:
all oracle 64Bit version are delivered with 32bit and 64bit client...
on hp-ux with Oracle 9i 64Bit, the $ORACLE_HOME/lib have 64bit client
library and $ORACLE_HOME/lib32 the 32Bit version...
(seem to be the same on AIX, and i think is the same probleme on other
64bit plateforme with oracle 64bit)
with Oracle 8i 64bit the $ORACLE_HOME/lin containt 32bit version and
$ORACLE_HOME/lib64 the 64Bit version...
when you whant compile php + oci8 in 32bit with oracle 8i 64bit have no
probleme...
but with 9i they dont work beceause the 32bit client lib are in
$ORACLE_HOME/lib32 not in $ORACLE_HOME/lib...
with the detection schema used in oci8 ext, they cannot compile php +
oci8 in 32bit with oracle 9i 64Bit...
why i whant to compile php in 32Bit with Oracle 64Bit...
on hp-ux there no precompiled version for 64Bit of all opensource
needed for compiling php and all the nessary for use php...
i think the probleme is the same with the 10g...
Reproduce code:
---
na
Expected result:
na
Actual result:
--
have modified the config.m4 of the oci8...
have replace $OCI8_DIR/lib with $OCI8_LIBDIR...
and have added at the start of AC_OCI8_VERSION:
OCI8_LIBDIR=$OCI8_DIR/lib
and have added :
elif test -f $OCI8_DIR/lib32/libclntsh.$SHLIB_SUFFIX_NAME.9.0; then
OCI8_VERSION=9.0
OCI8_LIBDIR=$OCI8_DIR/lib32
before:
elif test -f $OCI8_LIBDIR/libclntsh.$SHLIB_SUFFIX_NAME.9.0; then
and they worked fine...
but with that, they privilege the 32bit version vs the default version
(the 64bit version with oracle 9i 64Bit)
the seconde posibility is to add --oci8-32bit to force the use of lib32
in place of lib...for use with >=9i 64Bit in 32bit mode...
and --oci8-64bit to force the use of lib64 in place of lib for compile
with Oracle 8i 64bit in 64Bit mode...
--
Edit this bug report at http://bugs.php.net/?id=34339&edit=1
#34339 [Opn]: linking probleme oci8 in 32bit with oracle 64bit...
ID: 34339
User updated by: info at ch2o dot info
Reported By: info at ch2o dot info
Status: Open
Bug Type: OCI8 related
Operating System: HP-UX
PHP Version: 4.4.0
New Comment:
i found a way to detect 64Bit on hp-ux is to try to set value larger
than 32bit in int variable...
in 64bit they don't make error...
and on 32bit (cc and gcc) they make error:
evroult:/varsoft/delivery/CEGTOOL/src/php5-STABLE-200508291635
[rootmca]> gcc +DD32 -o essai essai.c
gcc: +DD32: No such file or directory
essai.c: In function `main':
essai.c:5: warning: integer constant is too large for "long" type
essai.c:5: warning: overflow in implicit constant conversion
essai.c:4: warning: return type of 'main' is not `int'
evroult:/varsoft/delivery/CEGTOOL/src/php5-STABLE-200508291635
[rootmca]> gcc -o essai essai.c
essai.c: In function `main':
essai.c:5: warning: integer constant is too large for "long" type
essai.c:5: warning: overflow in implicit constant conversion
essai.c:4: warning: return type of 'main' is not `int'
#include
like that:
void main(void)
{
int t=0xf;
#ifdef __LP64__
printf("64bit detected\n");
#endif
}
Previous Comments:
------------
[2005-09-02 02:18:13] info at ch2o dot info
i think that the modification 1.51 (51 branch) of config.m4 of oci8 (in
relation i think with bug #29402) while be ok...
but i'm not sure that the PHP_CHECK_64BIT (in acinclude.m4) is ok!
because "int" and "long int" are 4 bytes in 32bit mode...on hp-ux 64bit
(HP-UX 11.11 on PA RISC)...(tested with gcc 32Bit and HP-UX cc in 32bit
and 64Bit!)
the only way i found to detect 64bit on hp-ux is to test macro __LP64__
(on pa risc, beceause on itanium i thnik is differente..)...
--------
[2005-09-02 01:30:08] info at ch2o dot info
Description:
all oracle 64Bit version are delivered with 32bit and 64bit client...
on hp-ux with Oracle 9i 64Bit, the $ORACLE_HOME/lib have 64bit client
library and $ORACLE_HOME/lib32 the 32Bit version...
(seem to be the same on AIX, and i think is the same probleme on other
64bit plateforme with oracle 64bit)
with Oracle 8i 64bit the $ORACLE_HOME/lin containt 32bit version and
$ORACLE_HOME/lib64 the 64Bit version...
when you whant compile php + oci8 in 32bit with oracle 8i 64bit have no
probleme...
but with 9i they dont work beceause the 32bit client lib are in
$ORACLE_HOME/lib32 not in $ORACLE_HOME/lib...
with the detection schema used in oci8 ext, they cannot compile php +
oci8 in 32bit with oracle 9i 64Bit...
why i whant to compile php in 32Bit with Oracle 64Bit...
on hp-ux there no precompiled version for 64Bit of all opensource
needed for compiling php and all the nessary for use php...
i think the probleme is the same with the 10g...
Reproduce code:
---
na
Expected result:
na
Actual result:
--
have modified the config.m4 of the oci8...
have replace $OCI8_DIR/lib with $OCI8_LIBDIR...
and have added at the start of AC_OCI8_VERSION:
OCI8_LIBDIR=$OCI8_DIR/lib
and have added :
elif test -f $OCI8_DIR/lib32/libclntsh.$SHLIB_SUFFIX_NAME.9.0; then
OCI8_VERSION=9.0
OCI8_LIBDIR=$OCI8_DIR/lib32
before:
elif test -f $OCI8_LIBDIR/libclntsh.$SHLIB_SUFFIX_NAME.9.0; then
and they worked fine...
but with that, they privilege the 32bit version vs the default version
(the 64bit version with oracle 9i 64Bit)
the seconde posibility is to add --oci8-32bit to force the use of lib32
in place of lib...for use with >=9i 64Bit in 32bit mode...
and --oci8-64bit to force the use of lib64 in place of lib for compile
with Oracle 8i 64bit in 64Bit mode...
--
Edit this bug report at http://bugs.php.net/?id=34339&edit=1
#34339 [Opn]: linking probleme oci8 in 32bit with oracle 64bit...
ID: 34339 User updated by: info at ch2o dot info Reported By: info at ch2o dot info Status: Open Bug Type: OCI8 related Operating System: HP-UX PHP Version: 4.4.0 New Comment: i think that the modification 1.51 (51 branch) of config.m4 of oci8 (in relation i think with bug #29402) while be ok... but i'm not sure that the PHP_CHECK_64BIT (in acinclude.m4) is ok! because "int" and "long int" are 4 bytes in 32bit mode...on hp-ux 64bit (HP-UX 11.11 on PA RISC)...(tested with gcc 32Bit and HP-UX cc in 32bit and 64Bit!) the only way i found to detect 64bit on hp-ux is to test macro __LP64__ (on pa risc, beceause on itanium i thnik is differente..)... Previous Comments: ---- [2005-09-02 01:30:08] info at ch2o dot info Description: all oracle 64Bit version are delivered with 32bit and 64bit client... on hp-ux with Oracle 9i 64Bit, the $ORACLE_HOME/lib have 64bit client library and $ORACLE_HOME/lib32 the 32Bit version... (seem to be the same on AIX, and i think is the same probleme on other 64bit plateforme with oracle 64bit) with Oracle 8i 64bit the $ORACLE_HOME/lin containt 32bit version and $ORACLE_HOME/lib64 the 64Bit version... when you whant compile php + oci8 in 32bit with oracle 8i 64bit have no probleme... but with 9i they dont work beceause the 32bit client lib are in $ORACLE_HOME/lib32 not in $ORACLE_HOME/lib... with the detection schema used in oci8 ext, they cannot compile php + oci8 in 32bit with oracle 9i 64Bit... why i whant to compile php in 32Bit with Oracle 64Bit... on hp-ux there no precompiled version for 64Bit of all opensource needed for compiling php and all the nessary for use php... i think the probleme is the same with the 10g... Reproduce code: --- na Expected result: na Actual result: -- have modified the config.m4 of the oci8... have replace $OCI8_DIR/lib with $OCI8_LIBDIR... and have added at the start of AC_OCI8_VERSION: OCI8_LIBDIR=$OCI8_DIR/lib and have added : elif test -f $OCI8_DIR/lib32/libclntsh.$SHLIB_SUFFIX_NAME.9.0; then OCI8_VERSION=9.0 OCI8_LIBDIR=$OCI8_DIR/lib32 before: elif test -f $OCI8_LIBDIR/libclntsh.$SHLIB_SUFFIX_NAME.9.0; then and they worked fine... but with that, they privilege the 32bit version vs the default version (the 64bit version with oracle 9i 64Bit) the seconde posibility is to add --oci8-32bit to force the use of lib32 in place of lib...for use with >=9i 64Bit in 32bit mode... and --oci8-64bit to force the use of lib64 in place of lib for compile with Oracle 8i 64bit in 64Bit mode... -- Edit this bug report at http://bugs.php.net/?id=34339&edit=1
#34339 [NEW]: linking probleme oci8 in 32bit with oracle 64bit...
From: info at ch2o dot info Operating system: HP-UX PHP version: 4.4.0 PHP Bug Type: OCI8 related Bug description: linking probleme oci8 in 32bit with oracle 64bit... Description: all oracle 64Bit version are delivered with 32bit and 64bit client... on hp-ux with Oracle 9i 64Bit, the $ORACLE_HOME/lib have 64bit client library and $ORACLE_HOME/lib32 the 32Bit version... (seem to be the same on AIX, and i think is the same probleme on other 64bit plateforme with oracle 64bit) with Oracle 8i 64bit the $ORACLE_HOME/lin containt 32bit version and $ORACLE_HOME/lib64 the 64Bit version... when you whant compile php + oci8 in 32bit with oracle 8i 64bit have no probleme... but with 9i they dont work beceause the 32bit client lib are in $ORACLE_HOME/lib32 not in $ORACLE_HOME/lib... with the detection schema used in oci8 ext, they cannot compile php + oci8 in 32bit with oracle 9i 64Bit... why i whant to compile php in 32Bit with Oracle 64Bit... on hp-ux there no precompiled version for 64Bit of all opensource needed for compiling php and all the nessary for use php... i think the probleme is the same with the 10g... Reproduce code: --- na Expected result: na Actual result: -- have modified the config.m4 of the oci8... have replace $OCI8_DIR/lib with $OCI8_LIBDIR... and have added at the start of AC_OCI8_VERSION: OCI8_LIBDIR=$OCI8_DIR/lib and have added : elif test -f $OCI8_DIR/lib32/libclntsh.$SHLIB_SUFFIX_NAME.9.0; then OCI8_VERSION=9.0 OCI8_LIBDIR=$OCI8_DIR/lib32 before: elif test -f $OCI8_LIBDIR/libclntsh.$SHLIB_SUFFIX_NAME.9.0; then and they worked fine... but with that, they privilege the 32bit version vs the default version (the 64bit version with oracle 9i 64Bit) the seconde posibility is to add --oci8-32bit to force the use of lib32 in place of lib...for use with >=9i 64Bit in 32bit mode... and --oci8-64bit to force the use of lib64 in place of lib for compile with Oracle 8i 64bit in 64Bit mode... -- Edit bug report at http://bugs.php.net/?id=34339&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34339&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34339&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34339&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34339&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34339&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34339&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34339&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34339&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34339&r=support Expected behavior: http://bugs.php.net/fix.php?id=34339&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34339&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34339&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34339&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34339&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34339&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34339&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34339&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34339&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34339&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34339&r=mysqlcfg
#34328 [WFx]: buildconf fail
ID: 34328 User updated by: info at ch2o dot info Reported By: info at ch2o dot info Status: Wont fix Bug Type: Compile Failure Operating System: HP-UX PHP Version: 4CVS-2005-09-01 (snap) New Comment: when use export MAKE=gmake to force use of gnu make they work fine (with autoconf 2.59)... the autoheader warning dont block configure generation... after that configure work fine... i use buildconf to update libtool (the default libtool included in php 4 and 5 have bug for HP-UX) and some config.m4 (oci8 have bug with 9i 64bit with 32bit php build...) and to include extern pecl module directly in ext dir... have added at the begining of the buildconf to check gnu make and tested on hp-ux... : export MAKE MAKE=$(whence make) if test "$($MAKE -version 2>&1 | grep "GNU Make" | wc -l)" -ne 1; then MAKE=$(whence gmake) fi if test "$($MAKE -version 2>&1 | grep "GNU Make" | wc -l)" -ne 1; then echo "ERROR: no gnu make found..." exit -1 fi Previous Comments: ------------ [2005-09-02 00:33:46] info at ch2o dot info autoconf >2.13 worked for other version (4.3.x) that have used??? but the new one is the use of gnu make! and the coolest solution is to detect if "make" (found in path) are gnu make or not, and alternatively try tu use "gmake" in place... in buildconf shell script! like: MAKE=$(whence make) if [ $($MAKE -version | grep "GNU Make" | wc) -ne 1 ]; then MAKE=$(whence gmake) fi if [ $($MAKE -version | grep "GNU Make" | wc) -ne 1 ]; then echo "ERROR: no gnu make found..." exit -1 fi [2005-09-01 16:10:58] [EMAIL PROTECTED] And yes, we only support gnu make too for that.. [2005-09-01 16:10:13] [EMAIL PROTECTED] We only support autoconf 2.13 for generating the configure. If you don't have the correct tools, use snapshots from http://snaps.php.net/ [2005-09-01 15:54:10] info at ch2o dot info Description: when have passed to php4.4 and up from 4.3.x... when execute buildconf on hp-ux without gnu make (named make!) buildconf fail in path... because of use of specifique gnu make macro in build2.mk... on hp-ux precompiled gnu make is named "gmake" and not "make" to differentiate from regulare make... when have analyse buildconf script, have found that i counld export MAKE env with gmake to buildconf work fine : export MAKE=gmake if gmake is the only choice for use buildconf it nessesary to add the possibility to autodetect gnu make in form "gmake" to set automaticly MAKE env vars in buildconf shell script... and detect if "make" are not gnu make to indicate the need of gnu make to use buildconf... Best regards, Mathieu Reproduce code: --- /src/php4-STABLE-200508291446> ./buildconf --force Forcing buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.59 (ok) buildconf: Your version of autoconf likely contains buggy cache code. Running cvsclean for you. To avoid this, install autoconf-2.13 and automake-1.5. Make: Must be a separator on rules line 36. Stop. *** Error exit code 1 Stop. /src/php4-STABLE-200508291446> export MAKE=gmake /src/php4-STABLE-200508291446> ./buildconf --force Forcing buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.59 (ok) buildconf: Your version of autoconf likely contains buggy cache code. Running cvsclean for you. To avoid this, install autoconf-2.13 and automake-1.5. rebuilding configure rebuilding main/php_config.h.in autoheader: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' autoheader: WARNING: and `config.h.top', to define templates for `config.h.in' autoheader: WARNING: is deprecated and discouraged. autoheader: autoheader: WARNING: Using the third argument of `AC_DEFINE' and autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without autoheader: WARNING: `acconfig.h': autoheader: autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1, autoheader: [Define if a function `main' is needed.]) autoheader: autoheader: WARNING: More sophisticated templates can also be produced, see the autoheader: WARNING: documentation. Expected result: Forcing buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.59 (ok) buildconf: Your version of autoconf likely contains buggy cache code. Running cvsclean for you. T
#34328 [WFx]: buildconf fail
ID: 34328 User updated by: info at ch2o dot info Reported By: info at ch2o dot info Status: Wont fix Bug Type: Compile Failure Operating System: HP-UX PHP Version: 4CVS-2005-09-01 (snap) New Comment: autoconf >2.13 worked for other version (4.3.x) that have used??? but the new one is the use of gnu make! and the coolest solution is to detect if "make" (found in path) are gnu make or not, and alternatively try tu use "gmake" in place... in buildconf shell script! like: MAKE=$(whence make) if [ $($MAKE -version | grep "GNU Make" | wc) -ne 1 ]; then MAKE=$(whence gmake) fi if [ $($MAKE -version | grep "GNU Make" | wc) -ne 1 ]; then echo "ERROR: no gnu make found..." exit -1 fi Previous Comments: [2005-09-01 16:10:58] [EMAIL PROTECTED] And yes, we only support gnu make too for that.. [2005-09-01 16:10:13] [EMAIL PROTECTED] We only support autoconf 2.13 for generating the configure. If you don't have the correct tools, use snapshots from http://snaps.php.net/ ------------ [2005-09-01 15:54:10] info at ch2o dot info Description: when have passed to php4.4 and up from 4.3.x... when execute buildconf on hp-ux without gnu make (named make!) buildconf fail in path... because of use of specifique gnu make macro in build2.mk... on hp-ux precompiled gnu make is named "gmake" and not "make" to differentiate from regulare make... when have analyse buildconf script, have found that i counld export MAKE env with gmake to buildconf work fine : export MAKE=gmake if gmake is the only choice for use buildconf it nessesary to add the possibility to autodetect gnu make in form "gmake" to set automaticly MAKE env vars in buildconf shell script... and detect if "make" are not gnu make to indicate the need of gnu make to use buildconf... Best regards, Mathieu Reproduce code: --- /src/php4-STABLE-200508291446> ./buildconf --force Forcing buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.59 (ok) buildconf: Your version of autoconf likely contains buggy cache code. Running cvsclean for you. To avoid this, install autoconf-2.13 and automake-1.5. Make: Must be a separator on rules line 36. Stop. *** Error exit code 1 Stop. /src/php4-STABLE-200508291446> export MAKE=gmake /src/php4-STABLE-200508291446> ./buildconf --force Forcing buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.59 (ok) buildconf: Your version of autoconf likely contains buggy cache code. Running cvsclean for you. To avoid this, install autoconf-2.13 and automake-1.5. rebuilding configure rebuilding main/php_config.h.in autoheader: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' autoheader: WARNING: and `config.h.top', to define templates for `config.h.in' autoheader: WARNING: is deprecated and discouraged. autoheader: autoheader: WARNING: Using the third argument of `AC_DEFINE' and autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without autoheader: WARNING: `acconfig.h': autoheader: autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1, autoheader: [Define if a function `main' is needed.]) autoheader: autoheader: WARNING: More sophisticated templates can also be produced, see the autoheader: WARNING: documentation. Expected result: Forcing buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.59 (ok) buildconf: Your version of autoconf likely contains buggy cache code. Running cvsclean for you. To avoid this, install autoconf-2.13 and automake-1.5. rebuilding configure rebuilding main/php_config.h.in autoheader: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' autoheader: WARNING: and `config.h.top', to define templates for `config.h.in' autoheader: WARNING: is deprecated and discouraged. autoheader: autoheader: WARNING: Using the third argument of `AC_DEFINE' and autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without autoheader: WARNING: `acconfig.h': autoheader: autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1, autoheader: [Define if a function `main' is needed.]) autoheader: autoheader: WARNING: More sophisticated templates can also be produced, see the autoheader: WARNING: documentation. -- Edit this bug report at http://bugs.php.net/?id=34328&edit=1
#34328 [NEW]: buildconf fail
From: info at ch2o dot info Operating system: HP-UX PHP version: 4CVS-2005-09-01 (snap) PHP Bug Type: Compile Failure Bug description: buildconf fail Description: when have passed to php4.4 and up from 4.3.x... when execute buildconf on hp-ux without gnu make (named make!) buildconf fail in path... because of use of specifique gnu make macro in build2.mk... on hp-ux precompiled gnu make is named "gmake" and not "make" to differentiate from regulare make... when have analyse buildconf script, have found that i counld export MAKE env with gmake to buildconf work fine : export MAKE=gmake if gmake is the only choice for use buildconf it nessesary to add the possibility to autodetect gnu make in form "gmake" to set automaticly MAKE env vars in buildconf shell script... and detect if "make" are not gnu make to indicate the need of gnu make to use buildconf... Best regards, Mathieu Reproduce code: --- /src/php4-STABLE-200508291446> ./buildconf --force Forcing buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.59 (ok) buildconf: Your version of autoconf likely contains buggy cache code. Running cvsclean for you. To avoid this, install autoconf-2.13 and automake-1.5. Make: Must be a separator on rules line 36. Stop. *** Error exit code 1 Stop. /src/php4-STABLE-200508291446> export MAKE=gmake /src/php4-STABLE-200508291446> ./buildconf --force Forcing buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.59 (ok) buildconf: Your version of autoconf likely contains buggy cache code. Running cvsclean for you. To avoid this, install autoconf-2.13 and automake-1.5. rebuilding configure rebuilding main/php_config.h.in autoheader: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' autoheader: WARNING: and `config.h.top', to define templates for `config.h.in' autoheader: WARNING: is deprecated and discouraged. autoheader: autoheader: WARNING: Using the third argument of `AC_DEFINE' and autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without autoheader: WARNING: `acconfig.h': autoheader: autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1, autoheader: [Define if a function `main' is needed.]) autoheader: autoheader: WARNING: More sophisticated templates can also be produced, see the autoheader: WARNING: documentation. Expected result: Forcing buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.59 (ok) buildconf: Your version of autoconf likely contains buggy cache code. Running cvsclean for you. To avoid this, install autoconf-2.13 and automake-1.5. rebuilding configure rebuilding main/php_config.h.in autoheader: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' autoheader: WARNING: and `config.h.top', to define templates for `config.h.in' autoheader: WARNING: is deprecated and discouraged. autoheader: autoheader: WARNING: Using the third argument of `AC_DEFINE' and autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without autoheader: WARNING: `acconfig.h': autoheader: autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1, autoheader: [Define if a function `main' is needed.]) autoheader: autoheader: WARNING: More sophisticated templates can also be produced, see the autoheader: WARNING: documentation. -- Edit bug report at http://bugs.php.net/?id=34328&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34328&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34328&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34328&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34328&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34328&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34328&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34328&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34328&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34328&r=support Expected behavior: http://bugs.php.net/fix.php?id=34328&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34328&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34328&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34328&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34328&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34328&r=dst IIS Stability:
#32417 [Bgs]: zlib compression pb, dont send gzip header...
ID: 32417 User updated by: info at ch2o dot info Reported By: info at ch2o dot info Status: Bogus Bug Type: Zlib Related Operating System: HP-UX PHP Version: 4.3.10 New Comment: all similare probleme have seen (including #32283) don't resolv my probleme, all other use mod_php sapi and not fastcgi... i think the probleme is similar but the resolution has not been apply for fastcgi sapi... Previous Comments: [2005-03-23 23:42:58] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. [2005-03-22 22:40:33] info at ch2o dot info Description: i have similare probleme than #32283... i use lighttpd and fastcgi... when activate zlib compression they dont flush gzip header... the browser (mozilla and ie...) not receve the gzip header... when i force by the php function header they work fine... Reproduce code: --- Expected result: phpinfo result Actual result: -- , but receve gzip binary! -- Edit this bug report at http://bugs.php.net/?id=32417&edit=1
#32417 [NEW]: zlib compression pb, dont send gzip header...
From: info at ch2o dot info Operating system: HP-UX PHP version: 4.3.10 PHP Bug Type: Zlib Related Bug description: zlib compression pb, dont send gzip header... Description: i have similare probleme than #32283... i use lighttpd and fastcgi... when activate zlib compression they dont flush gzip header... the browser (mozilla and ie...) not receve the gzip header... when i force by the php function header they work fine... Reproduce code: --- Expected result: phpinfo result Actual result: -- , but receve gzip binary! -- Edit bug report at http://bugs.php.net/?id=32417&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32417&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32417&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32417&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32417&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32417&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32417&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32417&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32417&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32417&r=support Expected behavior: http://bugs.php.net/fix.php?id=32417&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32417&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32417&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32417&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32417&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32417&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32417&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32417&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32417&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32417&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32417&r=mysqlcfg
