MAMPStack dylib and pear/pecl config locations

MAMPStack installer in the 7.y.z series seems to put libraries (*.dylib) both into /Applications/mampstack-7.y.z-0/common/lib and /bitnami/mampstackDev-osx-x64/output/common/lib. It also seems that libraries in /Applications/mampstack-7.y.z-0/common/lib link to the ones in the other directory. Also pear and pecl configuration refers to the /bitnami directory causing all sorts of trouble trying to install PHP modules with them. This is not very nice. I’d suggest getting rid of the /bitnami directory, using only /Applications/mampstack-7.y.z-0/common/lib and changing the dependencies accordingly.

What I did to be able to install e.g. PHP CodeSniffer properly with MAMPStack 7.0.12-0 was:

cd /Applications/mampstack-7.0.12-0/common/lib
for i in *.dylib; do install_name_tool -change /bitnami/mampstackDev-osx-x64/output/common/lib/$i /Applications/mampstack-7.0.12-0/common/lib/$i /Applications/mampstack-7.0.12-0/php/bin/php.bin; done
pear config-set bin_dir /Applications/mampstack-7.0.12-0/php/bin
pear config-set doc_dir /Applications/mampstack-7.0.12-0/php/lib/docs
pear config-set data_dir /Applications/mampstack-7.0.12-0/php/lib/php/data
pear config-set doc_dir /Applications/mampstack-7.0.12-0/php/lib/php/docs
pear config-set php_bin /Applications/mampstack-7.0.12-0/php/bin/php
pear config-set test_dir /Applications/mampstack-7.0.12-0/php/lib/php/test
pear config-set www_dir /Applications/mampstack-7.0.12-0/php/lib/php/www
pear config-set man_dir /Applications/mampstack-7.0.12-0/php/man
pecl config-set ext_dir /Applications/mampstack-7.0.12-0/php/lib/php/extensions
pecl config-set php_dir /Applications/mampstack-7.0.12-0/php/lib/php
pecl config-set cfg_dir /Applications/mampstack-7.0.12-0/php/lib/php/cfg

But I don’t think all this should be necessary. This is especially concerning since there is no version number in the paths in /bitnami, which means that a side-by-side installation of multiple MAMPStack versions might break in peculiar ways.


1 Like

Hi @eremaijala,

Thanks for reporting this issue. We were able to reproduce the issue installing PHP CodeSniffer, where the packages would be installed to the wrong location. We will look into it.

However, we only found contents inside the php directory and we’re interested in knowing which files were located inside the following directory:



Best regards,

It’s not that a pear or pecl package installation puts something into /bitnami/mampstackDev-osx-x64/output/common/lib but that the MAMPStack installer puts stuff in there and the libraries in /Applications/mampstack-7.y.z-0/common/lib also point there. See the example here:

bash-3.2$ cd /Applications/mampstack-7.0.13-1/common/lib/
bash-3.2$ otool -L libssl.1.0.0.dylib
    /bitnami/mampstackDev-osx-x64/output/common/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
    /bitnami/mampstackDev-osx-x64/output/common/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 832.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)

I think libssl.1.0.0.dylib should use libcrypto.1.0.0.dylib from the same directory where it is. Besides, /bitnami/mampstackDev-osx-x64 looks like a development or build system directory that, I believe, shouldn’t be created by the installer in the first place and wouldn’t be necessary if the libraries would point to the correct directory.

Hi @eremaijala,

Unfortunately we haven’t found any other directories in /bitnami/mampstackDev-osx-x64/output/ other than php, where the PECL package was installed.

We have already opened a case for fixing the PEAR issue. If you need to execute any other command (like php or mysql), it will be enough to load the environment:

$ cd /Applications/mampstack-7.0.13-1/
$ ./use_mamp

If you found a similar case than the PEAR issue, please let us know so we can look into it.

We will consider executing install_name_tool -change for the binaries we package, since it will be useful for the macOS stacks.

Best regards,

I’ve just installed MAMPStack 7.1.1-0 and encountered quite similar issues as with 7.0.13-1. For example trying to install xdebug after executing the use_mampstack script with the following command:

pecl install xdebug

Displayes the following error:

Cannot install, php_dir for channel "" is not writeable by the current user

Pear and pecl configuration is still wrong:

pecl config-show

shows invalid paths for many settings like:

PEAR executables directory     bin_dir          /bitnami/mampstackSecondDev-osx-x64/output/php/bin

“/bitnami/mampstackSecondDev-osx-x64” directory doesn’t exist on my system.

Also the dylib locations are still borked. E.g. trying to update composer from the old version that comes with MAMPStack leads to composer breaking beyond repair:

bash-3.2$ composer self-update
Updating to version 07123715d6782185b25059871f272054057333c7.
  Downloading: 100%
Use composer self-update --rollback to return to version c41079192f38f0fc446b17baa8f628dcb3b61e7d
bash-3.2$ composer
dyld: Library not loaded: /bitnami/mampstackSecondDev-osx-x64/output/common/lib/libcrypto.1.0.0.dylib
  Referenced from: /Applications/mampstack-7.1.1-0/php/bin/php.bin
  Reason: image not found

Best Regards,


We have this task on our roadmap. Unfortunately, we have not had time to solve it. Thank you for the feedback.

I’ve been having trouble getting PHP_CodeSniffer (and sometimes Xdebug, and a few other components to work for awhile too.I keep running into the same issue with location of referenced *dylib files. I Initially mentioned this here but jota wasn’t able to reproduce the issue.

I’ve tried setting DYLD_FALLBACK_LIBRARY_PATH as suggested by crhernandez and marcos in this Djangostack thread but it appears that Apple’s SIP no longer allows that.

I’m guessing that this is somehow a result of one PHP process spawning another child PHP process that for some reason isn’t getting the correct environment or PHP binary.

I was able to get a suggestion by tomasp over in this thread to work in some instances. (Changing the order of methods in PhpExecutableFinder) However I think (maybe?) in other cases I can’t quite do that because the file is embedded in Composer’s phar? In that same thread it was suggested to just symlink the incorrect library references, but newer versions of macOS consider the root level of the drive to be read only so that command failed.

eremaijala’s suggestion at the top here seemed to get me a little further, but now while the php.bin itself has good references, some of the libraries themselves are incorrect:

% '/Applications/mampstack-7.4.25-0/php/bin/php.bin' -d allow_url_fopen='1' -d disable_functions="" -d memory_limit='1536M' ./bin/phpcs --config-set installed_paths /Users/tflight/.composer/vendor/phpcompatibility/php-compatibility,/Users/tflight/.composer/vendor/slevomat/coding-standard,/Users/tflight/.composer/vendor/wp-coding-standards/wpcs
dyld[4579]: Library not loaded: /bitnami/mamp74stack-osx-x64/output/common/lib/libsasl2.3.dylib
  Referenced from: /Applications/mampstack-7.4.25-0/common/lib/libldap-2.5.0.dylib
  Reason: tried: '/bitnami/mamp74stack-osx-x64/output/common/lib/libsasl2.3.dylib' (no such file), '/usr/local/lib/libsasl2.3.dylib' (no such file), '/usr/lib/libsasl2.3.dylib' (no such file)
zsh: abort      '/Applications/mampstack-7.4.25-0/php/bin/php.bin' -d allow_url_fopen='1' -d 
tflight@tflight-mb .composer % otool -L /Applications/mampstack-7.4.25-0/common/lib/libldap-2.5.0.dylib
	/bitnami/mamp74stack-osx-x64/output/common/lib/libldap-2.5.0.dylib (compatibility version 2.0.0, current version 2.3.0)
	/bitnami/mamp74stack-osx-x64/output/common/lib/liblber-2.5.0.dylib (compatibility version 2.0.0, current version 2.3.0)
	/bitnami/mamp74stack-osx-x64/output/common/lib/libsasl2.3.dylib (compatibility version 4.0.0, current version 4.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
	/System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos (compatibility version 5.0.0, current version 6.0.0)
	/usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)
	/bitnami/mamp74stack-osx-x64/output/common/lib/libssl.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
	/bitnami/mamp74stack-osx-x64/output/common/lib/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)

I’ve come across this info, which looks helpful but is just a bit beyond my current understanding:

Has any progress been made on this issue?

Hi @tflight,

You should not use '/Applications/mampstack-7.4.25-0/php/bin/php.bin'. Use '/Applications/mampstack-7.4.25-0/php/bin/php' instead. Note this is a wrapper that loads the right environment.

export PHPRC
. /Applications/mampstack-7.4.25-0/php/../scripts/
exec /Applications/mampstack-7.4.25-0/php/bin/php.bin "$@"

I hope it helps

Hi @davidg,

Thank you. Yes, however I’m not calling that directly, I’m just performing composer update. The log above was showing what was happing when running composer update -vvv to show where the error was coming from. One of my dependencies is using Symfony’s PhpExecutableFinder to locate the PHP binary and is finding ‘/Applications/mampstack-7.4.25-0/php/bin/php.bin’ instead of ‘/Applications/mampstack-7.4.25-0/php/bin/php’.

I believe this should be reproducible.

cd /Applications/mampstack-7.4.25-0/php/composer/
composer require wp-coding-standards/wpcs
composer require dealerdirect/phpcodesniffer-composer-installer

At that point you should get an error:

  The process has been signaled with signal "6".

Hi @tflight,

I could reproduce your issue. It seems that the command fails under php/composer directory. Running those commands in a different path worked for me. Just to confirm, could you try the commands below?

cd /Applications/mampstack-7.4.25-0/
composer require wp-coding-standards/wpcs
composer require dealerdirect/phpcodesniffer-composer-installer

mkdir new
cd new
composer require wp-coding-standards/wpcs
composer require dealerdirect/phpcodesniffer-composer-installer

Reply n when you get asked about using an existing file in the new directory.


Hi @davidg,

Thanks again for your help here, and noting you could reproduce the issue. I wasn’t able to get it to work running it in a different directory like you were. To workaround the issue I’ve installed a different PHP binary and running composer through that binary works. Not a great solution, but it looks like it will have to do for now.

Again, thanks for your help, I really do appreciate it.

1 Like

Hello @tflight,

Happy you could work around it. It is weird that different behavior. We added all your feedback to the task.