[R] R 1.9.0 on AIX, 64-bit

[Jim Edwards]

Tim,

On the configure problem I've determined that this is a bug in the file 
acinclude.m4 provided in the R distribution.  The test function  
R_SYS_POSIX_LEAPSECONDS  needs to have ct initialized.  That it works on 
other systems is fortuitous.  Can you provide this feedback to the 
developers?  Thanks

Jim



Tim Hoar wrote:

>Here is a followup to Andy's post -- I have a working 64-bit R on AIX ...
>
>My institution is running AIX 5.1.
>
>Several things are needed to build R 1.9.0 and use dynamic loading of .so
>objects.
>
>*) setenv OBJECT_MODE 64       or the equivalent.
>
>*) There is a quirk (bug?) in the AIX compilers in 64bit mode that requires
>   changing configure:line 36555      to initialize a variable to zero.
>   Line 36555 should be:  time_t ct=0;
>
>   without the change -- configure hits a test for POSIX times and hangs ...
>
>   This can also be overcome by using -qinitauto=00, but it is
>   a performance hit ... so it is probably undesirable in the long run.
>
>   Note that in 32bit mode, this is not needed.
>
>*) The dynamic linking options specified in the R Installation and
>   Administration Guide: Section B.7.8 did not work for me --
>   the ones that did work are:
>
>OBJECT_MODE=64
>LDFLAGS='-brtl'
>CFLAGS='-O -qstrict'
>FFLAGS='-O -qstrict'
>CXXFLAGS='-O -qstrict'
>CC=/usr/bin/xlc_r
>F77=/usr/bin/xlf_r
>CXX=/usr/bin/xlC_r
>
>   furthermore, I was able to configure with the X11 libraries (and did not
>   have to supply the "--without-blas" option):
>
>   ./configure --prefix='blah_blah_blah'
>
>   it is nice to be able to plot!
>   Our IBM rep indicated that with LDFLAGS set as above, "configure" is
>   generally smart enough to figure out everything else -- kudos to the R
>   configure team. I have not tried a higher level of optimization.
>
>*) Our system does not have a 32,64-bit /lib/crt0.o  -- ours is only 32bit.
>   Our 64bit one is /lib/crt0_64.o   so after configure generates a
>   Makeconf file, it must be edited to use /lib/crt0_64.o  instead of crt0.o
>
>*) (credit to Andy Pierce)
>
>  
>
>>Date: Mon, 10 May 2004 13:31:22 -0400
>>From: Andy Pierce <apierce at stny.rr.com>
>>To: Tim Hoar <thoar at ucar.edu>
>>Subject: Re: [R] R 1.9.0 on AIX, 64-bit
>>
>>I worked the problem down to where there seems to be something wrong
>>with mktime in the way that R uses it.... I modified src/main/datetime.c
>>to add the lines for _AIX which you see below...  oddly, if you
>>extract out the mktime code from here and stuff it into a standalone
>>routine, it seems to work fine. It's all in the handling of dates from
>>before the epoch (1970).
>>
>>static Rboolean have_broken_mktime(void)
>>{
>>#ifdef _AIX
>>     return TRUE;
>>#else
>>#ifdef Win32
>>
>>     return TRUE;
>>
>>(the rest of the existing function....
>>
>>#endif
>>}
>>    
>>
>
>*) Our system is configured such that it is guaranteed to fail the
>   "running tests of Internet and socket function" tests, so I have
>   not run any of the tests after that -- yet.
>
>*) (again - credit to Andy Pierce)
>   When I tried to build the SparseM package -- there was an unresolved
>   external -- "etime"
>
>   Adding a file "etime.c" to the SparseM/src  with the following:
>
>#include <sys/time.h>
>#include <sys/resource.h>
>float etime(tt)
>float tt[2];
>{
>   int who;
>   struct rusage used;
>   who = 0;
>   getrusage(who,&used);
>/*   tt[0] = used.ru_exutime.tv_sec+((used.ru_exutime.tv_usec)/1000000.); */
>   tt[0] = used.ru_utime.tv_sec+((used.ru_utime.tv_usec)/1000000.);
>   tt[1] = used.ru_stime.tv_sec+((used.ru_stime.tv_usec)/1000000.);
>   return(tt[0]+tt[1]);
>}
>
>I did not find any problems in the config.log or the build output that
>indicates etime is a problem anywhere else.
>
>-=-=-=-=-=-=-=-=-=-=-
>
>After all the above -- I can dyn.load(), generate figures, etc.
>Hope this helps someone ...
>
>Tim
>
><Andy's post from Mon, 03 May 2004 08:27:47 -0400  deleted>
>
>
>## Tim Hoar, Associate Scientist              email: thoar at ucar.edu     ##
>## Geophysical Statistics Project             phone: 303-497-1708       ##
>## National Center for Atmospheric Research   FAX  : 303-497-1333       ##
>## Boulder, CO  80307                    http://www.cgd.ucar.edu/~thoar ##
>
>  
>


-- 
Jim Edwards             jedwards at ucar.edu
IBM Applications Analyst
NCAR SCD
BOULDER CO  303-497-1842