Am trying to install oci8 on mac os Monterey but i keep getting the following error. I have already set php path on the .zshrc and am able to see the correct php version when i run php -v and also the correct path when i run which php
Am running php 7.4.20
I have Xcode installed
checking for Oracle Database OCI8 support... yes, shared
checking PHP version... Unknown option: n
Usage: head [-options] <url>...
-m <method> use method for the request (default is 'HEAD')
-f make request even if head believes method is illegal
-b <base> Use the specified URL as base
-t <timeout> Set timeout value
-i <time> Set the If-Modified-Since header on the request
-c <conttype> use this content-type for POST, PUT, CHECKIN
-a Use text mode for content I/O
-p <proxyurl> use this as a proxy
-P don't load proxy settings from environment
-H <header> send this HTTP header (you can specify several)
-u Display method and URL before any response
-U Display request headers (implies -u)
-s Display response status code
-S Display response status chain
-e Display response headers
-d Do not display content
-o <format> Process HTML content in various ways
-v Show program version
-h Print this message
-x Extra debugging output
configure: error: failed to detect PHP version, please report
ERROR: `/private/tmp/pear/install/oci8/configure --with-php-config=/Applications/XAMPP/xamppfiles/bin/php-config --with-oci8=instantclient,/Applications/XAMPP/xamppfiles/lib/oracle/instantclient_19_8/' failed
I am trying to install composer through php, as described in their wesite.
php -r "readfile('https://getcomposer.org/installer');" | php
But it is displaying the following error:
$ php -r "readfile('https://getcomposer.org/installer');" | php
output is not a tty
input is not a tty
I am in windows 7 and using git bash to execute this command. At windows command prompt, it is working fine. This problem is only occur when I run this command from git bash 2.6.2-64bit.
BTW, I have installed composer for windows, and that is working fine. But I can not download composer.phar in this way. How can I fix this issue?
It can be a PATH or an encoding issue:
issue 25 mentions:
it seems that git ls-remote origin, run from a freshly-built and installed MinGW Git fails to be able to output anything, and git ls-remote origin | cat (a trick learned from working with old MSys'/MinGW's quirks) only says: output is not a tty (the exit code is 127, suggesting that some executable was not found, but it is very difficult to say which one because not even debug print statements to stderr are shown; It seems that in case of a crash or of a die(), stderr is not flushed)
issue 519 even suggests to unalias winpty
unalias $(alias | grep winpty | cut -d"=" -f1 | cut -d" " -f2)
But:
No, we cannot simply abandon winpty. PHP can be run interactively, i.e. it requires a proper Win32 Console. Running PHP without winpty in MinTTY would not provide that Console instance, leaving you with a seemingly unresponsive terminal.
See git-for-windows/build-extra#44ed99b, #399 and #400 to understand what havoc you would wreak by simply removing those aliases.
So right now, the bash console is not compatible with executing php through pipe (as the second | php might not benefit from winpty, which seems needed when a program requires a Win32 Console for interactive usage).
Peh points out in the comments:
If you use C:`Program Files\Git\bin\bash.exeinstead ofC:\Program Files\Git\git-bash.exe`, then the command works fine.
I'm using it in combination with ConsoleZ without any problems
That probably is because bash.exe does not use winpty, contrary to git-bash.exe.
VonC's answer is correct, and to help others in the future I want to provide a more visual solution.
Navigate to C:\Program Files\Git\bin
Double-click on bash.exe
You should now see a command prompt.
Navigate to your PHP project directory and install Composer.
$ cd C:\path\to\your\project
$ curl -sS https://getcomposer.org/installer | php
$ ls
The file composer.phar is now visible in project root.
Install a package with composer.
$ php composer.phar require some-package-you-want-to-install
Can output by using bash: C:\Program Files\Git\bin\bash.exe
When running composer diagnose, I get the following error :
The xdebug extension is loaded, this can slow down Composer a little.
Disabling it when using Composer is recommended.
How can I disable xdebug only when I'm running Composer?
Update: For Xdebug 3+:
As of Xdebug 3, it is possible to disable the Xdebug completely by setting the option xdebug.mode to off, or by setting the environment variable XDEBUG_MODE=off.
It is very easy to disable Xdebug just for composer, by aliasing composer.
alias composer='XDEBUG_MODE=off \composer'
OR
alias composer='php -dxdebug.mode=off $(where composer | fgrep -v composer: | head -1)'
You can add the alias to your $HOME/.bashrc to make it permanent.
Update: For Xdebug 1.3 - 3.0.0 :
The issue has been fixed in Composer 1.3. Update composer to the latest version by executing composer self-update, instead of trying the following workaround.
For Xdebug < 1.3
Here is my modification of #ezzatron's code. I have updated the script to detect ini files from phpinfo output.
#!/bin/sh
php_no_xdebug () {
temporaryPath="$(mktemp -t php.XXXX).ini"
# Using awk to ensure that files ending without newlines do not lead to configuration error
php -i | grep "\.ini" | grep -o -e '\(/[a-z0-9._-]\+\)\+\.ini' | grep -v xdebug | xargs awk 'FNR==1{print ""}1' | grep -v xdebug > "$temporaryPath"
php -n -c "$temporaryPath" "$#"
rm -f "$temporaryPath"
}
php_no_xdebug /usr/local/bin/composer.phar $#
# On MacOS with composer installed using brew, comment previous line
# Install jq by executing `brew install jq` and uncomment following line.
# php_no_xdebug /usr/local/Cellar/composer/`brew info --json=v1 composer | jq -r '.[0].installed[0].version'`/libexec/composer.phar $#
This command will disable the PHP5 Xdebug module for CLI (and thus composer) :
sudo php5dismod -s cli xdebug
It removes the xdebug.ini symlink from /etc/php5/cli/conf.d/
This was suggested on http://blog.lorenzbausch.de/2015/02/10/php-disable-xdebug-for-cli/
Note that for Ubuntu 16.04 you probably need to run it like this:
sudo phpdismod -s cli xdebug
I don’t think there is an option to configure PHP so it can load different configurations according to the targeted script. At least, not without duplicating .ini files...
However, you can add thoses options when running composer with php:
php -n -d extension=needed_ext.so composer.phar
-n will tell PHP to ignore any php.ini. This will prevent xdebug from loading for this very command.
-d options permits you to add any option you want (for exemple, activate needed_ext.so). You can use multiple -d options. Of course, this is optional, you might not need it.
Then you can create an alias, to make it sugary again.
A typical solution (because composer needs json):
php -n -d extension=json.so composer.phar
greg0ire > my solution, based on that:
#!/bin/bash
options=$(ls -1 /usr/lib64/php/modules| \
grep --invert-match xdebug| \
# remove problematic extensions
egrep --invert-match 'mysql|wddx|pgsql'| \
sed --expression 's/\(.*\)/ --define extension=\1/'| \
# join everything together back in one big line
tr --delete '\n'
)
# build the final command line
php --no-php-ini $options ~/bin/composer $*
alias composer=/path/to/bash/script.sh
It looks ugly (I tried and failed to do that with xargs), but works… I had to disable some extensions though, otherwise I get the following warnings:
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/mysqli.so' - /usr/lib64/php/modules/mysqli.so: undefined symbol: mysqlnd_connect in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/pdo_mysql.so' - /usr/lib64/php/modules/pdo_mysql.so: undefined symbol: pdo_parse_params in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/pdo_pgsql.so' - /usr/lib64/php/modules/pdo_pgsql.so: undefined symbol: pdo_parse_params in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/wddx.so' - /usr/lib64/php/modules/wddx.so: undefined symbol: php_XML_SetUserData in Unknown on line 0
You can disable Xdebug setting an environment variable:
XDEBUG_MODE=off composer install
It's available using XDebug 3.
By creating an alias you'll suppress that composer xdebug error message.
Just add this line to your ~/.bash_aliases within your system and it should work flawlessly.
alias composer="php -n /usr/local/bin/composer"
Reload the shell to make the new alias composer available.
source ~/.bash_profile
USAGE:
$ composer --version
NOTE:
You don't necessarily need to use any other parameter.
Depending on your system you might have a .bashrc instead of .bash_profile.
UPDATE:
As #AlexanderKachkaev mention in the comments it's worth nothing to add the memory_limit as follows to avoid crashing im some situations:
alias composer="php -d memory_limit=-1 -n /usr/local/bin/composer"
I came up with an answer that works pretty well for OSX, and could probably be adapted for any PHP version that loads its extensions using individual .ini files in the "additional ini dir":
#!/bin/sh
function php-no-xdebug {
local temporaryPath="$(mktemp -t php-no-debug)"
find /opt/local/etc/$1/php.ini /opt/local/var/db/$1/*.ini ! -name xdebug.ini | xargs cat > "$temporaryPath"
php -n -c "$temporaryPath" "${#:2}"
rm -f "$temporaryPath"
}
alias composer="php-no-xdebug php56 ~/bin/composer"
I usually create a shell script per project, since every project has another PHP version. It's in a /bin/ directory next to composer.phar and composer.json and I run it as ./bin/composer in my project directory.
It looks like this (for php56)
#!/bin/sh
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
COMPOSER_DISABLE_XDEBUG_WARN=1 /opt/local/bin/php56 \
-d xdebug.remote_enable=0 -d xdebug.profiler_enable=0 \
-d xdebug.default_enable=0 $DIR/../composer.phar "$#"
The -d options effectively disable xdebug. The COMPOSER_DISABLE_XDEBUG_WARN=1 part disables the warning composer issues.
Disabling the xdebug extension is preferred (see composer troubleshooting), but I personally like the simpler script.
Some timings on my machine:
2
Run with xdebug and ini-enabled: 1m33
Run with xdebug but ini-disabled: 0m19
Run without xdebug: 0m10
If you use PHPStorm, the latest release (2016.2) comes with a feature to enable XDebug for CLI scripts on-demand, which means you can simply turn off XDebug globally on your development machine. The IDE will enable it on the fly when it is needed by code inside your projects.
https://blog.jetbrains.com/phpstorm/2016/06/xdebug-on-demand-for-cli-php-scripts-in-phpstorm-2016-2-eap/
PhpStorm 2016.2 introduces Xdebug On Demand mode where you can disable Xdebug for your global PHP install, and PhpStorm will only enable it when it needs to — when you’re debugging your scripts, or when you need code coverage reports.
You need to edit your PHP Interpreters preferences to include the path to XDebug, as described in the linked article.
To me this seems like the perfect solution, as I only usually want XDebug while I'm in the IDE.
However XDebug does have other potential uses when you are "offline" e.g. extended stack dumps in error logs, which you would lose by turning it off globally. Of course you shouldn't have XDebug enabled on production, so this would be limited to use cases like beta-testing or automated-testing CLI scripts in development.
Rather than muddle with temporarily enabling or disabling the PHP module, when you might have concurrent processes using PHP (for example as part of a CI pipeline), you can tell PHP to point at a different module loading directory.
While this is similar to some of the solutions mentioned above, this solves a few edge cases, which is very useful when being used by Jenkins or other CI runner which runs tests on the same machine concurrently.
The easiest way to do this is to use the environment variable PHP_INI_SCAN_DIR
Using this in a script or build task is easy:
export PHP_INI_SCAN_DIR=/etc/php.d.noxdebug
php composer install
Of course you would want to prepare /etc/php.d.noxdebug first, doing something like:
mkdir /etc/php.d.noxdebug
cp /etc/php.d/* /etc/php.d.noxdebug
rm /etc/php.d.noxdebug/xdebug.ini
This means you have an environment similar to the old php environment, with only one module missing. Meaning you don't need to worry about needing to load the phar/json modules as you would with the php -n solution.
Direct manipulation of PHP config
Here's my contribution based on a Homebrew-installed PHP installation on Mac OS X.
It's a shell-script wrapper, designed to be saved as an executable file at /usr/local/bin/composer, with the Composer binary at /usr/local/bin/composer.phar:
#!/bin/sh
sed -i '' -e 's:zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":;zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":' /usr/local/etc/php/5.5/conf.d/ext-xdebug.ini
/usr/local/bin/php /usr/local/bin/composer.phar "$#"
sed -i '' -e 's:;zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":' /usr/local/etc/php/5.5/conf.d/ext-xdebug.ini
Theory of Operation
The wrapper script:
uses sed to temporarily modify the configuration file, disabling Xdebug (line 2)
executes Composer, passing through args to the command (line 3)
uses sed to restore the configuration file, re-enabling Xdebug (line 4)
The script is coupled to an OS X/Homebrew installation of PHP 5.5. The paths should be adjusted to work with other PHP versions and other operating systems' and package managers' directory layouts. Note also that some versions of sed do not need the empty-string argument following the -i option.
Caveat Utilitor
The script is straightforward, in that it works directly on the main PHP configuration files, however this is also a drawback: Xdebug will also be disabled for any scripts that happen to be executed concurrently with this script.
In my development environment, this is an acceptable trade-off, given that Composer is executed manually and only occasionally; however you may not want to use this technique if executing Composer as part of an automated deployment process.
I came up with a solution for the Windows-based Composer installer - it should work for any Composer installation, it just basically makes a copy of the loaded INI file and comments out the xdebug zend extension, then loads that configuration file when it runs composer.
I've opened an issue to see if they'd like to integrate this change:
https://github.com/composer/windows-setup/issues/58
You can find my instructions and code there.
As noted in Joyce's answer, this issue no longer exists in the latest version of Composer.
The Composer documentation has been updated to note this. It details how you can enable xdebug with Composer (if required).
You can update your version of Composer by utilising self-update.
On my Mac I had to do: sudo php /opt/local/bin/composer self-update
Further details about this in the context of a Homebrew PHP install can be found in this issue.
Creating an alias for composer to disable xdebug and prevent memory errors:
Add this line to your ~/.bash_profile
alias composer='php -d xdebug.profiler_enable=0 -d memory_limit=-1 /usr/local/bin/composer'
Restart the terminal to make the new alias available.
In most cases you do not need xdebug on CLI mode. If this is acceptable for you than you can configure cli and cgi differently.
So if you make php-cli.ini and conf-cli.d near exiting php.ini file than you can configure cli and cgi differently (for cgi it would be php.ini and conf.d). Just do not put xdebug.ini into conf-cli.d.
If you install composer using brew on OS X
You can use this alias:
alias composer="php -n $(cat $(which composer) | grep composer.phar | awk '{print $7}')"
My quick solution for a macports installation, with multiple versions of PHP was to write this simple shell wrapper for Composer:
/user/local/bin/composer-nodebug.sh
#!/bin/bash
sudo mv /opt/local/var/db/php53/xdebug.ini /opt/local/var/db/php53/xdebug.NOT
sudo mv /opt/local/var/db/php54/xdebug.ini /opt/local/var/db/php54/xdebug.NOT
sudo mv /opt/local/var/db/php55/xdebug.ini /opt/local/var/db/php55/xdebug.NOT
composer $1 $2 $3 $4 $5 $6 $7
sudo mv /opt/local/var/db/php53/xdebug.NOT /opt/local/var/db/php53/xdebug.ini
sudo mv /opt/local/var/db/php54/xdebug.NOT /opt/local/var/db/php54/xdebug.ini
sudo mv /opt/local/var/db/php55/xdebug.NOT /opt/local/var/db/php55/xdebug.ini
Then run any composer commands like so:
sudo composer-nodebug.sh update
Drawbacks:
requires sudo (unless you chmod the INI files)
if you kill it mid-way the INI files are modified
will require future PHP versions added.
while it's running other PHP processes are affected
Not elegant, but simple.
(Windows)
Based on documentation I use environment variable PHPRC, so I can choose which INI file shloud be loaded, thus I can choose whether I want to enable or disable Xdebug before executing a command (like composer install).
I have two INI files, one with Xdebug enabled (php-xdebug.ini) and one with Xdebug disabled (php.ini - it's also default one).
I use some batches (placed in location which is included in PATH environment variable, so it can be executed from anywhere):
To enable Xdebug I call xon.bat:
#ECHO OFF
set PHPRC=C:/path-to-php/php-xdebug.ini
To disable Xdebug I call xoff.bat:
#ECHO OFF
set PHPRC=
By calling php --ini I can check which INI file was loaded.
Alternatively you can use environment variable PHP_INI_SCAN_DIR in which you set a path to directory from where additional INI files will be loaded. Advantage is that you can load multiple INI files.
Here is my quick solution to get rid off the Xdebug warning on PHP5-cli version. I have removed the support of Xdebug for PHP5-cli on Ubuntu 14.04.
cd /etc/php5/cli/conf.d/
sudo rm 20-xdebug.ini
Now no more Xdebug warning on PHP5-cli.
I try to use exec function in PHP to compile a source file with gcc with the following code.
<?php
exec("gcc -o hello hello.c 2>&1", $output, $return_value);
echo $output[0];
I got the following output when calling via web browser (I use nginx as a web server).
gcc: error trying to exec 'cc1': execvp: No such file or directory
However, if I run gcc -o hello hello.c on the command shell directly or call with php my_file.php on the shell directly, both ways compile successfully.
If I append the absolute path to gcc in my PHP code like this:
<?php
exec("/usr/bin/gcc -o hello hello.c 2>&1", $output, $return_value);
echo $output[0];
I got the following output.
collect2: fatal error: cannot find 'ld'
So, I think the problem is my webserver (nginx) doesn't know the system path environment variable to find /usr/bin which gcc and other gcc-dependencies resides in.
How can I let PHP exec function recognize system environment variables on nginx?
OS: Ubuntu 14.04
nginx: 1.6.2
PHP 5.5.9
I'm stuck on the same problem (exactly the same...) using nginx 1.10 and PHP 5.6 on Arch Linux.
The same PHP code was working on Apache/Debian.
When trying the Arch/Nginx server, I had the cc1 error... I replaced gcc by /usr/bin/gcc.... and I am now stuck on "collect2: fatal error: cannot find 'ld'"
The same compilation works with a shell... and ld is in /usr/bin. It just does not work when using "exec" in PHP.
Not satisfying (but working...) solution
By running gcc -v .....(just add -v to your compilation line) I could see :
...
COLLECT_GCC_OPTIONS='-v' '-D' 'exit=noexit' '-D' '_exit=noexit' ...
/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/collect2 -plugin ... (<= very long line)
collect2: fatal error: cannot find 'ld'
Then I did :
cd /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/ # <- path to collect2 (see above)
ln -s /usr/bin/ld ld
Now ld prog is available in the same dir as collect2.
And it works.
I am now looking for a better solution... :)
Set the PATH variable for PHP, as it may rely on its own environment variables and ignore the system's PATH variable.
For example, I have the following line at the bottom of my .env file:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
With this, executing gcc (without giving the full path /usr/bin/gcc) works correctly.
Duplicate of How compile GCC from php. Thought I'd post the answer here as well, since this question received a lot more attention than the other one.
I'm compiling PHP-CPP source but i getting error in Windows 7.But, in Linux (for .so extension) it works fine. The error given by the compiler is:
collect2.exe [Error] ld returned 1 exit status
Note: I'm using PHP-CPP not PHP source code directly...
Error: mkdir -p shared/common The syntax of the command is incorrect.
Makefile:190: recipe for target 'shared_directories' failed
mingw32-make: *** [shared_directories] Error 1
PHP-CPP (i'm using)
Error Image
So, you are using MinGW (mingw32-make) in a cmd.exe hosted environment; cmd.exe's mkdir (md) command doesn't offer a -p option, AFAIK. Your makefile appears to expect a POSIX shell hosted environment, so you may have better luck with such, (e.g. the bash shell furnished by MinGW.org's MSYS, or by Cygwin).
You have to download the newest release of phpcpp - then make a build with cmake (just use the cmake gui for windows) - here it's important to set the follwoing entries for build:
PHPCPP_ARCH with "x86_64" and
PHPCPP_PHP_PATH to the path where your root dir of the php source is ...
if you want to build for static libs - set this:
PHPCPP_MSVCRT_STATIC
if you want to have a dynamic build just don't set this Entry ...
Now just click on "Configure" - when its completed just hit "Generate" ..
if all works fine you can now click on "Open Project" and usualy now Visual Studio will load the data needed for compiling ...
Now just compile and now you can use .lib / .dll for further implementations ...