linking problems with tz-1994e `date' on Solaris 2.3

[Guy Harris]

> A point of curiosity: Sun's strftime invokes mktime, which is tz's
> mktime in this case.

Are you certain that it's not calling the 5.x "mktime()"?  See below....

> Perhaps Sun's strftime expects something out of
> mktime that tz's mktime does not provide.  I wonder why it calls
> mktime at all?

5.x doesn't have "tm_zone" nor "tm_gmtoff" in "struct tm", does it?  The
SVR4 ABIs don't include it, and I don't think the SVR4 code from AT&T
did.

Hmm.  I just remembered - C library code in SVR4-derived systems like 5.x,
when calling routines not in, I think, the ANSI C name space, prepend
an underscore to the name of the routine.  Routines in the C library
with names not in the ANSI C name space have that underscore prepended;
references to the name without the prepended underscore resolve to the
routine from the library if there's no routine in the program itself
with the no-prependend-underscore name, or something such as that.

Now, I'm not sure what happens to calls to the prepended-underscore name
if there is a routine in the program with the no-prepended-underscore
name, but I suspect it does *not* resolve to the routine in the program;
that way, if you have a routine named "read()" in your program (where
"in your program" includes "in a library of your own linked into your
program), you don't break any ANSI C routines (e.g., standard I/O
library routines) that might call "_read()" to do file system I/O.

Could the 5.x "strftime()" be calling the 5.x "tzset()" rather than the
"tzset()" from the library you've built?  If so, is there some reason to
expect the 5.x "tzset()" routine to e.g. fail to find the time zone
file?