I just want to do phpunit --coveragefor my project first I got this error:
PHPUnit 9.5.0 by Sebastian Bergmann and contributors.
Warning: No code coverage driver available
I just check my php to make sure I have xdebug via php -v
PHP 8.0.0 (cli) (built: Nov 30 2020 13:51:52) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.0-dev, Copyright (c) Zend Technologies
with Zend OPcache v8.0.0, Copyright (c), by Zend Technologies
seems I do not have it then I just install it via pecl install xdebug Homebrew I got this error at the end of installation:
........
Build process completed successfully
Installing '/usr/local/Cellar/php/8.0.0_1/pecl/20200930/xdebug.so'
Warning: mkdir(): File exists in System.php on line 294
Warning: mkdir(): File exists in /usr/local/Cellar/php/8.0.0_1/share/php/pear/System.php on line 294
ERROR: failed to mkdir /usr/local/Cellar/php/8.0.0_1/pecl/20200930
You can step by step debug this problem with starting to check what it is inside the /usr/local/Cellar/php/8.0.0_1 folder running
$ cd /usr/local/Cellar/php/8.0.0_1
$ la -la
I tend to say that there is a pecl symlink already existing which is why pecl cannot create a folder there.
Then you should check where pecl is installed by running which pecl which ideally gives you /usr/local/bin/pecl which should point to somewhere /usr/local/Cellar/php/8.0.0_1/bin/pecl.
If that is the case you can remove the /usr/local/Cellar/php/8.0.0_1/pecl symlink with
$ rm /usr/local/Cellar/php/8.0.0_1/pecl
and try to reinstall xdebug.
Now fixing the image not found issue
This comes from an incorrect configuration during the xdebug installation.
First, check what the path to your php.ini file is by running ˋphp —-iniˋ.
Then open the file and check the First line if there is your xdebug Extension loaded. If yes, remove it there. Then add a file xdebug.ini in the conf.d folder and add the following to the file you create:
;XDebug
zend_extension="/usr/local/Cellar/php/8.0.0/pecl/CHANGEME/xdebug.so"
xdebug.remote_autostart=1
xdebug.remote_port=9000
xdebug.remote_enable=1
xdebug.profiler_enable=1
xdebug.profiler_output_dir="/tmp"
Please check that you have the correct path to your xdebug.so file and that the output dir exists.
I just removed the symlink rm /opt/homebrew/Cellar/php/8.0.8_1 and then reinstalled the mongodb again sudo pecl install mongodb
But I still had the PHP Warning on loading the mongodb.so so I edited the php.ini file as below:
extension="/opt/homebrew/Cellar/php/8.0.8_1/pecl/20200930/mongodb.so"
building on #codedge answer
you can add, to be able to use it in laravel
xdebug.mode=coverage
to the xdebug.ini file
An update to the answer https://stackoverflow.com/a/65836657/4568085
the "xdebug.ini" file options have been updated now the recommended settings are
;XDebug
zend_extension="/opt/homebrew/Cellar/php/8.1.9/pecl/20210902/xdebug.so"
xdebug.mode=debug
xdebug.start_with_request=yes
xdebug.client_port=9003
;xdebug.mode=profile
xdebug.output_dir="/tmp"
The old options triggered warnings in PHP as shown below
Related
I'm setting up a new macbook (Monterey 12.2.1 chip Apple M1 Pro), and installed PHP 7.4 with homebrew. I configured PHP to run as a module for the Apache2 server that comes with MacOS (Apache/2.4.51). I immediately ran into trouble because gatekeeper wouldn't allow me to run php as an apache module from homebrew until I codesigned it. I did codesign it:
codesign --sign "Mike Andersen" --force --keychain ~/Library/Keychains/login.keychain-db /opt/homebrew/opt/php#7.4/lib/httpd/modules/libphp7.so
And afterwards PHP worked perfectly. Then I installed xdebug with PECL:
arch -x86_64 sudo pecl install xdebug
When I checked it from the command line, everything looked right:
php -v
PHP 7.4.28 (cli) (built: Feb 28 2022 07:33:39) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.28, Copyright (c), by Zend Technologies
with Xdebug v3.1.3, Copyright (c) 2002-2022, by Derick Rethans
php --ini
Configuration File (php.ini) Path: /opt/homebrew/etc/php/7.4
Loaded Configuration File: /opt/homebrew/etc/php/7.4/php.ini
Scan for additional .ini files in: /opt/homebrew/etc/php/7.4/conf.d
Additional .ini files parsed: /opt/homebrew/etc/php/7.4/conf.d/20-ext-opcache.ini,
/opt/homebrew/etc/php/7.4/conf.d/99-xdebug.ini
But loading from a browser failed - the browser listed the 99-xdebug.ini file:
Additional .ini files parsed /opt/homebrew/etc/php/7.4/conf.d/20-ext-opcache.ini, /opt/homebrew/etc/php/7.4/conf.d/99-xdebug.ini
But nothing else about xdebug. I checked the apache error log and saw:
Failed loading /opt/homebrew/lib/php/pecl/20190902/xdebug.so:
dlopen(/opt/homebrew/lib/php/pecl/20190902/xdebug.so, 0x0009):
tried: '/opt/homebrew/lib/php/pecl/20190902/xdebug.so'
(code signature in <8E9B311F-7332-3812-89A8-91BA8FB71682> '/opt/homebrew/lib/php/pecl/20190902/xdebug.so'
not valid for use in process: mapped file has no Team ID and is not a platform binary (signed with custom identity or adhoc?)),
'/usr/lib/xdebug.so' (no such file)
I tried signing the xdebug.so file as well:
codesign --sign "Mike Andersen" --force --keychain ~/Library/Keychains/login.keychain-db /opt/homebrew/lib/php/pecl/20190902/xdebug.so
/opt/homebrew/lib/php/pecl/20190902/xdebug.so: replacing existing signature
And restarted apache, but still got the same error in the apache log. I've also tried re-signing PHP, no help. I've also tried disabling gatekeeper:
sudo spctl --master-disable
That made no difference either.
I've been googling this all morning, and can't find anything about how to address this problem. Somebody must have seen this by now, so I'm hoping one of you is that somebody and can help a brother out. Thanks in advance for any help you can offer.
It looks like the simplest way to fix this problem is to not use the Apache that Apple ships with Mac OS.
I installed apache with brew:
brew install apache2
And updated the httpd.conf file for brew to use port 80, and to point to Exactly. The. Same. Libphp7.so file that I used for Apple's Apache. No re-compiling, no codesign, nothing. Then I stopped and disabled Apple's Apache:
sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist
sudo apachectl stop
And finally, restarted brew's apache:
brew services restart httpd
Reloaded my phpinfo file, and all the xdebug goodness was there. First try!
I think the root problem here is that Apple compiles Apache to insist on codesigning, and then makes codesigning opaque and difficult. I'd still love to know if there's a real solution to this problem, but until then, use Brew's Apache and you should be good to go.
If you need help with codesigning PHP, this is the guide I used:
https://www.simplified.guide/macos/apache-php-homebrew-codesign
I'm using the ondrej ppa for PHP and am running Ubuntu 18. Running php -v gives me the following output:
PHP Warning: PHP Startup: Unable to load dynamic library 'curl.so' (tried: /usr/lib/php/20190902/curl.so (/usr/lib/php/20190902/curl.so: symbol curl_mime_addpart version CURL_OPENSSL_4 not defined in file libcurl.so.4 with link time reference), /usr/lib/php/20190902/curl.so.so (/usr/lib/php/20190902/curl.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
PHP 7.4.2 (cli) (built: Jan 23 2020 11:21:30) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.2, Copyright (c), by Zend Technologies
Basically, I can't run any composer commands because a lot of libraries depend on curl, and apparently it isn't being found. I've done the following:
Tried to update everything (sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade && sudo apt-get install php7.4-curl). This doesn't fix the issue.
Restarted apache despite this being the cli version.
Double checked where it's trying to find the library. What's weird is that /usr/lib/php/20190902/curl.so is a valid path and the file is definitely there.
Running php --ini also shows that the curl extension is loaded:
Configuration File (php.ini) Path: /etc/php/7.4/cli
Loaded Configuration File: /etc/php/7.4/cli/php.ini
Scan for additional .ini files in: /etc/php/7.4/cli/conf.d
Additional .ini files parsed: /etc/php/7.4/cli/conf.d/10-mysqlnd.ini,
...more ini files...
/etc/php/7.4/cli/conf.d/20-curl.ini,
...more ini files...
I'm unsure how to fix this as the file it supposedly can not find is exactly where it says it looked, and everything is up to date.
For anyone with this issue, the answer is here.
Basically, the libcurl that was installed on my Ubuntu machine clashed with the official one that Ubuntu has? Weirdly it was only affecting php7.3 and 7.4 and not 7.2. Anyways, I renamed the libcurl module like so:
mv /usr/local/lib/libcurl.so.4.4.0 /usr/local/lib/libcurl.so.4.4.0.backup
And by running php -m, I could verify that the cURL module was now enabled.
I found that if I did:
apt search | more
(the pipe is for long lists)
that I could find the php package name that I needed.
For example:
apt search curl
told me that the name of the package for my php version is 'php7.2-curl'
So, all I had to do was sudo apt install php7.2 curl.
I repeated this (some names require a little googling, and/or some apt search creativity.
I solved it by doing this:
Uninstall curl:
apt remove php7.4-curl
New install:
apt install php7.4-curl
I have now all right.
After trying to run composer update things were failing because the deps where from php -v 7 while I was using 8.
composer install --ignore-platform-reqs
worked for me
I'm trying to install Magento (2.3.0) on macOS Mojave. Magento shows PHP Extension intl. is missing.
I tried the below to resolve:
Made a copy of php.ini using cp /etc/php.ini.default php.ini
Removed ";" before extension=php_intl.dll
Restart Apache sudo apachectl restart
But the above did not resolve.
On checking php -v, i'm seeing the below error:
PHP Warning: PHP Startup: Unable to load dynamic library
'/usr/lib/php/extensions/no-debug-non-zts-20160303/php_intl.dll' -
dlopen(/usr/lib/php/extensions/no-debug-non-zts-20160303/php_intl.dll,
0x0009): dlopen(): file not found: /usr/lib/php/extensions/no-debug-
non-zts-20160303/php_intl.dll in Unknown on line 0
PHP 7.1.19 (cli) (built: Aug 17 2018 20:10:18) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2018 Zend Technologies
There are only 2 files under /usr/lib/php/extensions/no-debug-non-zts-20160303 namely opache.so and xdebug.so
How can i install or enable "PHP Extension intl" on my macOS Mojave?
Here's a solution that worked for me:
Find all PHP versions installed brew list | grep php
Remove all versions of PHP brew remove --ignore-dependencies --force php70 php71 php72 (based on what you see above)
Install PHP brew install php72 (i chose 7.2, 7.3 is not supported yet by several vendors)
Run the command which php should show you the path to the installed PHP. Copy the path.
Update your bash_profile vi ~/.bash_profile and add this line to the file:
export PATH=/usr/local/php5/bin:$PATH
Save and run this source ~/.bash_profile
Check if PHP Intl Extension is installed using php -m | grep intl. If the installation went well, we will see intl listed. If not the extension is not installed.
I think from PHP 7 (not sure of the version), the extensions are available by default and we need not enable them in php.ini file explicitly.
If you installed Homebrew's php, linking it to a directory in your path will fix the issue.
brew link --force php#7.3
I had the same issue and that fixed it.
Here is a link where I got a detailed answer from
Got help from the link and able to compile https://donatstudios.com/Install-PHP-Mcrypt-Extension-in-OS-X
Next we will download the PHP source. Verify the exact version of PHP you are running. This can be retrieved as follows. The version is highlighted.
$ php --version
PHP 7.1.19 (cli) (built: Aug 17 2018 18:03:17) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Now we move into a working directory and download the source making sure to update the following for the version from above.
$ cd /tmp
$ curl -L http://php.net/get/php-{{php-version}}.tar.bz2/from/this/mirror > php.tar.bz2
$ open php.tar.bz2
Now we will compile and test the extension.
$ cd php-{{php-version}}/ext/{{extension}}
$ phpize
$ ./configure
$ make
$ make test
$ sudo make install
If all that goes well finally we'll need to add the following to our php.ini - I usually add at it at the end of the file.
extension = {{extension}}
.so
You can verify your installation with the following:
$ php --info | grep {{extension}}\\.
Lastly, depending on your setup now you may want to restart apache.
$ sudo apachectl restart
I have overlook at this issue Linux - PHP 7.0 and MSSQL (Microsoft SQL)
and I am sure did exactly what MS told me to do in this page
installing-the-drivers-on-red-hat-7
howevey, i stiil got the error when type 'php -v':
PHP Warning: PHP Startup: Unable to load dynamic library
'pdo_sqlsrv.so' (tried: /usr/lib64/php/modules/pdo_sqlsrv.so
(/usr/lib64/php/modules/pdo_sqlsrv.so: undefined symbol:
php_pdo_register_driver), /usr/lib64/php/modules/pdo_sqlsrv.so.so
(/usr/lib64/php/modules/pdo_sqlsrv.so.so: cannot open shared object
file: No such file or directory)) in Unknown on line 0
PHP 7.2.10
(cli) (built: Sep 15 2018 07:10:58) ( NTS ) Copyright (c) 1997-2018
The PHP Group Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend
Technologies
with Zend OPcache v7.2.10, Copyright (c) 1999-2018, by Zend
Technologies
I never modify the php.ini,
[user#tssvr php.d]$ pwd
/etc/php.d
[user#tssvr php.d]$ ls
20-sqlsrv.ini ctype.ini fileinfo.ini gmp.ini mbstring.ini pdo.ini shmop.ini tokenizer.ini xmlwriter.ini
30-pdo_sqlsrv.ini curl.ini ftp.ini iconv.ini mysqli.ini pdo_mysql.ini simplexml.ini xml.ini xsl.ini
bz2.ini dom.ini gd.ini intl.ini opcache-default.blacklist pdo_sqlite.ini sockets.ini xmlreader.ini zip.ini
calendar.ini exif.ini gettext.ini json.ini opcache.ini phar.ini sqlite3.ini xml_wddx.ini
[user#tssvr php.d]$ cat 20-sqlsrv.ini
extension=sqlsrv.so
[user#tssvr php.d]$ cat 30-pdo_sqlsrv.ini
extension=pdo_sqlsrv.so
it seems that the sqlsrv.so is good, but the pho_sqlsrv.so just can't work correctly,,although i notice that double 'so' appear: 'pdo_sqlsrv.so.so' ,
can any guys can help me through this ,many thanks.
Type in terminal linux centos 7 :
php --ini
find /etc/php.d/20-pdo.ini
Edit the file and append extension=sqlsrv.so extension=pdo_sqlsrv.so
note: comment extension extension=sqlsrv.so , extension=pdo_sqlsrv.so in /etc/php.ini
reboot system
php -m - you see loaded module
The proper order to load the modules is:
extension=pdo.so
extension=pdo_sqlsrv.so
extension=sqlsrv.so
One can either put these into one .ini file - or use numbered .ini files.
Loading them in alphabetical order (which is the default) won't work.
I ran into the same issue with Ubuntu 18.04 and 20.xx. I finally got it to work on Ubuntu 18.04 and pretty sure this will work on 20.xx as well.
This is for PHP 7.1 so if you are not using 7.4 or 8.0 you will have to specify the version in pecl.
pecl install sqlsrv-5.7.0preview
pecl install pdo_sqlsrv-5.7.0preview
printf "; priority=20\nextension=sqlsrv.so\n" > /etc/php/7.1/mods-available/sqlsrv.ini
printf "; priority=30\nextension=pdo_sqlsrv.so\n" > /etc/php/7.1/mods-available/pdo_sqlsrv.ini
phpenmod -v 7.1 sqlsrv pdo_sqlsrv
service apache2 restart
The trick that got everything working was the printf and phpenmod command. You still need to add the extension to your php.ini file as well. Not sure if the order really matters but the driver does not appear to get installed properly using the pecl installer.
After restarting apache I can now see pdo_sqlsrv listed in php.ini and my php application can connect to the local Microsoft SQL server.
BTW, I got this working on WSL2 for Windows.
This is the way I solved this on CentOS 7.
First I've installed pdo_dblib extension
[root#localhost html]# yum list *dblib*
Complementos cargados:fastestmirror, langpacks
Loading mirror speeds from cached hostfile
* base: mirror.airenetworks.es
* centos-sclo-rh: mirror.airenetworks.es
* epel: ftp.uma.es
* extras: mirror.airenetworks.es
* remi-safe: mir01.syntis.net
* updates: mirror.tedra.es
Paquetes instalados
php73-php-pdo-dblib.x86_64
Paquetes disponibles
php70-php-pdo-dblib.x86_64
php71-php-pdo-dblib.x86_64
php72-php-pdo-dblib.x86_64
php74-pdo-dblib.x86_64
php74-php-pdo-dblib.x86_64
php80-php-pdo-dblib.x86_64
php81-php-pdo-dblib.x86_64
[root#localhost html]# yum install php73-php-pdo-dblib.x86_64
I have php 7.3 installed so I've chosen matching version extension. After installation, tried a simple test script I created to test connectivity but still got error.
Used locate command to find out if pdo_dblib.so library was correctly installed and found it under /opt/remi/php73/root/usr/lib64/php/modules path which looked a bit strange
With the command locate php.ini I discovered that there were 2 php.ini files on the machine. With the command php -i and by creating a simple file to test it from the web browser:
<?php
phpinfo()
I checked what php.ini file was in use both from Cli and from Apache. It was /etc/php.ini.
With php -m I saw PDO was loading correctly, so I searched the location of pdo.so library. Copied pdo_dblib.so library on previous search location. Searched for pdo_dblib.ini file and copied it under the location of pdo.ini file (which full name was 20-pdo.ini).
After all of these changes, restarted Apache systemctl restart httpd and checked again that pdo_dblib was loading both from cli and web whith php -i and the phpinfo() file.
I am trying to configure Xdebug on a local LAMP server with PHP 5.6 and Ubuntu 16.04 installed and am running into some difficulties. After first following the common installation directions: running "sudo apt install php-xdebug", modifying my php.ini to have the correct config, then restarting my apache server, I was not seeing Xdebug in my info.php (only the xdebug.ini that was being parsed in). When I run "sudo apt install php-xdebug" again however it would say that it was installed / up to date.
After trying a couple different things I was looking and saw that the new version of Xdebug no longer supports version lower than PHP 7, as such I saw what other versions were available by apt and purged the current Xdebug install I had in favor of running "sudo apt install php-xdebug=2.4.0-1" as I saw that version still supported older PHP versions. After this I still had the same issue however so I searched for similar issues.
I tried running "php -m" and "php5.6 -m" and both had different outputs but neither had Xdebug listed under Zend modules. Also ran "php --ini" and the output was
Configuration File (php.ini) Path: /usr/local/lib
Loaded Configuration File: (none)
Scan for additional .ini files in: (none)
Additional .ini files parsed: (none)
"php5.6 --ini" on the other hand outputs:
Failed loading /usr/lib/php/20131226/usr/lib/php/20131226/xdebug.so: /usr/lib/php/20131226/usr/lib/php/20131226/xdebug.so: cannot open shared object file: No such file or directory
Configuration File (php.ini) Path: /etc/php/5.6/cli
Loaded Configuration File: /etc/php/5.6/cli/php.ini
Scan for additional .ini files in: /etc/php/5.6/cli/conf.d
Additional .ini files parsed: /etc/php/5.6/cli/conf.d/10-mysqlnd.ini,
/etc/php/5.6/cli/conf.d/10-opcache.ini....
In case it helps here is the output for "php -v"
PHP 5.4.45 (cli) (built: Nov 15 2017 10:53:58)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies
And "php5.6 -v"
PHP 5.6.34-1+ubuntu16.04.1+deb.sury.org+1 (cli)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies
Not sure why "php -v" shows a different version of PHP and Zend Engine than "php5.6 -v" but figured it may be relevant to my issue. Anyways, I checked to make sure "xdebug.so" existed in that directory so I ran "locate xdebug.so"
/usr/lib/php/20131226/xdebug.so
/usr/lib/php/20151012/xdebug.so
In the "php5.6 --ini" output it was clear that some path was getting appended to the one I was adding in my /etc/php/5.6/cli/php.ini file, so I commented out
;zend_extension="usr/lib/php/20131226/xdebug.so"
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.remote_log="/var/log/xdebug/xdebug.log"
xdebug.remote_enable = On
xdebug.remote_mode = req
xdebug.remote_connect_back = 1
xdebug.profiler_enable = On
xdebug.profiler_enable_trigger = On
After doing that when I run "php5.6 --ini" I no longer get the failed loading error but still Xdebug is no where to be found / used. I used step 4 in Check if xdebug is working to check if it is installed properly and I always get call to undefined function so it's clear the installation is wrong. My end goal here is to get Xdebug set up so I can link it with Sublime but the first step is obviously just getting Xdebug installed on my server.
My hunch is it's something to do with my differences between php and php5.6? I've usually been able to get to the bottom of issues through hunting online but at this point I feel like I've tried most suggestions and genuinely don't know what I should do; my experience with these sort of issues is limited as well. Also https://xdebug.org/wizard.php doesn't help as it just says under PHP 7 isn't supported. Hopefully I've detailed everything I've tried so far, any help or things I could try would be greatly appreciated, also if I can provide any more details to figure this out just let me know.