Hi !
I hope this is the right mailing list to post my request to.
I found a port of bcompiler here:
https://github.com/vjardin/bcgen/
which is PHP7 compatible.
By mailing here, I am trying to reach out to the authors of the PHAR
extension since the author(s) of bcgen have said that they don't know
enough about the PHAR extension.
I am trying to get bcgen to work with PHAR files. I have added the
compiled PHP files to the PHAR file (using their PHP extension within
the PHAR file)
The stub of the PHP archive is:
|#!/usr/bin/env php|
|<?php|
|Phar::mapPhar( 'app.phar' );|
|set_include_path( 'phar://app.phar' . PATH_SEPARATOR.';.');|
|require('phar://' . FILE . '/app.php');|
|__HALT_COMPILER(); |?>
The file app.php is in the root of the PHAR archive and is compiled by
bcgen.
When I run the phar (on the commandline), all I get is some gibberish
output (to STDOUT) and the process exits with exitcode 130 ?
My understanding is that bcgen extension will inspect the file which is
included/required (ie. app.php) and then - if it is bytecode - then
simply execute the bytecode - If it is not, then it will parse the
included file normally ? (from the description found in the README of
bcgen in github)
However it seems that what actually happens, is that the header of the
PHAR file itself is checked and since that is obviously not a BCGEN
header or a normal PHP file, processing is aborted.
If we could skip this check when running from a PHAR archive (from the
commandline or when the PHAR is included within some other PHP file) and
in this scenario only "react" to include/require/autoloading statements
(ie. check if a file that is about to be included is bytecode or not -
if it is, then run it - If it is not then compile it first and then run
the resulting bytecode), then - in my humble opinion - we would have a
way of adding minimal protection to PHAR files - useful when
redistributing PHARs (since such a PHAR archive would then simply
contain a number of files that are bytecode - except for the stub of
course...) and that would - I think - make PHAR files even cooler and
provide a most sought-after feature.
Could anyone help getting "PHAR support" to work with the bcgen
extension ? I would be willing to help but my C skills are not that
great and I know little about the ZendEngine.
Thanks in advance !
Best regards,
Henrik Skov
Secuno A/S
www.secuno.dk
I found a port of bcompiler here:
https://github.com/vjardin/bcgen/
which is PHP7 compatible.
By mailing here, I am trying to reach out to the authors of the PHAR
extension since the author(s) of bcgen have said that they don't know
enough about the PHAR extension.
I am not the author of Phar, but I am the current maintainer, so I'll do my
best to help. I am responding to your comments here so we can discuss, but
I encourage you to open a request at bugs.php.net so that we can track and
act on it.
I am trying to get bcgen to work with PHAR files. I have added the
compiled PHP files to the PHAR file (using their PHP extension within
the PHAR file)The stub of the PHP archive is:
|#!/usr/bin/env php|
|<?php|
|Phar::mapPhar( 'app.phar' );|
|set_include_path( 'phar://app.phar' . PATH_SEPARATOR.';.');|
|require('phar://' . FILE . '/app.php');|
|__HALT_COMPILER(); |?>The file app.php is in the root of the PHAR archive and is compiled by
bcgen.When I run the phar (on the commandline), all I get is some gibberish
output (to STDOUT) and the process exits with exitcode 130 ?
In my experience, exit codes above 128 indicate the process received a
signal, whose number is the difference between the exit code and 128. So,
130 - 128 = 2, and signal 2 is "Interrupt", which I usually associate with
the shell receiving a keystroke of Control+C. Is that what happened?
If not, we'll need a similar app.php to explore this further.
My understanding is that bcgen extension will inspect the file which is
included/required (ie. app.php) and then - if it is bytecode - then
simply execute the bytecode - If it is not, then it will parse the
included file normally ? (from the description found in the README of
bcgen in github)
While I'm grossly simplifying for purposes of discussion here, phar is
fundamentally a file archive format: think Zip or Tar file. When you open a
file on the phar:// stream, you're asking the phar subsystem to expand the
given path out of the archive and make it available to the caller as if it
were locally available at that path.
There are some gymnastics here to make that possible, and those might be
what's causing the incompatibility you've seen, but it sounds like it might
be a problem not with bcgen, or with phar, but with how the two are trying
to work together.
However it seems that what actually happens, is that the header of the
PHAR file itself is checked and since that is obviously not a BCGEN
header or a normal PHP file, processing is aborted.
If bcgen is inspecting the header of the phar, that suggests to me bcgen
needs some logic to detect the phar and open it as a phar stream instead of
attempting to read it as either binary or text. Said another way, if bcgen
is doing a simple "if has certain magic number in first N bytes then is
byte code else is php text" that logic won't work, if you're passing a
whole phar to bcgen. On the other hand, if bcgen intercepts calls to
include (and friends), it should transparently see either bytecode or php
text, because the phar subsystem has already expanded the file in place.
Either way, this sounds like an incompatibility between the two that should
probably be explored on the bcgen side.
If we could skip this check when running from a PHAR archive (from the
commandline or when the PHAR is included within some other PHP file) and
in this scenario only "react" to include/require/autoloading statements
(ie. check if a file that is about to be included is bytecode or not -
if it is, then run it - If it is not then compile it first and then run
the resulting bytecode), then - in my humble opinion - we would have a
way of adding minimal protection to PHAR files - useful when
redistributing PHARs (since such a PHAR archive would then simply
contain a number of files that are bytecode - except for the stub of
course...) and that would - I think - make PHAR files even cooler and
provide a most sought-after feature.
What you describe sounds like my "bcgen hooks into include" scenario above,
which would be a change request for the bcgen authors. I don't know bcgen,
but if there's interest in getting the two to work together, I suggest
opening this request at bugs.php.net.
Could anyone help getting "PHAR support" to work with the bcgen
extension ? I would be willing to help but my C skills are not that
great and I know little about the ZendEngine.
Glad you're willing to help! You don't need to be a C expert, just have a
passion for PHP and a willingness to contribute where you can: like
providing great test cases, or writing clear docs.
Next step: open this issue at bugs.php.net with all the info necessary to
reproduce it. From there, I can run it in a debugger and step through the
code to spot the incompatibility.