priol@irisa.UUCP ( Equipe Hypercubes) (10/25/88)
I try to port X11 on an PC/AT386 running Unix V.3 (It is an iPSC/2 hypercube host processor). libX11.a, libXaw.a now work on this machine, but i have a problem to implement the toolkit on UNIX V.3 because the BSD Gettimeofday() call does not exist and i have not found an equivalent call. Is there somebody solve this problem ? Thierry PRIOL -- Thierry PRIOL Phone: 99 36 20 00 IRISA Fax: 99 38 38 32 Campus Universitaire de Beaulieu Telex: UNIRISA 950 473F 35042 RENNES CEDEX - FRANCE E-mail: priol@irisa.fr
tom@ICASE.EDU (Tom Crockett) (10/26/88)
> Gettimeofday() call does not exist ....
You should be able to use the System V "localtime()" function (in my SVR2
manual it's documented under ctime(3c)) to achieve the same effect, with
minor modifications to the code. There are also some other handy routines:
gmtime, timezone, and daylight. The latter two are external variables,
actually. One possible drawback: the resolution on localtime is +- 1 second.
Tom Crockett
--------------------------------------------------------------------------------
Institute for Computer Applications in Science and Engineering
M.S. 132C, NASA Langley Research Center
Hampton, VA 23665
e-mail: tom@icase.edu phone: (804) 865-4097
--------------------------------------------------------------------------------"priol@tokaido.irisa.fr (10/28/88)
Thanks for you answer to my question, but the main problem is the resolution of the clock on a system V and i think the toolkit library of X11 need a better resolution. For the moment i use the ctime() function. Thierry PRIOL
guy@auspex.UUCP (Guy Harris) (10/28/88)
>> Gettimeofday() call does not exist .... > >You should be able to use the System V "localtime()" function (in my SVR2 >manual it's documented under ctime(3c)) to achieve the same effect, Presumably you meant "time()". "localtime()", under BSD, System V, and just about every other UNIX system, does the same thing; it converts a "UNIX time" value of "seconds since the Epoch" to a local date/time in the form of a multi-radix number. >There are also some other handy routines: gmtime, timezone, and >daylight. The latter two are external variables, actually. And provide the moral equivalent of the "timezone" information that "gettimeofday" stuffs into the structure pointed to by its second argument, if that argument is non-NULL. >One possible drawback: the resolution on localtime is +- 1 second. If this is not a problem, the code should be rewritten to use "time()" EVEN ON BSD SYSTEMS; "time()" works quite well, and is more portable. If this is a problem, then if the only reason they care about sub-second resolution is to find the elapsed time betwen two events with sub-second resolution, they can get sub-second time stamps from "times()" (the stamps are relative to some arbitrary time that may not be the same across reboots, so saving those times into a file won't work). If they really want wall-clock time down to sub-second resolution, they lose.