[R] Building R on Solaris (OpenIndiana) with gcc 4.6.2 for amd64 target - relocation problems solved

[Michael Figiel]

  On 04/ 7/12 08:13 AM, Prof Brian Ripley wrote:
> On 06/04/2012 19:38, Michael Figiel wrote:
>> Hello,
>> the "R Installation and Administration" handbook states in Section C 
>> 5.1:
>> For ‘amd64’ the builds have failed to complete in several different
>> ways, currently with relocation errors for libRblas.so.
>>
>> To fix it: add '-shared' to the SHLIB_LDFLAGS, SHLIB_CXXLDFLAGS and
>> SHLIB_FCLDFLAGS before starting configure.
>>
>> So the complete set of variables' values sufficient to build for the
>> amd64 target (as used on OpenIndiana 151a2 with gcc 4.6.2):
>> SHLIB_LDFLAGS=-shared
>> SHLIB_CXXFLAGS=-shared
>> SHLIB_FCLDFLAGS=-shared
>> CFLAGS=-m64
>> CXXFLAGS=-m64
>> FFLAGS=-m64
>> FCFLAGS=-m64
>> LDFLAGS=-m64 -L/usr/local/lib/amd64
>> CPPFLAGS=-I/usr/local/include
>>
>> Additionally you'll need the gnu libiconv, which resides probably in
>> /usr/gnu, so the CPPFLAGS will need an -I/usr/gnu/include and the
>> LDFLAGS needs a -L/usr/gnu/lib/amd64 (on my machines I keep everything
>> in /usr/local therefor no reference to /usr/gnu )
>>
>> If you prefer to use the Solaris linker (/usr/bin/ld) add
>> -fno-gnu-linker to the SHLIB_* variables and make sure, your PATH
>> doesn't list /usr/gnu/bin before /usr/bin.
I was wrong on that: you don't need to set anything  - the gcc 
(pkg:/runtime/gcc at 4.6.2-0.151.1) will always use the Solaris linker. I 
don't know how to force it to use the gnu linker - I think, it's a 
compile time option.
>>
>> I've got only OpenIndiana machines, but it should work on Solaris 10/11,
>> too.
>
> Your instructions are for the GNU linker: those in the manual are for 
> the Solaris linker, which does not support --shared.
Well, the options '-shared' and '-m64' are for the gcc, not for the 
linker. The build process doesn't invoke the linker directly, it's 
always via gcc, which processes the options and takes care for correct 
invocation of the linker. Without '-shared' the gcc invokes ld in a way, 
which makes the resulting shared object position dependent, even if the 
object code was position independent (I haven't investigated what 
actually happens there, I only verified with elfdump -d , that the 
resulting shared object contains text relocations).

Kind regards
Michael Figiel