At 8:53 AM -0500 9/24/07, John E. Malmberg wrote: >This is not the first time I have brought this up on this list, and the last >time no one admitted to using this build option on VMS.
Not everyone subscribes to every list. The person most likely to need SOCKETSHR support is someone on an older (like pre v7.0) version of VMS who suddenly discovers they need a relatively recent version of Perl and have to try to get it to build with whatever they have at hand. This hypothetical person is perhaps a consultant called in to make a machine that's been sitting in a corner for fifteen years talk to the outside world, and such a person, even if reading this message right now, might well not anticipate needing the support that you are proposing to deprecate. >The Configure.com has options to build Perl with SOCKETSHR/NETLIB libraries >instead of the CRTL libraries. > >This is only used for CMU-IP. It is not used for any other TCP/IP program >available on VMS. Except Pathway and Multinet and TCPWare and TCP/IP services, or that's what the NETLIB documentation says, and the SOCKETSHR documentation says it's based on NETLIB. It's true that the actively-maintained stacks from Process and HP can all use the CRTL interfaces, at least on VMS v7.0 and later (was that the turning point?), but that's optional. >As CMU-IP is effectively stuck at VAX/VMS 6.x, because it is missing the >source for critical bug fixes needed to rebuild it, I really doubt that it is >in much use. > >All the other TCP/IP product libraries are dynamically loaded by the CRTL if >needed. They can be, for current and not-so-current versions of VMS, but the vendor-specific APIs are still there. I can't say with any certainty that no one building Perl in the future will ever need to use them. The default is to use the CRTL interfaces, and that's obviously what most folks should do and will do, but I see no reason to remove other options. >I do not think it has been possible for at least the last 6 years to even >build Perl with socketshr support. > >I am recommending that unless someone speaks up soon that they are building >and testing current Perls with support for CMU-IP, that support for >SOCKETSHR/NETLIB be dropped from configure. I vote to leave well enough alone. It costs nothing to maintain and the effort expended to rip out the existing support would be much better spent fixing bugs or adding new features. >I also am recommending that the option to build without socket support also be >dropped, since the CRTL already returns the expected ENOSYS error code when >the socket routines are called on a system with out socket support. It's true that making sockets optional was something done originally because a TCP/IP stack is an add-on on VMS and the C run-time did not yet at that time support socket calls when no TCP/IP product was installed. But since we offered the option, other reasons to use it have occurred to people. Such as configuring Perl without socket support in a secure environment so you can be sure Perl programs aren't talking on the network. And who knows what other reasons people might have. If you don't like the option don't use it; having it there is barely noticeable if you don't use it, but I see no reason to arbitrarily drop support for something that's been there for a long time and has never gotten in the way that I recall. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
