lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

lynx-dev bzero() on VMS (was something meaningless)


From: Philip Webb
Subject: lynx-dev bzero() on VMS (was something meaningless)
Date: Sun, 10 May 1998 09:59:12 -0400 (EDT)

980510 FM wrote concerning TD's handling of the following problem:
>>   extern int bzero(); 
>>   .................^ 
>>   %CC-W-TOOFEWACTUALS, Too few actual parameters in macro call. 
>>   at line number 292 in file 
>>   DKA200:[LYNX.LYNX2-8.WWW.LIBRARY.IMPLEMENTATION]TCP.H;1
> This was explained in the PROBLEMS file through v2.7.2,
> with emphasis in the INTALLATION file that VMSers read it.
> there are extensive comments in the for-VMS-with-MultiNet sections of tcp.h
> to guide people in acting on what is explained in the PROBLEMS file.
> Al, at my request, has included a prominent entry for this in his VFAQ.
> -- remainder snipped --
 
whether or not this is fair, it's not very accurate.

PROBLEMS 2-7 has the following paragraph:

  On VMS, Lynx & other TCP-IP software, have been experiencing
  chronic problems of incompatibilites between DECC and MultiNet headers
  whenever new versions of either DECC or MultiNet are released.
  The Lynx build procedure for VMS & a maze of spaghetti #ifdef-ing in tcp.h
  of the libwww-FM had previously been successful in dealing with this problem
  across all versions of MultiNet & of DECC, VAXC & Pat Rankin's VMS port
  of GNUC, but are now not 100% successful.  If you get compiler messages
  about "struct timeval timeout" having no linkage, add this immediately
  below the inclusion of ioctl.h for MultiNet in tcp.h:
  
    [...]
    #include "multinet_root:[multinet.include.sys]ioctl.h"
    struct timeval {
        long tv_sec;            /* seconds since Jan. 1, 1970 */
        long tv_usec;           /* microseconds */
    };
    [...]
    
  For the most current versions of MultiNet,
  you can modify tcp.h to use the DECC socket and related headers.

there is nothing here which relates to the compile problem in question,
except the reference to  tcp.h ; this PROBLEMS paragraph is very cryptic
& would do nothing to help ordinary users solve their particular problem:
it looks as if it needs a thorough update by a VMSer.

i see nothing in INSTALLATION 2-7 relating to this, let alone emphasis.

 tcp.h  is not to be found as a separate file in the 2-7 package
& there is nothing in PROBLEMS or INSTALLATION to tell users
where to find it, so that they can insert whatever fixes are called for.

`Al's Picks' has an entry for the problem mentioned in PROBLEMS,
but it simply refers readers to an URL `PROBLEMS', which is "not found",
ie  www.slcc.edu/lynx/fote/lynx2-7-1/PROBLEMS .

i don't believe it's fair to expect any co-ordinator to keep in mind
all the oddities of all the platforms Lynx has been ported to;
the co-ordinator must be able to rely on communal expertise
& currently VMS seems not to be well represented among lynx-devers.

-- 
========================,,============================================
SUPPORT     ___________//___,  Philip Webb : address@hidden
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto

reply via email to

[Prev in Thread] Current Thread [Next in Thread]