PHP 8.1.8 lint

77 views
Skip to first unread message

Lewis G Rosenthal

unread,
Aug 5, 2022, 6:29:32 PM8/5/22
to Apache2 Mailing List
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

unread,
Aug 5, 2022, 6:51:42 PM8/5/22
to apa...@googlegroups.com

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

unread,
Aug 5, 2022, 7:07:31 PM8/5/22
to apa...@googlegroups.com
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

unread,
Aug 5, 2022, 7:14:53 PM8/5/22
to apa...@googlegroups.com

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

unread,
Aug 5, 2022, 7:53:27 PM8/5/22
to apa...@googlegroups.com
Hey Guys
Spotted something in php.m4 - rebuilding now - might be fixed in 8.1.9 :P

Steven Levine

unread,
Aug 5, 2022, 7:55:15 PM8/5/22
to apa...@googlegroups.com
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

unread,
Aug 5, 2022, 7:59:05 PM8/5/22
to apa...@googlegroups.com
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

unread,
Aug 5, 2022, 8:10:46 PM8/5/22
to apa...@googlegroups.com
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

unread,
Aug 5, 2022, 8:18:01 PM8/5/22
to apa...@googlegroups.com
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

unread,
Aug 5, 2022, 8:25:00 PM8/5/22
to Apache OS/2
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

unread,
Aug 5, 2022, 8:28:20 PM8/5/22
to apa...@googlegroups.com
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

unread,
Aug 5, 2022, 9:19:12 PM8/5/22
to apa...@googlegroups.com
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

unread,
Aug 5, 2022, 11:25:52 PM8/5/22
to apa...@googlegroups.com
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

unread,
Aug 5, 2022, 11:57:41 PM8/5/22
to apa...@googlegroups.com
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

unread,
Aug 6, 2022, 5:57:39 AM8/6/22
to apa...@googlegroups.com
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

unread,
Aug 6, 2022, 7:21:02 PM8/6/22
to apa...@googlegroups.com
Hey, Paul!
Confirmed fixed in 8.1.9 20220806.

Thanks!

Paul Smedley

unread,
Aug 8, 2022, 4:53:33 AM8/8/22
to apa...@googlegroups.com
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

unread,
Aug 8, 2022, 7:20:53 PM8/8/22
to apa...@googlegroups.com
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 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

unread,
Aug 9, 2022, 5:44:11 AM8/9/22
to apa...@googlegroups.com

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

unread,
Aug 10, 2022, 12:59:12 PM8/10/22
to apa...@googlegroups.com
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

unread,
Aug 10, 2022, 1:08:52 PM8/10/22
to apa...@googlegroups.com
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

Reply all
Reply to author
Forward
0 new messages