Mailing List Archive

On Sat, Jun 16, 2018 at 11:48 PM, NormW <normw@gknw.net> wrote:
> GD,
> Attached is a 'Readme' file I wrote back when Perl 5.8.9 was still new, and
> had, with help from a patched 5.8.4 from Novell engineers, been able to
> build Perl 5.8.9 using LibC, and run MOST of the tests successfully on a
> NetWare v6 box. (There's a test summary in the attached file).
> Thus encouraged, I put the build up on a friend's website as another
> open-source NetWare project.
> I still have the original 5.8.4 port to LibC, and periodically update the
> diffs such that I can build 5.28.0 for Novell's LibC. After some head
> banging can again build the documents in html format.
>
> The .\NetWare directory in the Perl source tree was code also supplied by
> Novell engineers, but the CLib C library it was intended for was superceded,
> then the staff that did the port (in India) were made redundant, and finally
> Novell suffered a similar fate.
>
> NetWare was intended solely as a network-server, so the few failures are
> not so bad, having regard to its first Perl test attempt (that I know of)
> with LibC.
>
> Wether there is any desire (or need) to upgrade the Perl NetWare source is
> the crux of the question. If upgrading, I also have a GNU Makefile that can
> get Perl/Libperl built. I use OWC as the compiler but my Makefile also
> supports a Public Domain GCC port that was tweaked to handle the NetWare way
> of doing things.

It seems to me that if what's in the NetWare directory now cannot work
with current Perl and/or latest Netware but can be replaced by
something that does, then it should be replaced with what you've got.
That should include removing anything vestigial that is no longer
applicable as well as adding/changing whatever needs to be. Anything
removed would still be present in older maintenance branches if anyone
ever wanted to go looking for it.

Can you submit patches? It would be highly preferable to see a series
of smallish patches, one for each coherent set of changes, and this
would especially apply to any changes outside the NetWare directory.

On 23/06/2018 1:42 AM, Craig A. Berry wrote:
> On Sat, Jun 16, 2018 at 11:48 PM, NormW <normw@gknw.net> wrote:
>> GD,
>> Attached is a 'Readme' file I wrote back when Perl 5.8.9 was still new, and
>> had, with help from a patched 5.8.4 from Novell engineers, been able to
>> build Perl 5.8.9 using LibC, and run MOST of the tests successfully on a
>> NetWare v6 box. (There's a test summary in the attached file).
>> Thus encouraged, I put the build up on a friend's website as another
>> open-source NetWare project.
>> I still have the original 5.8.4 port to LibC, and periodically update the
>> diffs such that I can build 5.28.0 for Novell's LibC. After some head
>> banging can again build the documents in html format.
>>
>> The .\NetWare directory in the Perl source tree was code also supplied by
>> Novell engineers, but the CLib C library it was intended for was superceded,
>> then the staff that did the port (in India) were made redundant, and finally
>> Novell suffered a similar fate.
>>
>> NetWare was intended solely as a network-server, so the few failures are
>> not so bad, having regard to its first Perl test attempt (that I know of)
>> with LibC.
>>
>> Wether there is any desire (or need) to upgrade the Perl NetWare source is
>> the crux of the question. If upgrading, I also have a GNU Makefile that can
>> get Perl/Libperl built. I use OWC as the compiler but my Makefile also
>> supports a Public Domain GCC port that was tweaked to handle the NetWare way
>> of doing things.
>
> It seems to me that if what's in the NetWare directory now cannot work
> with current Perl and/or latest Netware but can be replaced by
> something that does, then it should be replaced with what you've got.
> That should include removing anything vestigial that is no longer
> applicable as well as adding/changing whatever needs to be. Anything
> removed would still be present in older maintenance branches if anyone
> ever wanted to go looking for it.
>
> Can you submit patches? It would be highly preferable to see a series
> of smallish patches, one for each coherent set of changes, and this
> would especially apply to any changes outside the NetWare directory.
>
GM,
And thanks Craig for your reply.
It would be a wrong to interpret my intent as saying the NetWare Clib
doesn't work. The Novell people brought out LibC because it was more
standards compliant for the time. The first releases of Perl on NetWare
were Clib-based and I would guess they worked without issue.
The major question I think is 'Is anyone working on the Clib version'?
If people are working on the CLib version (patches,etc) and can build
it, there is, I think, little point in cluttering up your source code.
To see what I mean, will add here the diff from 5.8.4 which was taken
against the original 5.8.4 release and a zip of patches that I use on
current releases. Because LibC does things differently to Clib, the zip
defines NETWARE, NETWARE_LIBC & NETWARE_CLIB which is likely not kind to
your source (The NETWARE define in my patches is common to both). The
red bits in the 5.8.4 diff is what Novell removed from your source to
change it to LibC, and used the NETWARE define for its new library. The
0 bytes diffs exist as I use a .bat file to apply, and there's fewer
complaints from the bat file.

Norm

(To paraphrase a meme, "It's an old thread, but it checks out")

On Sun, Jun 24, 2018 at 01:48:52PM +1000, NormW wrote:

> GM,
> And thanks Craig for your reply.
> It would be a wrong to interpret my intent as saying the NetWare Clib
> doesn't work. The Novell people brought out LibC because it was more
> standards compliant for the time. The first releases of Perl on NetWare were
> Clib-based and I would guess they worked without issue.
> The major question I think is 'Is anyone working on the Clib version'?
> If people are working on the CLib version (patches,etc) and can build it,
> there is, I think, little point in cluttering up your source code. To see
> what I mean, will add here the diff from 5.8.4 which was taken against the
> original 5.8.4 release and a zip of patches that I use on current releases.
> Because LibC does things differently to Clib, the zip defines NETWARE,
> NETWARE_LIBC & NETWARE_CLIB which is likely not kind to your source (The
> NETWARE define in my patches is common to both). The red bits in the 5.8.4
> diff is what Novell removed from your source to change it to LibC, and used
> the NETWARE define for its new library. The 0 bytes diffs exist as I use a
> .bat file to apply, and there's fewer complaints from the bat file.

So, we now know the answer to 'Is anyone working on the Clib version'

No! Confidently no.

The build of the NetWare port in the core will have been broken in Sept 2009
by commit b0e687f777617f7f - if it wasn't already broken.

See https://perl.markmail.org/thread/f5qhoxlw6fblcaul for explanation.

Hence it's been broken for (at least) 12 years and no-one has reported this.

As I stress in that e-mail

The port in NetWare/ has been broken since 2009 and no-one has noticed.
^^^^^^^^^^^^^^^^^^^^

I like your phrasing "not kind to your source". That port isn't. Removing it
looks like this:

131 files changed, 139 insertions(+), 19798 deletions(-)


There is stuff in how that port that just seems strange. For example

# ifdef NETWARE
# define CopFILE_set(c,pv) ((c)->cop_file = savepv(pv))
# define CopFILE_setn(c,pv,l) ((c)->cop_file = savepvn((pv),(l)))
# else
# define CopFILE_set(c,pv) ((c)->cop_file = savesharedpv(pv))
# define CopFILE_setn(c,pv,l) ((c)->cop_file = savesharedpvn((pv),(l)))
# endif


which seems to be fallout from this:

/* Shared memory macros */
#ifdef NETWARE

#define PerlMemShared_malloc(size) \
(*PL_Mem->pMalloc)(PL_Mem, (size))
#define PerlMemShared_realloc(buf, size) \
(*PL_Mem->pRealloc)(PL_Mem, (buf), (size))
#define PerlMemShared_free(buf) \
(*PL_Mem->pFree)(PL_Mem, (buf))
#define PerlMemShared_calloc(num, size) \
(*PL_Mem->pCalloc)(PL_Mem, (num), (size))
#define PerlMemShared_get_lock() \
(*PL_Mem->pGetLock)(PL_Mem)
#define PerlMemShared_free_lock() \
(*PL_Mem->pFreeLock)(PL_Mem)
#define PerlMemShared_is_locked() \
(*PL_Mem->pIsLocked)(PL_Mem)

#else

#define PerlMemShared_malloc(size) \
(*PL_MemShared->pMalloc)(PL_MemShared, (size))
#define PerlMemShared_realloc(buf, size) \
(*PL_MemShared->pRealloc)(PL_MemShared, (buf), (size))
#define PerlMemShared_free(buf) \
(*PL_MemShared->pFree)(PL_MemShared, (buf))
#define PerlMemShared_calloc(num, size) \
(*PL_MemShared->pCalloc)(PL_MemShared, (num), (size))
#define PerlMemShared_get_lock() \
(*PL_MemShared->pGetLock)(PL_MemShared)
#define PerlMemShared_free_lock() \
(*PL_MemShared->pFreeLock)(PL_MemShared)
#define PerlMemShared_is_locked() \
(*PL_MemShared->pIsLocked)(PL_MemShared)

#endif

Why was it done that way? How come it couldn't be done more simply by having
PL_Mem and PL_MemShared point to the same thing on Netware?


Seems that not enough review happened when the port was first worked on, to
try to get the changes and conditional code down when possible.



So, we'd love to integrate your porting work into the core, if it can be
done cleanly. We don't have access to NetWare, so we can't test whether
things like the code above could be simplified. Hence, the best way to do
this seems to be

1) We remove all the existing NetWare port
2) You locally put back the parts that you need (with one #define for your
port)
3) Send us patches and we'll try to merge them


I appreciate that this might well mean that you're putting back stuff that
we just took out, and that seems like a bunch of code churn and makework
[and you'll hate me for suggesting this plan :-)]

But my hunch is that your much cleaner port doesn't need a bunch of the
work around that the original port did, but that also it won't break *with*
many of them. So taking the "minimise churn" approach of trying to figure
out what can be removed won't get as much cleanup. Also, it's going to
take longer. The workflow for it is

10 "I don't think we need this. Let's try removing it..."
20 run the full testsuite
30 did something new break?
yes - revert
no - retain
40 GOTO 10


whereas the more brutal approach of "demolish and build afresh is" doesn't
need to run all the tests each time - one can iterate quite quickly with
miniperl and minitest until it that passes, and only then does one fill in
the gaps found by the rest of the code.


Also, we're intending to up the build requirements to the subset of C99
that is supported by current MSVC and the VMS vendor compiler
(gcc, clang and all the Unix vendor compilers we tested are not constraints)

Most importantly, this gets us

1) mixed declarations and code
2) 64 bit integer types (ie long long)

as best I can tell, OpenWatcom already supports what we need:

https://web.archive.org/web/20210329095056/http://wiki.openwatcom.org/index.php/C99_Compliance

so I don't think that this will be a problem

MSVC doesn't support variable length arrays, so we won't be using them.

Nicholas Clark