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.

In article <uts93j$16m5n$1@dont-email.me>, seaohveh@hoffmanlabs.invalid
(Stephen Hoffman) wrote:

> Examples of alternatives and tooling mentioned in my earlier reply,
> too. And Linux is a mess here, too. This is not an easy problem.
>
> OpenVMS is limited here both by its compatibility goals, and as
> this and related areas are seemingly "below the fold" when
> investing time and effort on the platform.

This is very educational: I'm learning about the origins of my employer's
very painstaking maintenance methods for shared library interfaces. Those
started on VAX VMS and have been applicable to every other platform we've
supported. They do require regarding the API compatibility as a
fundamental feature, never to be busted without a very good reason.

John

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.

Linux has symbol versioning; Windows lacks it, although it has a bodged
solution for the C/C++ run-time.

John