I was playing around with some libraries using FFI and I wanted to
share a .phar with the result, but to my surprise, it didn't work.
Apparently we are not able to load shared libraries using FFI from
within .phar files.
Is that the expected behavior or is it a bug in the FFI extension?
I have setup a dummy repo so the error could be easily reproduced:
https://github.com/CViniciusSDias/ffi-phar-problem
I am sorry if this is not the list to send this type of problem. I
will gladly move the thread to the right one if someone points it out.
Thanks, folks.
Vinicius Dias,
Zend Certified Engineer,
iMasters PHP Certified Professional
I was playing around with some libraries using FFI and I wanted to
share a .phar with the result, but to my surprise, it didn't work.Apparently we are not able to load shared libraries using FFI from
within .phar files.
Is that the expected behavior or is it a bug in the FFI extension?I have setup a dummy repo so the error could be easily reproduced:
https://github.com/CViniciusSDias/ffi-phar-problemI am sorry if this is not the list to send this type of problem. I
will gladly move the thread to the right one if someone points it out.
https://www.php.net/unsub.php
Erstwhile PHAR extension maintainer here. What an interesting question! The
short answer is no, FFI does not support loading dynamic libraries
contained within a PHAR archive.
The longer answer is that FFI was not written to be able to support VFS
locations, including the phar:// scheme. In this case, PHP starts and
invokes the code. The code invokes FFI1 with a phar:// path, which then
tries to perform a dlopen()2, which fails because dlopen has no idea how
to resolve PHAR paths: dlopen() expects a path that the OS can resolve3.
I suppose it'd be possible to improve FFI to call the PHP VFS layer to
resolve a path, which would handle the phar:// scheme and other schemes.
But, I would be worried about potential other downstream impacts - esp.
security implications - as this is a novel (to me at least) scenario.
bishop
Ah, that makes total sense. I was worried I was doing something very wrong. haha
Thank you very much for the detailed clarification.
This doesn't seem to be a "critical" feature, but I wonder if the
documentation shouldn't mention something about only "regular files"
being supported.
Vinicius Dias,
Zend Certified Engineer,
iMasters PHP Certified Professional
Vinicius Dias,
Zend Certified Engineer,
iMasters PHP Certified Professional
Em sex., 8 de set. de 2023 às 16:55, Bishop Bettini bishop@php.net escreveu:
I was playing around with some libraries using FFI and I wanted to
share a .phar with the result, but to my surprise, it didn't work.Apparently we are not able to load shared libraries using FFI from
within .phar files.
Is that the expected behavior or is it a bug in the FFI extension?I have setup a dummy repo so the error could be easily reproduced:
https://github.com/CViniciusSDias/ffi-phar-problemI am sorry if this is not the list to send this type of problem. I
will gladly move the thread to the right one if someone points it out.
https://www.php.net/unsub.phpErstwhile PHAR extension maintainer here. What an interesting question! The short answer is no, FFI does not support loading dynamic libraries contained within a PHAR archive.
The longer answer is that FFI was not written to be able to support VFS locations, including the phar:// scheme. In this case, PHP starts and invokes the code. The code invokes FFI1 with a phar:// path, which then tries to perform a dlopen()2, which fails because dlopen has no idea how to resolve PHAR paths: dlopen() expects a path that the OS can resolve3.
I suppose it'd be possible to improve FFI to call the PHP VFS layer to resolve a path, which would handle the phar:// scheme and other schemes. But, I would be worried about potential other downstream impacts - esp. security implications - as this is a novel (to me at least) scenario.
bishop