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.

Kasper

On Thu, Sep 27, 2012 at 10:29 AM, Kasper Daniel Hansen
<[email protected]> wrote:
> On Thu, Sep 27, 2012 at 10:07 AM, Peder Axensten <[email protected]> 
> wrote:
>>
>> On 27 sep 2012, at 14:27, Simon Urbanek <[email protected]> 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
>>>> [email protected]
>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> R-SIG-Mac mailing list
>> [email protected]
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac

_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Reply via email to