On Fri, Sep 28, 2012 at 10:58 AM, Prof Brian Ripley
<rip...@stats.ox.ac.uk> wrote:
> 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).
Thanks. I see how this works now, and I should have investigated a bit more.
Kasper
> 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
>> <kasperdanielhan...@gmail.com> wrote:
>>>
>>> On Thu, Sep 27, 2012 at 10:07 AM, Peder Axensten <peder.axens...@slu.se>
>>> wrote:
>>>>
>>>>
>>>> On 27 sep 2012, at 14:27, Simon Urbanek <simon.urba...@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@r-project.org
>>>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> R-SIG-Mac mailing list
>>>> R-SIG-Mac@r-project.org
>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>
>>
>> _______________________________________________
>> R-SIG-Mac mailing list
>> R-SIG-Mac@r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>
>
>
> --
> Brian D. Ripley, rip...@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
_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
