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

[Michael Felt]

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
  +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
>
>