FW: Installation of tzcode1999e_tar.gz and tzdata1999e_tar.gz
guy at netapp.com
Tue Sep 7 22:17:45 UTC 1999
> cc: "localtime.c", line 1260: warning 527: Integral value implicitly converted
> to pointer in assignment.
The problem here is probably that the time zone code depends on the
native OS's header files to declare the "standard" functions, such as
"localtime()" - and "localtime_r()".
The "/usr/include/time.h" on an HP-UX 11.0 system here is defined if the
right collection of 50,000 #defines are pre-defined; it appears that:
must all be defined. I'm not sufficiently familiar with HP-UX to know
what we should be doing to define them.
> /usr/ccs/bin/ld: (Warning) At least one PA 2.0 object file (date.o) was
> detected. The linked output may not run on a PA 1.x system.
Was this compiled on a 32-bit (PA-RISC 1.x) or 64-bit (PA-RISC 2.0)
> But up to here, everything is OK (every executable is in the right place,
> under the /usr/local/ directory, and the PATH variable is set correctly).
> I set the TZ variable to, for example, America/New_York and the date
> command doesn't give me the right time.
What does it give *instead* of the right time?
Are the data files installed in "/etc/zoneinfo" (or whatever directory
was chosen as "TZDIR")?
> I have checked the file /usr/bin/locale and it's a PA-RISC1.1 shared
> executable dynamically linked. Maybe that's the problem.
In what way is "/usr/bin/locale" involved here? If it's not involved,
it's probably not the problem.
> Nevertheless, the directory /usr/lib/locale and its subdirectories don't
That should affect only the "strftime()" that comes with the time zone
package, which means it might affect the format of the "date" command's
output *IF* it's given a date format argument, but it shouldn't affect
the actual time.
More information about the tz