[R-SIG-Mac] error: unrecognized option ‘-arch’ -- suggestion!

Prof Brian Ripley ripley at stats.ox.ac.uk
Fri Sep 28 16:58:16 CEST 2012 

On 28/09/2012 15:29, Kasper Daniel Hansen wrote:
> So I had a few emails with Peder, and I think he gets it now.
>
> However, one point came up which I have been wondering about as well.
> In Makeconf R only stores the name of the compiler, say "gcc" or
> perhaps "gcc-4.2".  Why not store the full path?  Peder's situation is
> that he has installed another compiler that resolves to gcc in his
> environment, masking the one in /usr/bin.  It seems to me that it
> would be more "safe" to save the entire path to the compiler, both on
> multi-user systems on in case like (for os x) the binary is downloaded
> from somewhere else.  [ on the other hand, it may be easier on Windows
> to not have the full path ]
>
> Now, there is probably a perfectly good reason to do what is happening
> now.  Or perhaps changing it is not worth the effort.  But I just
> wanted to raise the issue for 2 seconds.

You get what you specified when you configured R.  I usually configure 
with full paths except on Windows (where paths like /usr/local do not 
exist in general).

The point is that you can do what suits you.  If you choose to use a 
binary distribution you get what suits the distributor: if you don't 
like that, build from the sources yourself.

The documentation for the CRAN Mac binary distribution is a bit 
scattered.  I am not sure it would help, but we could add some more 
words to the R-admin manual.  I suspect few people want to work with 
source packages with compiled code and use the CRAN distribution (not 
least as it is hard to make portable binary packages that way).

>
> Kasper
>
> On Thu, Sep 27, 2012 at 10:29 AM, Kasper Daniel Hansen
> <kasperdanielhansen at gmail.com> wrote:
>> On Thu, Sep 27, 2012 at 10:07 AM, Peder Axensten <Peder.Axensten at slu.se> wrote:
>>>
>>> On 27 sep 2012, at 14:27, Simon Urbanek <simon.urbanek at r-project.org> wrote:
>>>
>>>> On Sep 27, 2012, at 5:02 AM, Peder Axensten wrote:
>>>>
>>>>> The compiler (clang) and linker that Apple includes (with Xcode) uses the argument -arch to specify the architecture to build for. This is not recognized by, for instance, the gcc compilers. Because this argument is 'hardcoded' into the Makeconfig files,
>>>>
>>>> It is not - those (assuming you mean Makeconf) are generated from the flags used to build R, so if you use any other compiler with other flags they will be reflected in the Makeconf accordingly.
>>>
>>> I know little about how this is set up, is it not possible to change some kind of template to change the way this is done? Some base variables that are generated from the flags, these variables are then used in the rest of the Makeconf along the lines I suggested?
>>>
>>>>> it is an involved process to compile libraries for R with any other compiler.
>>>>
>>>> R doen't care what you compile libraries with as long as R can links against them at configure time. Again, this has nothing to do with Makevars.
>>>
>>> As I understand it, if I use R CMD INSTALL I'm stuck with what is defined in the Makeconf files. If I use any other compiler other than Apple's clang as my "default" compiler, I get errors when I run R CMD INSTALL –– that is, if I from R try to install any package that requires compilation. I think it would be better to determine the value of the variables when R CMD INSTALL is run, rather than when R is installed (or even compiled?).
>>
>> Peder,
>>
>> You seem a bit confused.  Let me explain it a bit clearer.  When you
>> compile R, the settings (and compiler) with which you compiled R is
>> stored in Makeconf and used to compile new packages using R CMD
>> INSTALL.  This ensures that you use the same compiler settings to
>> build R and add-on packages, which is obviously an _extremely good_
>> idea.  If you want to use another compiler with R, you will need to
>> re-compile R using this compiler, which should work.
>>
>> My guess is that you are using the CRAN binary of R (compiled using
>> the official compiler) and you want to use another compiler to build
>> an add-on package.  This is not supported, and it should not be
>> supported, because it is an extremely bad idea.
>>
>> Below is my configure call for building R from svn, using Simon's
>> build of Apple's GCC codebase (aka the official compiler).  It should
>> be easy to modify this to build R using a different compiler.  I am
>> just including this as an example.  Once you have build R using you
>> new compiler, R CMD INSTALL should work out of the box.
>>
>> Note that if you want aqua support, you need a compiler that supports
>> objective-C (as far as I understand).  I don't use a GUI, but I use an
>> aqua device, like
>> R>  quartz()
>>
>> (I may use imprecise terminology here, wrt. aqua and quartz).
>>
>> Kasper
>>
>> configure:
>>
>> export LANG=en_US.UTF-8
>> ../${SRCDIR}/configure SHELL='/bin/bash' \
>>    --prefix=/usr/local/R/R-${R_VERSION} --disable-R-framework\
>>    CC="/usr/bin/gcc-4.2 -arch x86_64 -std=gnu99" \
>>    CFLAGS="-g -O2 -std=gnu99 -march=nocona" \
>>    CXX="/usr/bin/g++-4.2 -arch x86_64" \
>>    CXXFLAGS="-g -O2 -march=nocona" \
>>    OBJC="/usr/bin/gcc-4.2 -arch x86_64" \
>>    F77="/usr/bin/gfortran-4.2 -arch x86_64" \
>>    FFLAGS="-g -O2 -march=nocona" \
>>    FC="/usr/bin/gfortran-4.2 -arch x86_64" \
>>    FCFLAGS="-g -O2 -march=nocona" \
>>    --enable-memory-profiling\
>>    --x-includes=/usr/X11/include --x-libraries=/usr/X11/lib\
>>    --with-system-zlib\
>>    --with-blas='-framework vecLib' --with-lapack
>>
>>
>>
>>
>>
>>> I'm sure it could be implemented better, but something like:
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> GCCPATH =
>>>
>>> # If we are using the Apple compiler [that supports the -arch option], this is the argument to that option.
>>> ARCH = x86_64
>>>
>>> # Get information on the gcc to be used.
>>> ISAPPLESTRING := $(shell "$(GCCPATH)gcc --version")
>>> ISAPPLEKEY := Apple
>>>
>>> # This will either be nothing or '-arch $(ARCH)'
>>> MYARCH := $(if $(findstring $(ISAPPLEKEY),$(ISAPPLESTRING)),"-arch $(ARCH)")
>>>
>>> MYGCC = $(GCCPATH)gcc $(MYARCH)
>>> MYGPP = $(GCCPATH)g++ $(MYARCH)
>>> MYFORTRAN = $(GCCPATH)gfortran $(MYARCH)
>>>
>>> ## etc.
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>
>>> All the best,
>>> /Peder
>>>
>>>
>>>> Cheers,
>>>> Simon
>>>>
>>>>
>>>>
>>>>> Either all all `-arch i386` and `-arch x86_64` must be removed from these files (this must be done every time R is updated) or you create a file `~/.R/Makevars` with something like
>>>>> ~~~~~~~
>>>>> MYARCH = -arch x86_64
>>>>>
>>>>> # Comment the next line to return to the original setting:
>>>>> MYARCH =
>>>>>
>>>>> CC = gcc $(MYARCH) -std=gnu99
>>>>> CXX=g++ $(MYARCH)
>>>>> CXXCPP = g++ $(MYARCH) -E
>>>>> FC = gfortran $(MYARCH)
>>>>> F77 = gfortran $(MYARCH)
>>>>> OBJC = gcc $(MYARCH)
>>>>> OBJCXX = g++ $(MYARCH)
>>>>>
>>>>> DYLIB_LD = gcc $(MYARCH) -std=gnu99
>>>>> MAIN_LD = gcc $(MYARCH) -std=gnu99
>>>>> SHLIB_CXXLD = g++ $(MYARCH)
>>>>> SHLIB_FCLD = gfortran $(MYARCH)
>>>>> SHLIB_LD = gcc $(MYARCH) -std=gnu99
>>>>> ~~~~~~~
>>>>> Unfortunately, a few instances of `-arch` are outside the variables and can not be reached this way.
>>>>>
>>>>>
>>>>>
>>>>> My suggestion is that the Makeconfig files are slightly changed:
>>>>>
>>>>> - Change all `-arch i386` or `-arch x86_64` in these files to `$(MYARCH)`.
>>>>> - Add a line `MYARCH = -arch x86_64` or `MYARCH = -arch i386`, respectively, to the top of these files.
>>>>>
>>>>> No functionality is changed but using another compiler is more compatible and simpler as only MYARCH would need to be predefined.
>>>>>
>>>>>
>>>>>
>>>>> Even better would be to be able to specify the compiler set to be used by using a variable (and handle the architecture accordingly), but I know to little about make files to come up with a constructive suggestion. Probably something like using
>>>>> PREFIX =
>>>>> GCC = $(PREFIX)gcc $(MYARCH)
>>>>> GPP = $(PREFIX)g++ $(MYARCH)
>>>>> GFORTRAN = $(PREFIX)gfortran $(MYARCH)
>>>>> and then using them when defining CC, XXX, etc.
>>>>>
>>>>> No functionality would be changed, but a different set of compilers could be used just by changing PREFIX and MYARCH.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Peder Axensten
>>>>> Research engineer
>>>>>
>>>>> Swedish University of Agricultural Sciences
>>>>> Dept. of Forest Resource Management
>>>>> Remote Sensing
>>>>> se-90183 Umeå
>>>>> Sweden
>>>>> Visiting address: Skogsmarksgränd
>>>>>
>>>>> _______________________________________________
>>>>> 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
>
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac at r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>


-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

More information about the R-SIG-Mac mailing list