Bug #61345 [Com]: CGI mode - make install don't work

2012-06-16 Thread streaky at mybrokenlogic dot com
Edit report at https://bugs.php.net/bug.php?id=61345&edit=1

 ID: 61345
 Comment by: streaky at mybrokenlogic dot com
 Reported by:sites at evoluons dot net
 Summary:CGI mode - make install don't work
 Status: Assigned
 Type:   Bug
 Package:Compile Failure
 Operating System:   Fedora 16 x86_64
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

Same problem with 5.4.4 on Debian - seems that if you --disable-cli and cgi is 
enabled *and* your EPREFIX/bin isn't already created - then `make install` 
doesn't create them.

If you mkdir EPREFIX/bin those directories then `make install` it all works 
fine - it even creates EPREFIX/include, EPREFIX/lib et al - it's just the bin 
that it seems to miss. To confirm I checked and created EPREFIX before make 
install - and it still falls over EPREFIX/bin.

This used to work fine with 5.3 builds, it is switching to 5.4.4 on a test 
server 'breaks' my build scripts.


Previous Comments:

[2012-04-26 17:15:26] lzsiga at freemail dot c3 dot hu

Try to execute this command manually

touch /usr/local/phpcgi/bin/#INST@1706#

if you get an error-message, please paste it in here.


[2012-04-25 20:55:50] kuteninja at gmail dot com

I have this same issue, creating php/bin directory make install works, without 
it it doesn't work.

I'm running CentOS 6 x86_64 (so it should be equal in RHEL6 too)

This is my configure:

./configure  --prefix=/usr/local/php --with-layout=GNU --with-config-file-
path=/usr/local/php --disable-all --enable-libxml --with-libxml-dir=/usr/local -
-with-regex=php --enable-cgi --disable-cli --enable-inline-optimization --with-
pcre-regex --enable-json


Only by making the /usr/local/php/bin directory manually I'm able to "make 
install" it.


[2012-03-23 06:32:08] sites at evoluons dot net

I apologize : it's with another computer it was OK.

I updated mine too, and it keep same error.

I tried today with a new ./configure command :

./configure --with-apxs2=/usr/local/apache/bin/apxs 
--with-config-file-path=/usr/local/apache/conf --with-gd --with-zlib --with-bz2 
--enable-ftp --enable-sockets --with-curl --with-mysql=/usr/local/mysql 
--with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd --with-imap --enable-mbstring 
--enable-exif --without-pear --enable-zip --prefix=/usr/local/php --with-mcrypt 
--with-jpeg-dir --with-png-dir --with-freetype-dir --enable-gd-native-ttf 
--with-kerberos --with-imap-ssl

Same problem :
make install
Installing PHP CGI binary:/usr/local/phpcgi/bin/
cp: cannot create regular file `/usr/local/phpcgi/bin/#INST@1706#': No such 
file or directory

And if I create folders myself :
mkdir /usr/local/phpcgi
mkdir /usr/local/phpcgi/bin

It's ok :
make install
Installing PHP CGI binary:/usr/local/phpcgi/bin/
Installing build environment: /usr/local/phpcgi/lib/php/build/
Installing header files:  /usr/local/phpcgi/include/php/
Installing helper programs:   /usr/local/phpcgi/bin/
  program: phpize
  program: php-config
Installing man pages: /usr/local/phpcgi/php/man/man1/
  page: phpize.1
  page: php-config.1
Installing PDO headers:  /usr/local/phpcgi/include/php/ext/pdo/


[2012-03-22 08:30:35] sites at evoluons dot net

I updated my Fedora 16 x86_64 and now it works directly, without any workaround.

So, I close the bug.


[2012-03-10 20:40:18] sites at evoluons dot net

Description:

Hi,

With a Fedora 16 x86_64 I compiled PHP in Apache module mode, no problem.

But, to use also CGI mode, compilation is OK, but "make install" not.

My ./configure :

./configure --with-gd --with-zlib --enable-ftp --enable-sockets --with-curl 
--enable-mbstring --enable-exif --enable-zip --prefix=/usr/local/phpcgi 
--disable-cli --with-mysql=/usr/local/mysql --with-jpeg-dir --with-png-dir 
--with-freetype-dir --enable-gd-native-ttf --with-mcrypt

make install
Installing PHP CGI binary:/usr/local/phpcgi/bin/
cp: cannot create regular file `/usr/local/phpcgi/bin/#INST@1199#': No such 
file or directory

Expected result:

Installing PHP CGI binary:/usr/local/phpcgi/bin/
Installing build environment: /usr/local/phpcgi/lib/php/build/
Installing header files:  /usr/local/phpcgi/include/php/
Installing helper programs:   /usr/local/phpcgi/bin/
  program: phpize
  program: php-config
Installing man pages: /usr/local/phpcgi/php/man/man1/
  page: phpize.1
  page: php-config

Req #62509 [Com]: chroot() is disabled with ZTS enabled

2012-07-09 Thread streaky at mybrokenlogic dot com
Edit report at https://bugs.php.net/bug.php?id=62509&edit=1

 ID: 62509
 Comment by: streaky at mybrokenlogic dot com
 Reported by:streaky at mkybrokenlogic dot com
 Summary:chroot() is disabled with ZTS enabled
 Status: Not a bug
 Type:   Feature/Change Request
 Package:Directory function related
 Operating System:   Anything but windows?
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

There are situations where you need to regardless - for example runkit needs 
ZTS - if you need runkit and chroot() currently you can't do it without the 
aforementioned hack. Besides this *is* a threaded context.

There's no good thread safety reason why chroot() would be disabled besides the 
"it's hard to get it to configure like that" is there? I'm okay with the way it 
is just in principle it seems wrong to me - personally I can do it in a patch...


Previous Comments:

[2012-07-09 05:29:27] larue...@php.net

maybe we can always return false in ZTS build, and trigger a warning.


[2012-07-08 21:02:35] johan...@php.net

You shouldn't use ZTS binaries in non-threaded context. They need more memory, 
they are slower, they are harder to debug in case of critical errors.

That aside: We have no good mechanism to disable it easily in one context only.


[2012-07-08 17:00:46] streaky at mkybrokenlogic dot com

Description:

chroot() seems to be arbitrarily disabled with ZTS enabled. It seems like it is 
disabled because when ZTS is -usually- used it is with a sapi that requires 
thread safety but this isn't always the case.

AFAIK there isn't a good reason for it, I assume it's some sort of oversight - 
a cheap and cheerful way to achieve the above, but it doesn't account for all 
circumstances so you have to go hacking on the source code in about 3 different 
places.

It probably should be as is *except* for if CLI and possibly CGI is the SAPI.

Test script:
---
https://bugs.php.net/bug.php?id=62509&edit=1


#43252 [Com]: The windows installer is corrupt.

2007-11-11 Thread streaky at mybrokenlogic dot com
 ID:   43252
 Comment by:   streaky at mybrokenlogic dot com
 Reported By:  s8 dot stunna at gmail dot com
 Status:   Open
 Bug Type: *General Issues
 Operating System: Windows 2000 server
 PHP Version:  5.2.5
 New Comment:

Confirmed here, also #43255 seems to be a dupe of this bug.


Previous Comments:


[2007-11-11 23:06:18] s8 dot stunna at gmail dot com

Description:

I am using the windows installer file. After it prompts me for the
destination it gives me a pop up saying that the installer is corrupt. 

"The installer has encountered and unexpected error installing this
package. This may indicate a problem with this package. Error code is
2878"

I have tried from all of your mirrors and on multiple machines at my
disposal. Let me know whats up

Thanks for your time






-- 
Edit this bug report at http://bugs.php.net/?id=43252&edit=1