Does it work if you run the script on command line?
What do you mean with "I try to start up a PHP script from
a C coded binary CGY by the C system() functi?n" ???

How did you configure PHP for Apache in httpd.conf ??

First of all thanks for your request.

The PHP script seems to work fine from de unix command line:

About the C coded CGI: The webserver starts up a normal CGI programmed in C. This CGY starts up the PHP script as it was from the command line, by using the C system() function as followed:
system("/disco1/php/test.php");

About apache: For this tests I used the netscape webserver because of some other problems I have using apache with this same configuration and reported as bug: 27540

Please close the other report, the issue is same.
And provide the backtrace of the crash here.

The problem I have with bug: 27540 is PHP versi?n independend and only with apache. If you prefer hendling thes both bugs under this reference, I will close the other one. 

Refering your request, please tell me exaclty with backtrace you mean, I don?t know PHP to much and need some help. If you refer to the coredump I see on the browser, its a lot of informati?n and seems to refer to a lot of memory data not only PHP.

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

I made the changes in php.ini for the backtrace generation as commented in "bugs-generating-backtrace.php", however there is nothing changed refering the behaviour of the apache/php execution as commented initially in bug: 27540.
This erroneous result doesn't create a core on my solaris file system so it is impossible for me to generate the backtrace file you asked for. In sted of generating the core file on the file system, the PHP shell execution from the CGI, sends the coredump information directly to the browser. Is there someting else I can do in order to give you the necesary information?

After looking for posible solutions in internet I tried some posible solutions for example compiling de PHP software without the options --enable-discard-path and --enable-force-cgi-redirect. The new situation seems to be more suitable, I can?t reproduce de coredump on the browser and the behavier seems to be the same executing the PHP script through IPlanet and Apache, in both cases with the same result on the browser "No input file specified.".

This is some misconfiguration of your webserver / php. Using latest PHP release on a properly configured server I can not reproduce this.

Normally we compile PHP with: configure --prefix=/usr/local/php4.3.4 --with-oracle=/disco1/oracle/8.0.4 --with-oci8=/disco1/oracle/8.0.4 --enable-discard-path  --enable-sockets but compiling version 4.3.4 with the same options it doesn?t works, always returning ?No input file specified? in the web browser. The ?--enable-discard-path? option, generates a core output using apache, without this option the result (?No input file specified?) is the same for apache and IPlanet.

Ok, it?s through, there can be a wrong configuration between the web server and my PHP version 4.3.4 (the latest version as I know), but the strange thing about this is that it happens with both web servers (apache and IPlanet). With previous version of PHP (4.0.4 and before) it works fine with the same web server configuration of IPlanet. All of these previous versions with the same configuration give core output problems with apache.

Comparing the configuration options the version 4.3.4 has more options than the 4.0.4 version, and it is almost impossible to understand and try them all in order to get the same functionality of the 4.0.4 for IPlanet and apache, perhaps some configuration tips form your site can help us to resolve this problem, or even if you tell me witch kind of input file the PHP shell is expecting in order to understand better the behavior of PHP 4.3.4.

Latest release is 4.3.5 (but wait for 4.3.6 before updating!).
Please ask further support questions on the mailing lists.