It exists.
But I am having a few "challenges".
The VSI kit works out of the box, but without mysqli support then it is
not that useful.
And I am having problems with the Berryman kit.
Specifically php_x86_7_4_28.zip where I have tried with both X86VMS-LDAP-V0205-15-1.ZIP and X86VMS-LDAP-V0206-6-1.ZIP but
always get:
$ php
%DCL-W-ACTIMAGE, error activating image LDAP$LIBLBER_SHR32
-CLI-E-IMGNAME, image file ARNE4$DKA0:[SYS0.SYSCOMMON.][SYSLIB]LDAP$LIBLBER_SHR32.EXE;1 -SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
Any suggestions for what version of Berryman PHP that works
with what version of VSI LDAP?
On 3/20/24 8:51 AM, Arne Vajhøj wrote:
It exists.
But I am having a few "challenges".
The VSI kit works out of the box, but without mysqli support then it
is not that useful.
And I am having problems with the Berryman kit.
Specifically php_x86_7_4_28.zip where I have tried with both
X86VMS-LDAP-V0205-15-1.ZIP and X86VMS-LDAP-V0206-6-1.ZIP but
always get:
$ php
%DCL-W-ACTIMAGE, error activating image LDAP$LIBLBER_SHR32
-CLI-E-IMGNAME, image file
ARNE4$DKA0:[SYS0.SYSCOMMON.][SYSLIB]LDAP$LIBLBER_SHR32.EXE;1
-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
Any suggestions for what version of Berryman PHP that works
with what version of VSI LDAP?
The 7.4.28 kit was built 2 years ago and was linked against LDAP V2.5-7 (VSI-X86VMS-LDAP-V0205-7-1.ZIP).
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).
Regarding all the link problems - would it be better
instead of xxxxxx.EXE to distribute xxxxxx.OLB and
LINK_xxxxxx.COM and let users link in their environment?
On Wed, 20 Mar 2024 20:18:31 -0400, Arne Vajhøj wrote:
Regarding all the link problems - would it be better
instead of xxxxxx.EXE to distribute xxxxxx.OLB and
LINK_xxxxxx.COM and let users link in their environment?
Interesting that, while VMS was a pioneer of shared libraries in the early days, it never progressed to developing library versioning.
On 3/20/2024 9:02 PM, Lawrence D'Oliveiro wrote:
early days, it never progressed to developing library versioning.
It did.
It exists.
But I am having a few "challenges".
The VSI kit works out of the box, but without mysqli support then it is
not that useful.
On 3/20/2024 10:40 PM, Lawrence D'Oliveiro wrote:
On Wed, 20 Mar 2024 21:36:05 -0400, Arne Vajhøj wrote:
On 3/20/2024 9:02 PM, Lawrence D'Oliveiro wrote:
early days, it never progressed to developing library versioning.
It did.
It’s supposed to solve problems with linking with incompatible libraries.
It refuses to load the executable when only an incompatible
library is present. It does not by magic download a compatible
library.
On Wed, 20 Mar 2024 21:36:05 -0400, Arne Vajhøj wrote:
On 3/20/2024 9:02 PM, Lawrence D'Oliveiro wrote:
early days, it never progressed to developing library versioning.
It did.
It’s supposed to solve problems with linking with incompatible libraries.
It does not by magic download a compatible library.
On Wed, 20 Mar 2024 21:36:05 -0400, Arne Vajhøj wrote:
On 3/20/2024 9:02 PM, Lawrence D'Oliveiro wrote:
early days, it never progressed to developing library versioning.
It did.
It’s supposed to solve problems with linking with incompatible libraries.
It’s supposed to solve problems with linking with incompatible
libraries.
Which is exactly what has happened here. An incompatible shareable image library was found in the default path, and its activation violated the
rules the developers provided to the linker, and the activation was
blocked.
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.
On Sat, 23 Mar 2024 12:23:14 -0400, Stephen Hoffman wrote:
It’s supposed to solve problems with linking with incompatible
libraries.
Which is exactly what has happened here. An incompatible shareable
image library was found in the default path, and its activation
violated the rules the developers provided to the linker, and the
activation was blocked.
What happened here is known as “DLL hell”. So you see, it’s something else Windows inherited from VMS.
OpenVMS does not do well around installations and upgrades and parallel versions, with various apps chosing their own paths here, and OpenVMS
itself chosing different paths in different cases.
On Sun, 24 Mar 2024 11:30:17 -0400, Stephen Hoffman wrote:
OpenVMS does not do well around installations and upgrades and parallel
versions, with various apps chosing their own paths here, and OpenVMS
itself chosing different paths in different cases.
Like I said, while VMS was a pioneer of shared libraries in the early
days, it never progressed to developing library versioning. Which (I
didn’t make clear before, I assumed it was understood) nowadays means
being able to cope with transitioning between versions.
It’s not just Linux that has a solution to this problem: the BSDs do,
too, and I believe their solution predated Linux.
Back when VMS was new, the Unixes were still trying to come to terms
with shared libraries. But they have long since surpassed the pioneer
in this regard.
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.
They do require regarding the API compatibility as a fundamental
feature, never to be busted without a very good reason.
Linux is a mess here, too.
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.
On Mon, 25 Mar 2024 12:34:59 -0400, Stephen Hoffman wrote:
Linux is a mess here, too.
The *nixes manage to cope with greater complexity than VMS can manage.
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
ABI and API stability avoids a whole lot of churn elsewhere in the
general configuration, yes.
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
:-(
On 3/25/2024 4:22 PM, John Dallman wrote:
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.
Ok, a confession. I have a database product which has a couple RTLs and
a couple files for linking. I attribute my placing them in SYS$SHARE to laziness. Guilty as charged. However, with logical names on VMS it is rather trivial to associate RTLs and such with particular applications.
After all, the developers should have to do some work.
As a general concept, the RTLs, DLLs, and such that are developer and/or
used with a particular application are indeed part of that application. Storage should no longer be an issue. My first DEC system was a
PDP11-40 RSTS system with 8 RKK05 disk drives. Each was 2000 blocks. Thought it was great, at the time. Today we have multi-terabyte
drives. While old habits die slowly, my opinion is use whatever storage (and memory) is required to have a well ordered application
installation. Bundle the complete application as a single entity.
While some may feel that VMS (and others) should have tools to address
such, I've found that logical names can do the job. And some work by
the developer.
VMS got the version check in the image activator.
VMS allows side by side installation using logicals.
Could VMS do more? Yes. But I don't think there is a good
case to do more. The message from VMS users seems to be
that they want less not more in this area. The "please
maintain backwards compatibility and disable the version
check and I will just upgrade to latest and greatest and
it should work" seems to be what the customers want.
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.
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.
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
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.
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
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.
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.
VMS allows side by side installation using logicals.
Does anyone know if composer runs on VMS?
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: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.
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.
But Laravel is a big framework. One view, one controller and two domain classes plus the framework is over 8700 files.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 434 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 128:00:48 |
| Calls: | 9,113 |
| Calls today: | 7 |
| Files: | 13,422 |
| Messages: | 6,031,828 |