ext-ds: Error after add extension=ds.so to php.ini

@rtheunissen ok, json extension was loaded in additional ini file (conf.d). To fix this problem i create new file (for example 30-ds.ini) with content extension=ds.so and put it in /etc/php/7.0/fpm/conf.d. Now ds extension is load as last:

Additional .ini files parsed => /etc/php/7.0/cli/conf.d/10-opcache.ini,
/etc/php/7.0/cli/conf.d/20-curl.ini,
/etc/php/7.0/cli/conf.d/20-gd.ini,
/etc/php/7.0/cli/conf.d/20-intl.ini,
/etc/php/7.0/cli/conf.d/20-json.ini,
/etc/php/7.0/cli/conf.d/20-mysqli.ini,
/etc/php/7.0/cli/conf.d/20-pdo_mysql.ini,
/etc/php/7.0/cli/conf.d/20-pdo_pgsql.ini,
/etc/php/7.0/cli/conf.d/20-pgsql.ini,
/etc/php/7.0/cli/conf.d/20-readline.ini,
/etc/php/7.0/cli/conf.d/30-ds.ini

Thanks for help 👍

I was getting the same Unable to load dynamic library … undefined symbol: php_json_serializable_ce issue as @itcraftsmanpl on Linux Mint, regardless of whether I installed using pecl install ds or did git clone and built the code. Changing /etc/php/7.0/mods-available/ds.ini to be:

; configuration for php ds module
; priority=30
 extension=ds.so

and then doing

 $ sudo phpenmod ds

worked, but only after I manually removed all the 20-ds.ini symbolic links. Thanks so much for this extension!

@rtheunissen - Other extensions are also suffering from this. The issue is with distribution’s PHPs not doing the standard PHP thing. I have written an explanation at https://derickrethans.nl/undefined-symbol.html about the how and why.

There is currently a hard dependency on the json extension, which is a bug because it shouldn’t try to implement JsonSerializable if the json extension is not loaded.

Try enabling the json extension, or specifying ds.so after json is already enabled.

encountered this issue too, fixed it by creating a symlink called /etc/php/7.3/cli/conf.d/25-ds.ini so the /etc/php/7.3/cli/conf.d/20-json.ini will load first

@chippyash extension=ds.dll or extension=php_ds.dll isn’t it?

I’m using Fedora 25 (PHP 7.0.20) and I have had the same problem. Just creating a new config file /etc/php.d/50-ds.ini, as teached on @derickr post, worked perfectly.

Inside the file, just extension=ds.so is needed.

This is so infuriating, how are other extensions not also running into this problem / how is this still a thing? Thanks for all the feedback here everyone, I’m going to link the readme directly to this issue.

Well, I found that even though I edit /etc/php/7.0/mods-available/ds.ini to look like:

; configuration for php ds module ; priority=30 extension=ds.so

And even though I first did

$ sudo phpdismod ds

This did not remove the 20-ds.ini symbolic links

$ cd /etc/php/7.0/ $ find . -name “*ds.ini”

./apache2/conf.d/20-ds.ini ./fpm/conf.d/20-ds.ini ./mods-available/ds.ini ./cli/conf.d/20-ds.ini ./cli/conf.d/30-ds.ini

So that after I edited /etc/php/7.0/mods-available/ds.ini to be:

; configuration for php ds module ; priority=30 extension=ds.so

instead of

; configuration for php ds module ; priority=20 extension=ds.so

and eve after I did

$ sudo phpdismod ds

before doing

$ sudo phpenmod ds

The old 2-ds.ini symbolic links were still present, and I had to manually remove them by hand.

This showed that there were both 20-ds.ini and 30-ds.ini symbolic links.

On 10/20/2016 08:51 AM, Andreu Correa Casablanca wrote:

I’m facing this issue too 😦 . I’ve used the trick of naming the file 30-ds.ini (and ensuring that there is not 20-ds.ini file), but the problem is happening anyway.

I’m working with PHP7.0, and Ubuntu 16.04. I’ve installed the extension through PECL.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/php-ds/extension/issues/2#issuecomment-255096772, or mute the thread https://github.com/notifications/unsubscribe-auth/AAH9yoJpZTInh6QdU3t-twoMjFt8VV0cks5q12PagaJpZM4HWSF0.

I’ve added a note in README.md, not much else that can be done.