I have been away for awhile, sorry for this belated impasse. I still think that in the binary that can be obtained from CRAN it would be safer to replace 'gcc' with 'llvm-gcc' and 'g++' with 'llvm-g++' to ensure that the right compiler is used and thus the -arch argument is recognized.
Thank you Kasper for taking the time to clarify the matter to me. I especially appreciate it now that I understand that this forum otherwise seems to be dominated by a 'if-you-don't-like-it-sod-of' attitude. I've found a reasonable workaround and I would have liked to contribute it so that R would be an even better experience on MacOS. My best regards, /Peder Axensten On 28 sep 2012, at 17:12, Kasper Daniel Hansen <[email protected]> wrote: > On Fri, Sep 28, 2012 at 10:58 AM, Prof Brian Ripley > <[email protected]> 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 >>> <[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 >>> >> >> >> -- >> Brian D. Ripley, [email protected] >> 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 > [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
