building 32-bit version of R 3.x

On Tue, Feb 25, 2014 at 3:11 AM, Prof Brian Ripley

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

A+
Sent from my iPhone
On Mar 3, 2014, at 12:25 PM, 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:

       [[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.
You can object all you
A+

_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac at r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Sent from my iPhone
On Mar 3, 2014, at 4:54 PM, David Winsemius <dwinsemius at comcast.net> wrote:

Sent from my iPhone

On Mar 3, 2014, at 12:25 PM, 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:

      [[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.
You can object all you
you like but you should realize that it is a message from the mail server, not from Prof Ripley.
David 

> 
> 
>> A+
>> 
>> _______________________________________________
>> R-SIG-Mac mailing list
>> R-SIG-Mac at r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> 
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac at r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac

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

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.

A+

On Mon, Mar 3, 2014 at 11:01 AM, Simon Urbanek
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

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

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).
Great -- so how should I configure R build to do that?  Obviously the
above builds only one.

A+

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).
Great -- so how should I configure R build to do that?  Obviously the
above builds only one.

You always build one, but they both install into one merged framework. You choose which to invoke by setting the --arch parameter, e.g. R --arch=x86_64 to run the 64-bit version. The default will be whichever you install last.

Cheers,
Simon
So in what sense is R on Mac OSX now supported as only 64-bit for 3.0
and after?  BTW, for the freshly built R32, I'm getting

[126] $ /opt/R/R32/R.framework/R
                                  zsh: exec format error:
/opt/R/R32/R.framework/R

setting DYLD_LIBRARY_PATH=/opt/R/R32/R.framework/Libraries doesn't help.

A+

On Mon, Mar 3, 2014 at 12:54 PM, Simon Urbanek
On Mar 3, 2014, at 3:41 PM, Alexy Khrabrov <deliverable at gmail.com> wrote:

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).
Great -- so how should I configure R build to do that?  Obviously the
above builds only one.

You always build one, but they both install into one merged framework. You choose which to invoke by setting the --arch parameter, e.g. R --arch=x86_64 to run the 64-bit version. The default will be whichever you install last.

Cheers,
Simon

So in what sense is R on Mac OSX now supported as only 64-bit for 3.0
and after?  BTW, for the freshly built R32, I'm getting

[126] $ /opt/R/R32/R.framework/R
                                 zsh: exec format error:
/opt/R/R32/R.framework/R

What is that? That's neither the proper place for a framework nor the correct build. Are you trying to run the framework library as opposed to the R binary?

If you do

make && make install

then the framework will be in 

/Library/Frameworks/R.framework

and the R start script in

/Library/Frameworks/R.framework/Resources/bin/R

You should not need to set anything else.

Cheers,
Simon
setting DYLD_LIBRARY_PATH=/opt/R/R32/R.framework/Libraries doesn't help.

A+

On Mon, Mar 3, 2014 at 12:54 PM, Simon Urbanek
<simon.urbanek at r-project.org> wrote:
On Mar 3, 2014, at 3:41 PM, Alexy Khrabrov <deliverable at gmail.com> wrote:

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).
Great -- so how should I configure R build to do that?  Obviously the
above builds only one.

You always build one, but they both install into one merged framework. You choose which to invoke by setting the --arch parameter, e.g. R --arch=x86_64 to run the 64-bit version. The default will be whichever you install last.

Cheers,
Simon

That's my own prefix gave to configure with your options above.  I've
installed gfortran-4.8.2 via brew, and gfortran symlink is pointing to
it.  For this 32-bit build, I've changed your flags to refer to
gfortran-4.2, which is the one installed from the tools link on CRAN.
Yet I get warnings during build:

ld: warning: ignoring file
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libquadmath.dylib, file
was built for x86_64 which is not the architecture being linked
(i386): /usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libquadmath.dylib

ld: warning: ignoring file
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2/libgcc.a,
file was built for archive which is not the architecture being linked
(i386): /usr/local/Cellar/gfortran/4.8.2/gfortran/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2/libgcc.a

-- hence I configured my own --prefix=/opt/R/R32 to first see whether
my build works, and it doesn't run from it.  make check seems to pass.
 Should I just make install and hope R --arch=i386 will work?

A+

On Mon, Mar 3, 2014 at 1:32 PM, Simon Urbanek
On Mar 3, 2014, at 4:24 PM, Alexy Khrabrov <deliverable at gmail.com> wrote:

So in what sense is R on Mac OSX now supported as only 64-bit for 3.0
and after?  BTW, for the freshly built R32, I'm getting

[126] $ /opt/R/R32/R.framework/R
                                 zsh: exec format error:
/opt/R/R32/R.framework/R

What is that? That's neither the proper place for a framework nor the correct build. Are you trying to run the framework library as opposed to the R binary?

If you do

make && make install

then the framework will be in

/Library/Frameworks/R.framework

and the R start script in

/Library/Frameworks/R.framework/Resources/bin/R

You should not need to set anything else.

Cheers,
Simon

setting DYLD_LIBRARY_PATH=/opt/R/R32/R.framework/Libraries doesn't help.

A+

On Mon, Mar 3, 2014 at 12:54 PM, Simon Urbanek
<simon.urbanek at r-project.org> wrote:
On Mar 3, 2014, at 3:41 PM, Alexy Khrabrov <deliverable at gmail.com> wrote:

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).
Great -- so how should I configure R build to do that?  Obviously the
above builds only one.

You always build one, but they both install into one merged framework. You choose which to invoke by setting the --arch parameter, e.g. R --arch=x86_64 to run the 64-bit version. The default will be whichever you install last.

Cheers,
Simon

That's my own prefix gave to configure with your options above.  I've
installed gfortran-4.8.2 via brew, and gfortran symlink is pointing to
it.  For this 32-bit build, I've changed your flags to refer to
gfortran-4.2, which is the one installed from the tools link on CRAN.
Ah, no, you cannot mix homebrew and native builds. As I said, if you use anything other that the native toolchain all bets are off and you'll need to pickup the mess yourself. In particular Homebrew doesn't provide fat binaries so you cannot mix it with 32-bit at all. Remove homebrew (move /usr/local aside), re-install the CRAN compiler and go from there. If you need any dependencies, have a look in
http://r.research.att.com/libs/

Cheers,
Simon
Yet I get warnings during build:

ld: warning: ignoring file
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libquadmath.dylib, file
was built for x86_64 which is not the architecture being linked
(i386): /usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libquadmath.dylib

ld: warning: ignoring file
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2/libgcc.a,
file was built for archive which is not the architecture being linked
(i386): /usr/local/Cellar/gfortran/4.8.2/gfortran/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2/libgcc.a

-- hence I configured my own --prefix=/opt/R/R32 to first see whether
my build works, and it doesn't run from it.  make check seems to pass.
Should I just make install and hope R --arch=i386 will work?

A+

On Mon, Mar 3, 2014 at 1:32 PM, Simon Urbanek
<simon.urbanek at r-project.org> wrote:
On Mar 3, 2014, at 4:24 PM, Alexy Khrabrov <deliverable at gmail.com> wrote:

So in what sense is R on Mac OSX now supported as only 64-bit for 3.0
and after?  BTW, for the freshly built R32, I'm getting

[126] $ /opt/R/R32/R.framework/R
                                zsh: exec format error:
/opt/R/R32/R.framework/R

What is that? That's neither the proper place for a framework nor the correct build. Are you trying to run the framework library as opposed to the R binary?

If you do

make && make install

then the framework will be in

/Library/Frameworks/R.framework

and the R start script in

/Library/Frameworks/R.framework/Resources/bin/R

You should not need to set anything else.

Cheers,
Simon

setting DYLD_LIBRARY_PATH=/opt/R/R32/R.framework/Libraries doesn't help.

A+

On Mon, Mar 3, 2014 at 12:54 PM, Simon Urbanek
<simon.urbanek at r-project.org> wrote:
On Mar 3, 2014, at 3:41 PM, Alexy Khrabrov <deliverable at gmail.com> wrote:

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).
Great -- so how should I configure R build to do that?  Obviously the
above builds only one.

You always build one, but they both install into one merged framework. You choose which to invoke by setting the --arch parameter, e.g. R --arch=x86_64 to run the 64-bit version. The default will be whichever you install last.

Cheers,
Simon

OK, after moving aside brew and building with ATT gfortran-4.3 and
your options above, I've installed over previous binary install of R.
It starts up 32-bit version fine via R, but --arch=x86_64 says
subarchitecture not installed.  Anything else needed to enable it?

A+

On Mon, Mar 3, 2014 at 2:17 PM, Simon Urbanek
On Mar 3, 2014, at 4:50 PM, Alexy Khrabrov <deliverable at gmail.com> wrote:

That's my own prefix gave to configure with your options above.  I've
installed gfortran-4.8.2 via brew, and gfortran symlink is pointing to
it.  For this 32-bit build, I've changed your flags to refer to
gfortran-4.2, which is the one installed from the tools link on CRAN.
Ah, no, you cannot mix homebrew and native builds. As I said, if you use anything other that the native toolchain all bets are off and you'll need to pickup the mess yourself. In particular Homebrew doesn't provide fat binaries so you cannot mix it with 32-bit at all. Remove homebrew (move /usr/local aside), re-install the CRAN compiler and go from there. If you need any dependencies, have a look in
http://r.research.att.com/libs/

Cheers,
Simon

Yet I get warnings during build:

ld: warning: ignoring file
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libquadmath.dylib, file
was built for x86_64 which is not the architecture being linked
(i386): /usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libquadmath.dylib

ld: warning: ignoring file
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2/libgcc.a,
file was built for archive which is not the architecture being linked
(i386): /usr/local/Cellar/gfortran/4.8.2/gfortran/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2/libgcc.a

-- hence I configured my own --prefix=/opt/R/R32 to first see whether
my build works, and it doesn't run from it.  make check seems to pass.
Should I just make install and hope R --arch=i386 will work?

A+

On Mon, Mar 3, 2014 at 1:32 PM, Simon Urbanek
<simon.urbanek at r-project.org> wrote:
On Mar 3, 2014, at 4:24 PM, Alexy Khrabrov <deliverable at gmail.com> wrote:

So in what sense is R on Mac OSX now supported as only 64-bit for 3.0
and after?  BTW, for the freshly built R32, I'm getting

[126] $ /opt/R/R32/R.framework/R
                                zsh: exec format error:
/opt/R/R32/R.framework/R

What is that? That's neither the proper place for a framework nor the correct build. Are you trying to run the framework library as opposed to the R binary?

If you do

make && make install

then the framework will be in

/Library/Frameworks/R.framework

and the R start script in

/Library/Frameworks/R.framework/Resources/bin/R

You should not need to set anything else.

Cheers,
Simon

setting DYLD_LIBRARY_PATH=/opt/R/R32/R.framework/Libraries doesn't help.

A+

On Mon, Mar 3, 2014 at 12:54 PM, Simon Urbanek
<simon.urbanek at r-project.org> wrote:
On Mar 3, 2014, at 3:41 PM, Alexy Khrabrov <deliverable at gmail.com> wrote:

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).
Great -- so how should I configure R build to do that?  Obviously the
above builds only one.

You always build one, but they both install into one merged framework. You choose which to invoke by setting the --arch parameter, e.g. R --arch=x86_64 to run the 64-bit version. The default will be whichever you install last.

Cheers,
Simon

OK, after moving aside brew and building with ATT gfortran-4.3 and
your options above, I've installed over previous binary install of R.
It starts up 32-bit version fine via R, but --arch=x86_64 says
subarchitecture not installed.  Anything else needed to enable it?

Did you build and install the 64-bit version as well? And did you use r_arch=x86_64 in the 64-bit build?

Cheers,
S
A+

On Mon, Mar 3, 2014 at 2:17 PM, Simon Urbanek
<simon.urbanek at r-project.org> wrote:
On Mar 3, 2014, at 4:50 PM, Alexy Khrabrov <deliverable at gmail.com> wrote:

That's my own prefix gave to configure with your options above.  I've
installed gfortran-4.8.2 via brew, and gfortran symlink is pointing to
it.  For this 32-bit build, I've changed your flags to refer to
gfortran-4.2, which is the one installed from the tools link on CRAN.
Ah, no, you cannot mix homebrew and native builds. As I said, if you use anything other that the native toolchain all bets are off and you'll need to pickup the mess yourself. In particular Homebrew doesn't provide fat binaries so you cannot mix it with 32-bit at all. Remove homebrew (move /usr/local aside), re-install the CRAN compiler and go from there. If you need any dependencies, have a look in
http://r.research.att.com/libs/

Cheers,
Simon

Yet I get warnings during build:

ld: warning: ignoring file
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libquadmath.dylib, file
was built for x86_64 which is not the architecture being linked
(i386): /usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libquadmath.dylib

ld: warning: ignoring file
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2/libgcc.a,
file was built for archive which is not the architecture being linked
(i386): /usr/local/Cellar/gfortran/4.8.2/gfortran/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2/libgcc.a

-- hence I configured my own --prefix=/opt/R/R32 to first see whether
my build works, and it doesn't run from it.  make check seems to pass.
Should I just make install and hope R --arch=i386 will work?

A+

On Mon, Mar 3, 2014 at 1:32 PM, Simon Urbanek
<simon.urbanek at r-project.org> wrote:
On Mar 3, 2014, at 4:24 PM, Alexy Khrabrov <deliverable at gmail.com> wrote:

So in what sense is R on Mac OSX now supported as only 64-bit for 3.0
and after?  BTW, for the freshly built R32, I'm getting

[126] $ /opt/R/R32/R.framework/R
                               zsh: exec format error:
/opt/R/R32/R.framework/R

What is that? That's neither the proper place for a framework nor the correct build. Are you trying to run the framework library as opposed to the R binary?

If you do

make && make install

then the framework will be in

/Library/Frameworks/R.framework

and the R start script in

/Library/Frameworks/R.framework/Resources/bin/R

You should not need to set anything else.

Cheers,
Simon

setting DYLD_LIBRARY_PATH=/opt/R/R32/R.framework/Libraries doesn't help.

A+

On Mon, Mar 3, 2014 at 12:54 PM, Simon Urbanek
<simon.urbanek at r-project.org> wrote:
On Mar 3, 2014, at 3:41 PM, Alexy Khrabrov <deliverable at gmail.com> wrote:

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).
Great -- so how should I configure R build to do that?  Obviously the
above builds only one.

You always build one, but they both install into one merged framework. You choose which to invoke by setting the --arch parameter, e.g. R --arch=x86_64 to run the 64-bit version. The default will be whichever you install last.

Cheers,
Simon