From aixtools at gmail.com  Mon Jan  4 23:24:17 2016
From: aixtools at gmail.com (Michael Felt)
Date: Mon, 4 Jan 2016 23:24:17 +0100
Subject: [Rd] R,
 AIX 64-bit builds - trying to understand root cause for message:
 "Error: Line starting 'Package: tools ...' is malformed!"
In-Reply-To: <11C4A052-1585-41A9-BFBD-1756E6DC8B96@r-project.org>
References: <56825A4B.7010508@gmail.com> <56839C9E.2010401@gmail.com>
	<5685466E.7000804@gmail.com>
	<4BED4A65-8EE9-49B8-8AFB-4E6CC3BB5BBF@r-project.org>
	<F92F30A1-4E5C-4312-B151-692F27013F8B@r-project.org>
	<F68557F2-67ED-4EF3-8BDF-F7981D8F38C0@gmail.com>
	<56894556.3020902@gmail.com>
	<5138BF7E-44C2-4ABE-9D3F-0730BCF90BC9@r-project.org>
	<568A1285.5000709@gmail.com>
	<11C4A052-1585-41A9-BFBD-1756E6DC8B96@r-project.org>
Message-ID: <568AF111.8030900@gmail.com>

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



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