[R-SIG-Mac] building 32-bit version of R 3.x

[Simon Urbanek]

On Mar 3, 2014, at 2:58 PM, Alexy Khrabrov <deliverable at gmail.com> wrote:

> Simon -- thanks, the flags were the issue.  I think the r_arch was not
> enough, and Fortran flags had to be supplied separately in addition to
> C++ ones.
> 

Yes, r_arch is just a label, it doesn't change anything in the compilers.


> About HTML and other assumptions, I just think it's good to reexamine
> them form time to time and see where the online tech stands...
> 
> Obviously I'm not going to link incompatible architectures, so I guess
> the management consists of shell and linker paths, etc.  Was wondering
> about any other caveats of having both.  I've installed into a
> separate prefix for now; how did you manage R32 and R64 before under
> R.framework?  E.g. can R32 be installed under R.framework/Versions as
> a separate 32-bit version?  I guess not as it's 3.0 too, but am
> generally curious about aspects of these two now coexisting.
> 

They are both installed into the same "fat" framework. Everything is shared (i.e. files exist only once) except for the .so objects and some configurations that are in separate subdirectories based on the r_arch setting. OS X supports multiple architectures in one binary, that's why you don't need to modify any paths. OS X was running several architectures in parallel for a long time (first PPC+Intel then ppc+ppc64+i386+x86_64) so it "just works". The only thing to remember is that when you are compiling 3rd party dependencies, you must compile them "fat" for both architectures as well (or use lipo to combine them).

Cheers,
Simon




> A+
> 
> On Mon, Mar 3, 2014 at 11:01 AM, Simon Urbanek
> <simon.urbanek at r-project.org> wrote:
>> 
>> On Mar 3, 2014, at 12:25 AM, Alexy Khrabrov <deliverable at gmail.com> wrote:
>> 
>>> On Tue, Feb 25, 2014 at 3:11 AM, Prof Brian Ripley
>>> <ripley at stats.ox.ac.uk> wrote:
>>> 
>>>>> Looking at the sources, there's no obvious way to switch to 32-bit.  The
>>>>> gfortran.pkg (4.2.3) seems obsolete; I've configured the default setup
>>>> 
>>>> So?  At least it includes a 32-bit compiler (by default if I understand the
>>>> version you are using).
>>>> 
>>> 
>>> Correct -- but with the current Apple gcc and -arch i386, that old gfortran and C++ disagree on integer and double sizes in configure.
>>> 
>> 
>> I don't think so - those two the same even between 32-bit and 64-bit. I suspect you're misinterpreting the output (which you didn't provide) and if there is indeed some other error you have likely not set the correct flags. I can confirm that
>> 
>> CC='gcc -arch i386' CXX='g++ -arch i386' F77='gfortran -arch i386' FC='gfortran -arch i386' OBJC='gcc -arch i386'
>> 
>> works just fine (assuming your system has both 32-bit and 64-bit libraries).
>> 
>> 
>>>> You need to specify a 32-bit compiler.  AFAIK -arch is specific to Apple
>>>> front-ends, and the value is i386, not x686.
>>>> 
>>>> If you build multilib GCC from the sources, the flag needed is -m32.
>>>> 
>>>> This *is* all in the relevant manual.
>>> 
>>> The manual seems rather general there.  I'd like to know whether
>>> someone has done this recently and what the exact steps are to
>>> 
>>> -- build the gcc and gfortran with both i386 and x86_64 standard libraries
>>> -- compile latest R with it
>>> -- how to install and manage the setup for invoking one or the other,
>>> and linking to one's or the other's .dylib
>>> 
>> 
>> You cannot link one another's dylibs since they are two entirely different, incompatible architectures.
>> 
>> Building R with the default compilers (Apple + gfortran from CRAN) works out of the box for both in 32-bit and 64-bit. For any other setup, you're entirely on your own. If you want a multi-arch installation of R, you can set r_arch=i386 for the 32-bit build and r_arch=x86_64 for the 64-bin build to build separate architectures. The default install will then create a merged universal framework - see instructions for 2.x series of R that used multi-arch install on OS X.
>> 
>> 
>>>>>       [[alternative HTML version deleted]]
>>> 
>>> I'll dare to object to your signature objection here -- the times
>>> moved on, and most web-based email services, such as gmail, use HTML
>>> mail by default.  Even those who used to run mutt and the like are on
>>> gmail, and not always do they bother to set plain text mode.  So I'd
>>> be OK with the line above, but I will set plain text mode to honor the
>>> tradition.
>>> 
>> 
>> As David pointed out you can object all you want, but those are the rules you were asked to abide by. Whether you like them or not is relevant - HTML cause unnecessary problems in e-mails. Unfortunately, bad defaults are ubiquitous (just look at Outlook to see how you can end up with e-mails that have content that doesn't communicate anything - not even the intended message).
>> 
>> Cheers,
>> Simon
>> 
>> 
>