[much snippage] > but if I use the Multinet headers and routines I get the correct length of 4:
> $ cc/prefix=all socktest/define=MULTINET_SOCKETS > $ link socktest, sys$input:/opt > MULTINET:MULTINET_SOCKET_LIBRARY.EXE/SHARE > ^Z > $ run socktest > 70100022 > localhost > 2 > 4 > (null) > (null) > Making use of this will be a bit of a mess since configure.com will have to > detect Multinet and define the MULTINET_SOCKETS macro. Then probably > sockadapt.h will have to be modified to include the alternate headers when > the macro is defined. Then one of the linker options files (I'm not sure > which one) will need to have a line added to link against the Multinet > socket library. Any takers? I have to advise extreme caution here. Here's a response from Hunter Goatley of Process Software about the Multinet-provided C headers files (in the context of compiling lynx 2.8.2): =============================================================== Date: Wed, 27 Mar 2002 20:39:15 -0600 (CST) From: Hunter Goatley <[EMAIL PROTECTED]> Subject: Re: Compiling LYNX2-8-2 with WASD? To: Jeremy Begg <[EMAIL PROTECTED]> Cc: Alan Winston - SSRL Central Computing <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Content-type: TEXT/PLAIN; CHARSET=us-ascii > Some years ago, when TGV still existed and developed MultiNet, I was told > by them to ignore MultiNet's '#include' files and just use the "standard" > ones (i.e. TCP/IP Services libraries) which are now shipped with VMS. The > MultiNet definition files hadn't been updated to keep them suitable for > modern compilers. Primarily because trying to keep up with all the changes in each release of DEC C for the past 8 or so years would require a full-time person---and they'd be insane by now. 8-) As Jeremy says, build it as if for UCX and all should be fine (though you may have to modify one module to point to MultiNet's copy of UCX$INETDEF.H). ==================================================================== So the vendors of Multinet aren't actually encouraging you to use those header files and don't guarantee they will even compile with modern versions of DECC. -- Alan =============================================================================== Alan Winston --- [EMAIL PROTECTED] Disclaimer: I speak only for myself, not SLAC or SSRL Phone: 650/926-3056 Paper mail to: SSRL -- SLAC BIN 99, 2575 Sand Hill Rd, Menlo Park CA 94025 ===============================================================================
