Re: oct-time.cc on an alpha

[A. Scottedward Hodel]

> on 2/23/00 3:34 PM, John W. Eaton at address@hidden wrote:

> On 23-Feb-2000, A. Scottedward Hodel <address@hidden> wrote:
> 
> | I'm updating my gcc/g++ to 2.95.2 so that I can compile the latest Octave
> | CVS archives.
> | 
> | Compiling liboctave/oct-time.cc gives errors:
> | 
> | oct-time.cc:182: `struct tm' has no member named `tm_zone'
> | oct-time.cc: In method `void octave_base_tm::init(void *)':
> | oct-time.cc:229: `struct tm' has no member named `tm_zone'
> | oct-time.cc: In method `void octave_strptime::init(const string &, const
> | string &)':
> | oct-time.cc:273: `struct tm' has no member named `tm_zone'
> | 
> | There was previously an error near line 80 of this file.  I worked my way
> | back to time.h on my system, which defines struct tm with:
> | 
> | #ifdef _OSF_SOURCE
> |         long    tm_gmtoff;
> |         char    *tm_zone;
> | #else
> |         long    __tm_gmtoff;
> |         char    *__tm_zone;
> | #endif
> | 
> | It's not clear to me why this doesn't cause problems in the configure
> | script.
> 
> Feature tests for Octave are done with the C compiler.  In the old
> days, the results of the tests were mostly correct, even if they were
> going to be used in C++ sources.  But now C++ compilers are picky and
> it may cause some trouble.  Recently, my approach has been to shove
> all the non-standard C/C++ stuff off in C-language files where the
> environment is a bit more forgiving.  The alternative solution of
> checking for features using the C++ compiler doesn't seem as
> desireable to me, because if the compiler is picky and the header
> files are not quite right for C++, you will probably not see all the
> features that your system really has.
> 
> The configure test for the tm_zone field in `struct tm' is:
> 
> #include "confdefs.h"
> #include <sys/types.h>
> #include <$ac_cv_struct_tm>
> int main() {
> struct tm tm; tm.tm_zone;
> ; return 0; }
> 
> and $ac_cv_struct_tm is either time.h or sys/time.h.  The contents of
> confdefs.h depends on what has been discovered up to this point in the
> configure script, but I don't think it matters.  Can you compile
> 
> #include <sys/types.h>
> #include <time.h>
> int main() { struct tm tm; tm.tm_zone; return 0; }
> 
> on your system with the C compiler?  What about if you use
> <sys/time.h>?  What happens if you repeat the test with the C++
> compiler?
> 
> On the DEC Alpha system that I have access to (running DU 4.0E, I
> think), it appears that _OSF_SOURCE is defined automatically (in
> standards.h, included by time.h and sys/time.h) when I compile with
> gcc or g++ (2.95.2).
> 
> jwe
> 

I already compled the above program as a C program and as c++ (with

#ifdef _OSF_SOURCE
   cout << ...
#else
   cout << ...
#endif

to confirm what you wrote above; _OSF_SOURCE seems to be automatically
defined.  For some reason, it's NOT defined when I compile oct-time.cc,
which doesn't make sense to me.  I put in

#ifndef _OSF_SOURCE
#define _OSF_SOURCE
#endif

into oct-time.cc and that took care of the compile problem for oct-time.cc
(although there are link-time problems I'm trying to resolve now).

I'm guessing that there's something screwy in my PATH or CFLAGS definitions
so that so that I'm sometimes working with the main gnu software directory
(using v 2.8.1) instead of using my beta-software directory where I test
this stuff out before installing it for everyone else to use.

I'll get back to you once I get a reasonable solution to the problem.

-- 
A S Hodel Assoc. Prof. Dept Elect and Computer Eng, Auburn Univ,AL
36849-5201
On leave at NASA Marshall Space Flight Center (256) 544-1426
Address until 31 July 2000:Mail Code TD-55, MSFC, Alabama, 35812
http://www.eng.auburn.edu/~scotte