On Wed, 2024-03-27 at 13:51 +0000, Simon Clubley wrote:
> Linux isn't perfect in this regard either.
>
> The earliest "fun" I remember in this area was the move from the
> .so.5 version of the C++ (not C) ABI to the .so.6 version.
>
> This was especially "fun" when you tried to install/build a more
> modern gcc (then use it to build programs) on a version of Linux that
> was using .so.5 for its own C++ libraries.

I had to manually patch and build my way from libc5 to glibc2. Nerve
wracking but worth it.
--
Tactical Nuclear Kittens

On 3/27/2024 10:14 AM, John Dallman wrote:
> In article <uu188n$2s5jm$4@dont-email.me>,
> clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
>
>> Linux isn't perfect in this regard either.
>>
>> The earliest "fun" I remember in this area was the move from the
>> .so.5 version of the C++ (not C) ABI to the .so.6 version.
>
> Yup. The .so.X scheme is for version numbers of the library's ABI. Enough
> people fooled themselves that was adequate for the .5 to .6 change to
> cause serious difficulties.
>
> It's notable that the GCC and glibc projects responded with the "version
> every signature change of each symbol" they use now, meaning that the
> .so.6 version of the C++ ABI is likely to continue forever. However, this
> (a) requires scrupulous attention to detail and (b) requires an OS with
> symbol versioning support built into the linker, loader, etc.

For those very interested in details:
https://www.cs.dartmouth.edu/~sergey/cs258/ABI/UlrichDrepper-How-To-Write-Shared-Libraries.pdf

Arne

On Wed, 2024-03-27 at 11:06 -0400, Arne Vajhøj wrote:
>
> For those very interested in details:
>  
> https://www.cs.dartmouth.edu/~sergey/cs258/ABI/UlrichDrepper-How-To-Write-Shared-Libraries.pdf

Ooh, Ulrich Drepper. Blast from the past indeed. Famously rage quit
because other glibc2 developers wanted to take the glibc library in
another direction.
--
Tactical Nuclear Kittens

On 3/23/24 5:36 PM, Arne Vajhøj wrote:
> On 3/20/2024 8:18 PM, Arne Vajhøj wrote:
>> On 3/20/2024 5:39 PM, Mark Berryman wrote:
>>> The more recent kits split out the extensions that depend on a
>>> particular layered product version as loadable extensions rather than
>>> building them into the phpshr.exe image.  PHP 8.1.23, for example, is
>>> linked against LDAP V2.6-6 (X86VMS-LDAP-V0206-6-1.ZIP).
>>
>> 8.1.23 works perfect.
>
> Pretty well anyway.
>
> My DIY stuff runs.
>
> I can get a ZF 3 app to run.
>
> But a Laravel 9 app gives me:
>
> $ php artisan serve
> zend_mm_heap corrupted

If you would, please define USE_ZEND_ALLOC to 0 and let me know if that
makes a difference.

Mark Berryman

On 3/27/2024 3:25 PM, Mark Berryman wrote:
> On 3/23/24 5:36 PM, Arne Vajhøj wrote:
>> On 3/20/2024 8:18 PM, Arne Vajhøj wrote:
>>> On 3/20/2024 5:39 PM, Mark Berryman wrote:
>>>> The more recent kits split out the extensions that depend on a
>>>> particular layered product version as loadable extensions rather
>>>> than building them into the phpshr.exe image.  PHP 8.1.23, for
>>>> example, is linked against LDAP V2.6-6 (X86VMS-LDAP-V0206-6-1.ZIP).
>>>
>>> 8.1.23 works perfect.
>>
>> Pretty well anyway.
>>
>> My DIY stuff runs.
>>
>> I can get a ZF 3 app to run.
>>
>> But a Laravel 9 app gives me:
>>
>> $ php artisan serve
>> zend_mm_heap corrupted
>
> If you would, please define USE_ZEND_ALLOC to 0 and let me know if that
> makes a difference.

It makes a difference. Instead of that error it just exits
without any error message.

:-(

$ php artisan serve
zend_mm_heap corrupted
$ USE_ZEND_ALLOC=0
$ php artisan serve
$

where the expected is:

C:\Work\VMS\lar3>php artisan serve

INFO Server running on [http://127.0.0.1:8000].

Press Ctrl+C to stop the server

Arne

On 3/27/2024 3:47 PM, Arne Vajhøj wrote:
> On 3/27/2024 3:25 PM, Mark Berryman wrote:
>> On 3/23/24 5:36 PM, Arne Vajhøj wrote:
>>> On 3/20/2024 8:18 PM, Arne Vajhøj wrote:
>>>> On 3/20/2024 5:39 PM, Mark Berryman wrote:
>>>>> The more recent kits split out the extensions that depend on a
>>>>> particular layered product version as loadable extensions rather
>>>>> than building them into the phpshr.exe image.  PHP 8.1.23, for
>>>>> example, is linked against LDAP V2.6-6 (X86VMS-LDAP-V0206-6-1.ZIP).
>>>>
>>>> 8.1.23 works perfect.
>>>
>>> Pretty well anyway.
>>>
>>> My DIY stuff runs.
>>>
>>> I can get a ZF 3 app to run.
>>>
>>> But a Laravel 9 app gives me:
>>>
>>> $ php artisan serve
>>> zend_mm_heap corrupted
>>
>> If you would, please define USE_ZEND_ALLOC to 0 and let me know if
>> that makes a difference.
>
> It makes a difference. Instead of that error it just exits
> without any error message.
>
> :-(
>
> $ php artisan serve
> zend_mm_heap corrupted
> $ USE_ZEND_ALLOC=0
> $ php artisan serve
> $
>
> where the expected is:
>
> C:\Work\VMS\lar3>php artisan serve
>
>    INFO  Server running on [http://127.0.0.1:8000].
>
>   Press Ctrl+C to stop the server

But it is not necessarily bad.

The new error (it is an error despite no error message)
could be a VMS permission / record format problem unlike
the "zend_mm_heap corrupted" error that looks like a
problem in C code.

Arne

On 2024-03-27, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> But it is not necessarily bad.
>
> The new error (it is an error despite no error message)
> could be a VMS permission / record format problem unlike
> the "zend_mm_heap corrupted" error that looks like a
> problem in C code.
>

If that's the case, you could try using the undocumented file watch
command that traces XQP access. That might give you some clues.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 3/27/2024 4:01 PM, Simon Clubley wrote:
> On 2024-03-27, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> But it is not necessarily bad.
>>
>> The new error (it is an error despite no error message)
>> could be a VMS permission / record format problem unlike
>> the "zend_mm_heap corrupted" error that looks like a
>> problem in C code.
>
> If that's the case, you could try using the undocumented file watch
> command that traces XQP access. That might give you some clues.

It gives a lot of output.

:-)

But I did see a few 0x00000910 (NOSUCHFILE).

So now I am wondering if a Laravel install is
platform specific.

I installed on Windows, zipped, transferred to
VMS and unzipped.

Does anyone know if composer runs on VMS?

Arne

On Wed, 27 Mar 2024 09:07:53 -0400, Arne Vajhøj wrote:

> VMS allows side by side installation using logicals.

Having to define different logical names before running each particular
executable just seems a clunky way of doing it.

On 3/27/2024 4:35 PM, Arne Vajhøj wrote:
> Does anyone know if composer runs on VMS?

Apparently not.

PHP Fatal error: Uncaught PharException: manifest cannot be larger than
100 MB in phar "/disk0/www/lar4/composer.phar" in /disk0/w
ww/lar4/composer.phar:28
Stack trace:
#0 /disk0/www/lar4/composer.phar(28): Phar::mapPhar('composer.phar')
#1 {main}
thrown in /disk0/www/lar4/composer.phar on line 28

Arne

On 3/27/2024 5:13 PM, Lawrence D'Oliveiro wrote:
> On Wed, 27 Mar 2024 09:07:53 -0400, Arne Vajhøj wrote:
>
>> VMS allows side by side installation using logicals.
>
> Having to define different logical names before running each particular
> executable just seems a clunky way of doing it.
>

In a decent implementation, the user environment sets up the logicals.
LOGIN.COM (or another command file) is part of the application.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 3/27/2024 4:35 PM, Arne Vajhøj wrote:
> On 3/27/2024 4:01 PM, Simon Clubley wrote:
>> On 2024-03-27, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> But it is not necessarily bad.
>>>
>>> The new error (it is an error despite no error message)
>>> could be a VMS permission / record format problem unlike
>>> the "zend_mm_heap corrupted" error that looks like a
>>> problem in C code.
>>
>> If that's the case, you could try using the undocumented file watch
>> command that traces XQP access. That might give you some clues.
>
> It gives a lot of output.

Which command did you use

$ set watch file /class = major
or
$ set watch file /class = all

I always start with the first command, and only
use the heavy hammer when needed.

--

--- Rob

On 3/27/2024 9:14 PM, Robert A. Brooks wrote:
> On 3/27/2024 4:35 PM, Arne Vajhøj wrote:
>> On 3/27/2024 4:01 PM, Simon Clubley wrote:
>>> On 2024-03-27, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> But it is not necessarily bad.
>>>>
>>>> The new error (it is an error despite no error message)
>>>> could be a VMS permission / record format problem unlike
>>>> the "zend_mm_heap corrupted" error that looks like a
>>>> problem in C code.
>>>
>>> If that's the case, you could try using the undocumented file watch
>>> command that traces XQP access. That might give you some clues.
>>
>> It gives a lot of output.
>
> Which command did you use
>
> $ set watch file /class = major
>              or
> $ set watch file /class = all
>
> I always start with the first command, and only
> use the heavy hammer when needed.

I also used MAJOR.

But Laravel is a big framework. One view, one controller
and two domain classes plus the framework is over 8700
files.

:-(

Arne

On Wed, 27 Mar 2024 21:42:16 -0400, Arne Vajhøj wrote:

> But Laravel is a big framework. One view, one controller and two domain
> classes plus the framework is over 8700 files.

I don’t think it does WebSockets.

On 3/27/2024 10:42 PM, Lawrence D'Oliveiro wrote:
> On Wed, 27 Mar 2024 21:42:16 -0400, Arne Vajhøj wrote:
>> But Laravel is a big framework. One view, one controller and two domain
>> classes plus the framework is over 8700 files.
>
> I don’t think it does WebSockets.

Not with just laravel/laravel.

But add beyondcode/laravel-websockets and it is ready.

Arne

On Wed, 27 Mar 2024 22:48:49 -0400, Arne Vajhøj wrote:

> On 3/27/2024 10:42 PM, Lawrence D'Oliveiro wrote:
>>
>> On Wed, 27 Mar 2024 21:42:16 -0400, Arne Vajhøj wrote:
>>>
>>> But Laravel is a big framework. One view, one controller and two
>>> domain classes plus the framework is over 8700 files.
>>
>> I don’t think it does WebSockets.
>
> Not with just laravel/laravel.
>
> But add beyondcode/laravel-websockets and it is ready.

Interesting that the WebSocket server seems to need its own listening port
<https://beyondco.de/docs/laravel-websockets/basic-usage/starting>. So
it’s not integrated into the regular HTTP control flow, the way a Python-
based ASGI framework would do.