PHP 8.1.8 lint

[Lewis G Rosenthal]

Hey, Paul!

Two nits with 8.1.8:

PHP 8 should now prefer module names specified in php.ini sans filename
extensions, however, our build seems incapable of appending ".dll"
internally. I suggest this be addressed, as we don't know when they might do
away with allowing the extension in a later release (see note in
php.ini-production, for example).

When starting up (php.exe -l), I get:

PHP Notice: PHP Startup: update_beginlibpath set BEGINLIBPATH to modules in
Unknown on line 0

This seems like so much ado about nothing, but just want to check. php -i
doesn't seem to know about BEGINLIBPATH (not listed), so I'm wondering
whether this is actually being set.

Cheers

--
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS, EA
Rosenthal & Rosenthal, LLC www.2rosenthals.com
visit my IT blog www.2rosenthals.net/wordpress
-------------------------------------------------------------

[Paul Smedley]

Hey Lewis,

On 6/8/22 07:59, Lewis G Rosenthal wrote:
> Two nits with 8.1.8:
>
> PHP 8 should now prefer module names specified in php.ini sans filename
> extensions, however, our build seems incapable of appending ".dll"
> internally. I suggest this be addressed, as we don't know when they
> might do away with allowing the extension in a later release (see note
> in php.ini-production, for example).

I wasn't aware of this - I'll investigate.

> When starting up (php.exe -l), I get:
>
> PHP Notice:  PHP Startup: update_beginlibpath set BEGINLIBPATH to
> modules in Unknown on line 0
>
> This seems like so much ado about nothing, but just want to check. php
> -i doesn't seem to know about BEGINLIBPATH (not listed), so I'm
> wondering whether this is actually being set.

https://github.com/psmedley/php-os2/commit/b95ab74e57da14a93550a51ec94a73f0042119df
has more detail

Essentially Steven added code to include the modules directory in
beginlibpath to avoid having to add the dir to the environment in a .cmd
file

Cheers,

Paul

[Lewis G Rosenthal]

Hi, again...

On 08/05/22 06:51 pm, Paul Smedley wrote:
>
> Hey Lewis,
>
> On 6/8/22 07:59, Lewis G Rosenthal wrote:
>> Two nits with 8.1.8:
>>
>> PHP 8 should now prefer module names specified in php.ini sans filename
>> extensions, however, our build seems incapable of appending ".dll"
>> internally. I suggest this be addressed, as we don't know when they might
>> do away with allowing the extension in a later release (see note in
>> php.ini-production, for example).
> I wasn't aware of this - I'll investigate.
>

As I requested quite some versions back (and as you added to previous
releases), it would be handy to include php.ini-development and
php.ini-production in the package. This way, one wouldn't have to go
upstream to fetch the matching sample files with each release. ;-)

>> When starting up (php.exe -l), I get:
>>
>> PHP Notice: PHP Startup: update_beginlibpath set BEGINLIBPATH to modules
>> in Unknown on line 0
>>
>> This seems like so much ado about nothing, but just want to check. php -i
>> doesn't seem to know about BEGINLIBPATH (not listed), so I'm wondering
>> whether this is actually being set.
> https://github.com/psmedley/php-os2/commit/b95ab74e57da14a93550a51ec94a73f0042119df
> has more detail
>
> Essentially Steven added code to include the modules directory in
> beginlibpath to avoid having to add the dir to the environment in a .cmd file
>

Indeed, I was aware of the change (though not the code, until now; thanks
for the ref). If BEGINLIBPATH has already been set before starting php, the
report is a tad different (as expected):

PHP Notice: PHP Startup: update_beginlibpath set BEGINLIBPATH to

modules;%BEGINLIBPATH% in Unknown on line 0

I suspect the "in Unknown on line 0" is misleading, but without seeing
evidence of BEGINLIBPATH in the php info report, I'm suspicious that this is
actually doing what we expect. I'll wait for Steve to weigh in on it, though.

Thanks!

[Paul Smedley]

Hey Lewis!

On 6/8/22 08:37, Lewis G Rosenthal wrote:
> As I requested quite some versions back (and as you added to previous
> releases), it would be handy to include php.ini-development and
> php.ini-production in the package. This way, one wouldn't have to go
> upstream to fetch the matching sample files with each release. ;-)

Added the following to my build.cmd:
'copy php.ini-development php8'
'copy php.ini-production php8'

:)

Meanwhile, I'm struggling to spot the code that adds the extension to
the module name...

Cheers,

Paul

[Paul Smedley]

Hey Guys

Spotted something in php.m4 - rebuilding now - might be fixed in 8.1.9 :P

[Steven Levine]

In <62ED99C4...@2rosenthals.com>, on 08/05/22
at 06:29 PM, Lewis G Rosenthal <lgros...@2rosenthals.com> said:

Hi Lewis,

>PHP Notice: PHP Startup: update_beginlibpath set BEGINLIBPATH to modules
>in Unknown on line 0

This is:

ext\standard\dl.c:187
php_error_docref(NULL, E_NOTICE,
"update_beginlibpath set BEGINLIBPATH to %s", beginlibpath);

You must be running with E_NOTICE set, which to my understanding is
typically off for production systems. This is as close to http's info
level as I could get.

>This seems like so much ado about nothing, but just want to check. php -i
> doesn't seem to know about BEGINLIBPATH (not listed), so I'm wondering
>whether this is actually being set.

We could move the reporting to php_print_info() if you think this would be
better.

Steven

--
----------------------------------------------------------------------
"Steven Levine" <ste...@earthlink.net> Warp/DIY/BlueLion etc.
www.scoug.com www.arcanoae.com www.warpcave.com
----------------------------------------------------------------------

[Lewis G Rosenthal]

They there!

On 08/05/22 07:14 pm, Paul Smedley wrote:
>
> Hey Lewis!
>
> On 6/8/22 08:37, Lewis G Rosenthal wrote:
>> As I requested quite some versions back (and as you added to previous
>> releases), it would be handy to include php.ini-development and
>> php.ini-production in the package. This way, one wouldn't have to go
>> upstream to fetch the matching sample files with each release. ;-)
>
> Added the following to my build.cmd:
> 'copy php.ini-development php8'
> 'copy php.ini-production php8'
>
> :)
>

;-)

> Meanwhile, I'm struggling to spot the code that adds the extension to the
> module name...
>

Wish I could shed some light, but I'm only going from comments in the config
and php.net docs.

[Steven Levine]

In <8e0f60de-915d-45ec...@smedley.id.au>, on 08/06/22
at 08:44 AM, Paul Smedley <pa...@smedley.id.au> said:

Hi Paul,

>Meanwhile, I'm struggling to spot the code that adds the extension to
>the module name...

The initial load attempt is done at:

ext\standard\dl.c:244
handle = php_load_shlib(libpath, &err1);

If this fails the fallback code follows. Looking at the existing code, it
appears there is already support for PHP_SHLIB_SUFFIX which is defined in
build-defs.h. I suspect if you rebuild with PHP_SHLIB_SUFFIX set to "dll"
rather than "so", we might get the desired results.

[Steven Levine]

In <4db48fba-458e-c76f...@smedley.id.au>, on 08/06/22

at 09:23 AM, Paul Smedley <pa...@smedley.id.au> said:

Hi Paul,

>Spotted something in php.m4 - rebuilding now - might be fixed in 8.1.9 :P

That looks like the place that needs to change.

[Paul Smedley]

Lol my typical trend where I poabout a problem, then find a solution 5 minutes later!

Cheers,

Paul

---

From: Steven Levine <ste...@earthlink.net>
Sent: Saturday, 6 August 2022 09:43
To: apa...@googlegroups.com
Subject: Re: [Apache/2] PHP 8.1.8 lint

In <4db48fba-458e-c76f-c91...@smedley.id.au>, on 08/06/22

--
You received this message because you are subscribed to the Google Groups "Apache for OS/2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to apache2+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/apache2/62edb230.6.mr2ice.fgrirsq%40earthlink.net.

[Steven Levine]

In <62EDA2A2...@2rosenthals.com>, on 08/05/22
at 07:07 PM, Lewis G Rosenthal <lgros...@2rosenthals.com> said:

Hi,

>Indeed, I was aware of the change (though not the code, until now; thanks
> for the ref). If BEGINLIBPATH has already been set before starting php,
>the report is a tad different (as expected):

>PHP Notice: PHP Startup: update_beginlibpath set BEGINLIBPATH to
>modules;%BEGINLIBPATH% in Unknown on line 0

>I suspect the "in Unknown on line 0" is misleading, but without seeing
>evidence of BEGINLIBPATH in the php info report, I'm suspicious that this
>is actually doing what we expect.

It's working as intended. Try running without the php extensions
directory in LIBPATH. It will fail for the extensions that reference
other extension DLLs.

I agree that the error reporting is annoying. The "Unknown on line 0"
means that the report is not related to a specific script and line number.
I don't know how to suppress addenda.

I'm fine with moving the output to php_info, which is already plenty
versbose. Please submit a ticket so the idea does not get forgotten. If
Paul want's to disable the current reporting, I'm fine with that too. I
needed the reporting when debugging, but that time is past.

[Lewis Rosenthal]

Sorry for the ugly top-post; AFK ATM...

It might indeed be better limited to info, just to quell some of the noise. I'll open a ticket later on. I'm curious as to why php -i doesn't list the variable, however. (I usually set BLP in my Apache startup, though I wonder if Apache's setenv would work as well. Hmmm...)

Indeed, I have E_NOTICE enabled while I migrate from 5.4, as I still have no idea what to expect. Whether I lower the verbosity once we get to production remains to be seen, as there are lots pf older scripts which need testing under php 8.

(Just spent 3+ hours migrating the Apache 2.2 configs to 2.4 - not done, yet - and expect lots of extra logging there, too, until we get off the ground.)

Thanks!

[Steven Levine]

In <22A61DA5-BE43-44E7...@2rosenthals.com>, on 08/05/22
at 09:19 PM, Lewis Rosenthal <lgros...@2rosenthals.com> said:

Hi,

>It might indeed be better limited to info, just to quell some of the
>noise. I'll open a ticket later on. I'm curious as to why php -i doesn't
>list the variable, however.

The answer to this question is to look at what

ext\standard\info.c:773
PHPAPI ZEND_COLD void php_print_info(int flag)

does. Think spagetti with embedded sauce. It's do-able, but will take
some copy/paste from the code for a variable that's already listed.

>(I usually set BLP in my Apache startup,
>though I wonder if Apache's setenv would work as well. Hmmm...)

Unlikely. BEGINLIBPATH may look like an environment variable, but it's
not.

>(Just spent 3+ hours migrating the Apache 2.2 configs to 2.4 - not done,
>yet - and expect lots of extra logging there, too, until we get off the
>ground.)

:-) The acid test will be when you stick a # in front of

LoadModule access_compat_module modules/accespat.dll

[Lewis G Rosenthal]

Hi...

On 08/05/22 11:11 pm, Steven Levine wrote:
> In <22A61DA5-BE43-44E7...@2rosenthals.com>, on 08/05/22
> at 09:19 PM, Lewis Rosenthal <lgros...@2rosenthals.com> said:
>
> Hi,
>
>> It might indeed be better limited to info, just to quell some of the
>> noise. I'll open a ticket later on. I'm curious as to why php -i doesn't
>> list the variable, however.
> The answer to this question is to look at what
>
> ext\standard\info.c:773
> PHPAPI ZEND_COLD void php_print_info(int flag)
>
> does. Think spagetti with embedded sauce. It's do-able, but will take
> some copy/paste from the code for a variable that's already listed.

Ah, gotcha.

>> (I usually set BLP in my Apache startup,
>> though I wonder if Apache's setenv would work as well. Hmmm...)
> Unlikely. BEGINLIBPATH may look like an environment variable, but it's
> not.

True. I tend to think of it as a variable which has a doppelganger. Likely
setting the variable there is already too late, as it would be disconnected
from its other half.

>> (Just spent 3+ hours migrating the Apache 2.2 configs to 2.4 - not done,
>> yet - and expect lots of extra logging there, too, until we get off the
>> ground.)
> :-) The acid test will be when you stick a # in front of
>
> LoadModule access_compat_module modules/accespat.dll
>

That's the goal, of course. :-)

[Paul Smedley]

Hey guys,

On 6/8/22 09:43, Steven Levine wrote:
> In <4db48fba-458e-c76f...@smedley.id.au>, on 08/06/22
> at 09:23 AM, Paul Smedley <pa...@smedley.id.au> said:
>
> Hi Paul,
>
>> Spotted something in php.m4 - rebuilding now - might be fixed in 8.1.9 :P
>
> That looks like the place that needs to change.

PHP 8.1.9 should fix this (hopefully).

Cheers,

Paul

[Lewis G Rosenthal]

Hey, Paul!

Confirmed fixed in 8.1.9 20220806.

Thanks!

[Paul Smedley]

Hey Guys,

On 6/8/22 09:49, Steven Levine wrote:
> In <62EDA2A2...@2rosenthals.com>, on 08/05/22
> at 07:07 PM, Lewis G Rosenthal <lgros...@2rosenthals.com> said:
>
> Hi,
>
>> Indeed, I was aware of the change (though not the code, until now; thanks
>> for the ref). If BEGINLIBPATH has already been set before starting php,
>> the report is a tad different (as expected):
>
>> PHP Notice: PHP Startup: update_beginlibpath set BEGINLIBPATH to
>> modules;%BEGINLIBPATH% in Unknown on line 0
>
>> I suspect the "in Unknown on line 0" is misleading, but without seeing
>> evidence of BEGINLIBPATH in the php info report, I'm suspicious that this
>> is actually doing what we expect.
>
> It's working as intended. Try running without the php extensions
> directory in LIBPATH. It will fail for the extensions that reference
> other extension DLLs.
>
> I agree that the error reporting is annoying. The "Unknown on line 0"
> means that the report is not related to a specific script and line number.
> I don't know how to suppress addenda.
>
> I'm fine with moving the output to php_info, which is already plenty
> versbose. Please submit a ticket so the idea does not get forgotten. If
> Paul want's to disable the current reporting, I'm fine with that too. I
> needed the reporting when debugging, but that time is past.

The change from https://github.com/psmedley/php-os2/pull/35 is included
in the following build.

https://smedley.id.au/tmp/php-8.1.9-os2-debug-20220808.zip

Cheers,

Paul

[Steven Levine]

In <081f075c-2b6f-d92a...@smedley.id.au>, on 08/08/22
at 06:23 PM, Paul Smedley <pa...@smedley.id.au> said:

Hi,

>>> PHP Notice: PHP Startup: update_beginlibpath set BEGINLIBPATH to
>>> modules;%BEGINLIBPATH% in Unknown on line 0

>The change from https://github.com/psmedley/php-os2/pull/35 is included
>in the following build.

>https://smedley.id.au/tmp/php-8.1.9-os2-debug-20220808.zip

The log message is gone, but for some reason I cannot yet see, the
BEGLINLIBPATH value is not getting reported. The DosQueryExtLIBPATH() is
running without errors, but the kernel is returning a NULL string. Very
odd.

Paul, it seems that the 8.1.9 builds are missing debug info for the php
sources. Can you fix this when you have a moment?

Thanks,

[Paul Smedley]

Hey Guys,

On 9/8/22 08:43, Steven Levine wrote:
> In <081f075c-2b6f-d92a...@smedley.id.au>, on 08/08/22
> at 06:23 PM, Paul Smedley <pa...@smedley.id.au> said:
>
> Hi,
>
>>>> PHP Notice: PHP Startup: update_beginlibpath set BEGINLIBPATH to
>>>> modules;%BEGINLIBPATH% in Unknown on line 0
>
>> The change from https://github.com/psmedley/php-os2/pull/35 is included
>> in the following build.
>
>> https://smedley.id.au/tmp/php-8.1.9-os2-debug-20220808.zip
>
> The log message is gone, but for some reason I cannot yet see, the
> BEGLINLIBPATH value is not getting reported. The DosQueryExtLIBPATH() is
> running without errors, but the kernel is returning a NULL string. Very
> odd.
>
> Paul, it seems that the 8.1.9 builds are missing debug info for the php
> sources. Can you fix this when you have a moment?

https://smedley.id.au/tmp/php-8.1.9-os2-debug-20220809.zip

Cheers,

Paul

[Steven Levine]

In <d23c083d-82d2-c52d...@smedley.id.au>, on 08/09/22

at 07:14 PM, Paul Smedley <pa...@smedley.id.au> said:

Hi,

>> The log message is gone, but for some reason I cannot yet see, the
>> BEGLINLIBPATH value is not getting reported. The DosQueryExtLIBPATH() is
>> running without errors, but the kernel is returning a NULL string. Very
>> odd.

>https://smedley.id.au/tmp/php-8.1.9-os2-debug-20220809.zip

Thanks.

I figured out the BEGINLIBPATH issue. It's the kernel's somewhat wierd
parsing rules and errors that are not reported as errors. The former is
typical. The later, not so much, but it happens.

When running php test builds, I was using

extension_dir = "modules/"

which is handy for testing. For production, php.ini will have full paths.
However, since DosSetExtLIBPATH does not like forword slashes and trailing
slashes this gets mapped to modules and DosSetExtLIBPATH silently ignores
this. The path component must have at least one colon or backslash, so

extension_dir = "./modules/"

will work as expected because it gets mapped to .\modules. With this php
-c. -i reports:

APR_DSOPATH => modules
BEGINLIBPATH => .\modules;

Note APR_DSOPATH does not need to be decorated because it is not passed to
DosSetExtLIBPATH.

[Lewis]

Hi...

On 08/10/22 12:31 pm, Steven Levine wrote:
> In <d23c083d-82d2-c52d...@smedley.id.au>, on 08/09/22
> at 07:14 PM, Paul Smedley <pa...@smedley.id.au> said:
>
> Hi,
>
>>> The log message is gone, but for some reason I cannot yet see, the
>>> BEGLINLIBPATH value is not getting reported. The DosQueryExtLIBPATH() is
>>> running without errors, but the kernel is returning a NULL string. Very
>>> odd.
>> https://smedley.id.au/tmp/php-8.1.9-os2-debug-20220809.zip
> Thanks.
>
> I figured out the BEGINLIBPATH issue. It's the kernel's somewhat wierd
> parsing rules and errors that are not reported as errors. The former is
> typical. The later, not so much, but it happens.
>
> When running php test builds, I was using
>
> extension_dir = "modules/"
>
> which is handy for testing. For production, php.ini will have full paths.
> However, since DosSetExtLIBPATH does not like forword slashes and trailing
> slashes this gets mapped to modules and DosSetExtLIBPATH silently ignores
> this. The path component must have at least one colon or backslash, so
>
> extension_dir = "./modules/"
>
> will work as expected because it gets mapped to .\modules. With this php
> -c. -i reports:
>
> APR_DSOPATH => modules
> BEGINLIBPATH => .\modules;
>

Aha! :-D

> Note APR_DSOPATH does not need to be decorated because it is not passed to
> DosSetExtLIBPATH.
>

Right-o. Good catch.

--
Lewis