[Rd] R, AIX 64-bit builds - trying to understand root cause for message: "Error: Line starting 'Package: tools ...' is malformed!"

[Michael Felt]

On 04-Jan-16 23:24, Michael Felt wrote:
> The bulk is on my forums - the final post for today is:
>
> Results to date:
>
> A. It looks like I am going to need a newer compiler for C - xlc/xlC 
> V11 apparently does not understand this code:
>
> "/data/prj/cran/R-3.2.3/src/main/memory.c", line 2149.31: 1506-046 (S) 
> Syntax error.
>
> I will have to check if R-devel has different code before asking for 
> assistence.
>
>  +2139  #ifdef HAVE_STDALIGN_H
>  +2140  # include <stdalign.h>
>  +2141  #endif
>  +2142
>  +2143  #include <stdint.h>
>  +2144
>  +2145  long double *R_allocLD(size_t nelem)
>  +2146  {
>  +2147  #if __alignof_is_defined
>  +2148      // This is C11: picky compilers may warn.
>  +2149      size_t ld_align = alignof(long double);
>  +2150  #elif __GNUC__
>  +2151      // This is C99, but do not rely on it.
>  +2152      size_t ld_align = offsetof(struct { char __a; long double 
> __b; }, __b);
>  +2153  #else
This is a hint/hack - with xlc V11 I get past a syntax "failure" with 
something like the following:
#if __alignof_is_defined
         long double ldbl = 0.0;
     // This is C11: picky compilers may warn.
     size_t ld_align = alignof(ldbl);
#elif __GNUC__

>  +2154 size_t ld_align = 0x0F; // value of x86_64, known others are 4 
> or 8
>  +2155  #endif
>  +2156      if (ld_align > 8) {
>  +2157          uintptr_t tmp = (uintptr_t) R_alloc(nelem + 1, 
> sizeof(long double));
>  +2158          tmp = (tmp + ld_align - 1) & ~ld_align;
>  +2159          return (long double *) tmp;
>  +2160      } else {
>  +2161          return (long double *) R_alloc(nelem, sizeof(long 
> double));
>  +2162      }
>  +2163  }
>
> If someone has a suggestion for how to test/fix so that I can proceed 
> with an older xlc compiler, that would be great!
> If not, I shall download the try and buy C compiler to test.
>
> On 04-Jan-16 15:52, Simon Urbanek wrote:
>> No, no duplicate warnings.
>>
> B. There is a very big difference in the way libraries are made when 
> gcc/gfortran are not used.
>
> When gcc is being used "everything" is being turned into a shared 
> library. The only library I seem to be able
> to affect via configure is libR.so (yes/no). The snip here shows that 
> all members of the .a archives are
> "non-shared" objects rather that a combined group of .o files into a 
> single .so shared object.
>
> So, it is not surprising that there are no duplicate symbols.
>
> cran at x068:[/home/cran/64/R]dump -H src/*/*.a | head
>
> src/appl/libappl.a[integrate.o]:
>
> Loader section is not available
>
> src/appl/libappl.a[interv.o]:
>
> Loader section is not available
>
> src/appl/libappl.a[maxcol.o]:
>>> >FYI: I shall be downloading the "try and buy" xlc and xlfortran - 
>>> and I think you will certainly prefer my packaging then as they work 
>>> without the libgc dependencies that many of the rpm packages need.
>>> >
>>> >And, at your option - we can take this discussion over tools - "out 
>>> of forums". Or at least start a new thread.
>>> >
>> We could leave the list out and create a Wiki or something with the 
>> results of our tests.
>>
>>
>>> >re: unsigned short - I have adopted the convention to use the *NN_t 
>>> types after running into a problem with unsigned longlong (from a 
>>> very old program). It goes back many years - and maybe they have 
>>> finalized short to mean 16-bits - but I remember when short was 
>>> meant to help when moving from 16-bit to 32-bit and the "word" size 
>>> changed - i.e., int became 32-bit same as long. nd for a long (no 
>>> pun intended) long was 32-bit and long long was 64-bit. Those 
>>> definitions are extinct.
>>> >
>> I'm not sure what you refer here - the issue with TRE has nothing to 
>> do with short - it can take any int type and like I said most 
>> platforms use unsigned int which is big enough on all platforms.
>>
>>
>>> >imho - the standard for wint_t is wrong as well - based on an 
>>> assumption about how "short" is defined. And, I consider it poor 
>>> practice that there are som many cases of type cast switches between 
>>> ushort and int.
>>> >
>> Not really - it doesn't care about short at all - note that the short 
>> typedef is never actually used on AIX since it has wchar support so 
>> TRE is only using int.
>>
>> Cheers,
>> Simon
>>
>>
>