[Rd] MacOS 10.4 gcc-4.0 and libcc_dynamic
Around line 527 of configure.ac in R-2.1.1 appears the following: darwin*) ## MacOS 10.3 and 10.4 do AM_CONDITIONAL(BUILD_DLFCN_DARWIN, false) ## SI says we want '-lcc_dynamic' on Darwin, although currently ## http://developer.apple.com /documentation/MacOSX/ has nothing ## official. AC_CHECK_LIB(cc_dynamic, main) ;; *) AM_CONDITIONAL(BUILD_DLFCN_DARWIN, false) AC_CHECK_LIB(dl, dlopen) ;; The purpose of this is to add -lcc_dynamic to the link options when linking Fortran code built with an FSF g77 with C libraries built with Apple's gcc-3.xx compilers. (see http://www.astro.gla.ac.uk/ users/norman/note/2004/restFP/ for the full story.). The fixed worked because /usr/lib/libcc_dynamic.dylib was a symlink to /usr/lib/gcc/powerpc-apple-darwin/$VERSION/libgcc.a. I write 'was' because as of gcc-4.0 on Tiger (10.4) this has changed. gcc-4.0 is the default compiler for Tiger, and it does not have the symlink. This is for the very good reason that it would not work. I have tried it. If gcc_select is used to changed the default compiler, the symlink is created, but it is destroyed again if the default is set back to 4.0. As far as I can see at this point, there are two ways to build R on MacOS X 10.4 Tiger: 1. use gcc-3.3 with g77 and ensure that -lcc_dynamic is in the link options. or 2. use gcc-4.0 with gfortran in which case -lcc_dynamic is not required and the configure.ac test above is redundant. AFAIK gcc-4.0 cannot be used with g77. Apple have been adding 'APPLE LOCAL' mods to gfortran and it can now be built from current Apple sources simply by adding f95 to the -- enable-languages on line 102 of the build_gcc script. I suspect that in the not too distant future gfortran will become part of the Xcode packages. Bill Northcott __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Building R sources on Windows
Following considerable off list discussion, I will post this on the list in the hope that it may help others who experience the same grief I did getting R sources to build on Windows. Firstly there is just no way that, starting with a clean version of Windows 2003 server, and following the instructions provided in the Admin and Installation manual, web sites and various FAQs, I could get a working build setup. I can only conclude that all the users actually building R on Windows have some software installed that is not in the documentation. The following recipe does work repeatably for me. Install the following third party packages as mentioned in the install manuals and Duncan Murdoch's Rtools page: Tcl/tk support libpng libjpeg BLAS (I used ATLAS) ActiveState PERL Microsoft HTML Help Workshop MikTek Inno Setup 5 iconv.dll MinGW-4.1.0 Duncan Murdoch's page on using MikTek is good but but more complicated than it needs to be. The only problem with the default e- TeX enhanced mode seems to be with the texinfo sources. So only the tex and pdftex commands need to be reset to use e-TeX compatibility mode. latex and pdflatex are only used to process the tex sources for the Reference manual and these have no problem with the current MikTek defaults. The issue with MikTek finding the Rd.sty file is more easily fixed by minor changes to doc/manual/Makefile.win. Change lines 21 - 24 of doc/manual/Makefile.win to read: > RTEX= > ifeq ($(strip $(MIKTEX)),YES) > # Setup MikTEX search path > RTEX=-include-directory=$(RHOME)/share/texmf > endif > > PDFLATEX = pdflatex $(RTEX) > LATEX = latex $(RTEX) > PDFTEX = pdftex $(RTEX) > TEX = tex $(RTEX) So far this all fairly much as the instructions. However, I had no joy getting the Rtools package to provide the rest of what I needed. All my build attempts failed with path errors of one sort or another. Instead I used the Msys 1.0.10 package from MinGW. This provides a minimal set of build tools which includes everything needed except zip.exe and unzip.exe. I used the ones from Rtools and put them in the msys\1.0\local\bin. The only remaining problem was that the makeinfo.exe in Msys is too old. So I used the Msys set up to build makeinfo from texinfo-4.7 sources. This also needed wget and libiconv, which I also built from current sources. The binaries need to go in msys\1.0\local so that they have precedence over the older ones in the msys package. When this was done I had a totally MinGW build setup with no Cygwin binaries and everything understanding the same MinGW path conventions ie C:\foo\bar, C:/foo/bar or /c/foo/bar. I did not need to make any modifications to the Windows PATH other than those made automatically by the installers for the various packages. It all works very nicely to build R from sources using 'make distribution' as described in the manual. If anyone would like a copy of the makeinfo binary to save the trouble of building it, please email me. One final note: If you install the MinGW Msys-DTK rename the perl binaries such as perl.exe which it provides. Otherwise they will be used instead of the ActiveState ones and they don't work. Cheers Bill Northcott __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problems in rgl on MacOS X
I have recently been trying to build rgl on MacOS X 10.4 using R-2.1.1 with gcc-4.0 5026 and gfortran. The R binary I built without problems and it includes libpng and Tcl/ Tk on X11. Rcmdr works correctly. The rgl build produces a large number of warnings like: g++ -no-cpp-precomp -I/Library/Frameworks/R.framework/Resources/ include -I/System/Library/Frameworks/OpenGL.framework/Headers -I/usr/ X11R6/include -DDarwin -DNO_GL_PREFIX -I/usr/X11R6/include -I/usr/ local/include -Wall -pedantic -fno-exceptions -fno-rtti -fno-common -g -O2 -c fps.cpp -o fps.o types.h:76: warning: 'class DestroyHandler' has virtual functions but non-virtual destructor gui.h:55: warning: 'class gui::WindowImpl' has virtual functions but non-virtual destructor gui.h:89: warning: 'class gui::GUIFactory' has virtual functions but non-virtual destructor pixmap.h:39: warning: 'class PixmapFormat' has virtual functions but non-virtual destructor More seriously it breaks in scene.cpp thus: g++ -no-cpp-precomp -I/Library/Frameworks/R.framework/Resources/ include -I/System/Library/Frameworks/OpenGL.framework/Headers -I/usr/ X11R6/include -DDarwin -DNO_GL_PREFIX -I/usr/X11R6/include -I/usr/ local/include -Wall -pedantic -fno-exceptions -fno-rtti -fno-common -g -O2 -c scene.cpp -o scene.o types.h:76: warning: 'class DestroyHandler' has virtual functions but non-virtual destructor gui.h:55: warning: 'class gui::WindowImpl' has virtual functions but non-virtual destructor gui.h:89: warning: 'class gui::GUIFactory' has virtual functions but non-virtual destructor pixmap.h:39: warning: 'class PixmapFormat' has virtual functions but non-virtual destructor scene.cpp: In member function 'void Texture::beginUse(RenderContext*)': scene.cpp:1994: error: invalid conversion from 'int*' to 'GLint*' make: *** [scene.o] Error 1 ERROR: compilation failed for package 'rgl' The compilers complaint appears to be legitimate in gl.h there is: .. typedef short GLshort; typedef long GLint; typedef long GLsizei; extern void glGetHistogramParameteriv (GLenum target, GLenum pname, GLint *params); extern void glGetIntegerv (GLenum pname, GLint *params); extern void glGetLightfv (GLenum light, GLenum pname, GLfloat *params); . and in scene.cpp the relevant lines read: .. unsigned int maxSize; glGetIntegerv(GL_MAX_TEXTURE_SIZE, (int*) &maxSize); ... which seems to give the compiler due cause to barf given the header. I got it to build by changing the code to: GLint maxSize; glGetIntegerv(GL_MAX_TEXTURE_SIZE, (GLint*) &maxSize); but this generates warnings about signed and unsigned further down scene.cpp. The resulting code works but it is clearly not right. I can't find an email address for the maintainer and his web site seems to be off the air just now. Bill Northcott __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] call fortran in R
On 04/08/2005, at 8:00 PM, Sebastien Durand wrote: > I used a mac G5, R.2.1.1, and G77 3.4.4 and I would like to use and > call a fortran subroutine. > The trouble is that it seems I am not able to correctly load the > compiled code. . > base > 2 /Library/Frameworks/R.framework/Resources/library/grDevices/libs/ > grDevices.so > 3 /Library/Frameworks/R.framework/Resources/library/stats/ > libs/stats.so > 4 /Library/Frameworks/R.framework/Resources/library/methods/libs/ > methods.so > 5 /Users/sebas/Desktop/Fortan_kmeans/kmeans3.so > > Dynamic.Lookup > 1 FALSE > 2 FALSE > 3 FALSE > 4 FALSE > 5TRUE I really wish someone would make these issues clear in MacOS R documentation. MacOS X 10.3 Panther uses gcc-3.3 as its default compiler. The R binary is built with gcc-3.3 and g77 3.4 so that it will run on Panther. MacOS X 10.4 Tiger uses gcc-4.00 as its default compiler. This causes two problems. 1. Fortran objects built with g77 cannot be linked with C/C++ objects built with gcc-4.0. So an R package with a mixture of C and Fortran code will very likely fail at some point. 2. Even if you specifically invoke gcc-3.3 and g77 the code will still fail to link because it needs a symlink /usr/lib/ libcc_dynamic.dylib which points to libgcc.a. This link is missing if the default gcc-4.0 is the selected compiler. (It is missing because it does not work with gcc-4). If you want to build Fortran source packages on Tiger using the R binary distribution, you need to to do 'sudo gcc_select 3.3' That command will make gcc-3.3 the default compiler and reinstate the symlink, which recreates the environment in which the R binary was built. You can always go back to gcc-4.0 with 'sudo gcc_select 4.0'. Bill Northcott __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 64 on Intel Mac check problem
On 26/03/2008, at 10:00 PM, Georgios wrote: > I have installed gcc 4.2 and gfortran 4.2 from the available sources > on the > web page and am using the copy and paste guide on the page. > > Now everything seems to be going fine until the point where the R > packages > are tested. In particular when the regression tests are run I get the > following. > > running regression tests > running code in 'reg-tests-1.R' ...\c > OK > running code in 'reg-tests-2.R' ...\c > OK > comparing 'reg-tests-2.Rout' to './reg-tests-2.Rout.save' ...\c > 3756c3756 > < The decimal point is 1 digit(s) to the right of the | > --- >> The decimal point is at the | > 3762c3762 It may or may not be relevant, but there is a catastrophic bug in log10() in 10.5.2 for x86_64: it returns 0 for all arguments. This has been discussed on the Scitech list. Apple think they have fixed it, but I am sure they would want to hear of other cases or possible compiler issues, if it is their compiler you are using. So if you can get a minimal test case it would be very good to submit a bug. It may be worth doing even if you cannot get a minimal case because all the sources are readily available. Finally last time I looked a few days back Simon's 64 bit Intel builds were failing. Bill Northcott __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 64 on Intel Mac check problem
On 27/03/2008, at 11:51 AM, Simon Urbanek wrote: > Yes, the gcc-4.2 is known to be broken for x86_64 as you describe > above (or in fact it miscompiles a few other things, too). > Interestingly llvm-gcc-4.2 suffers from the same problem. That is > the reason why the 64-bit binaries are currently not offered. > Switching to gcc-4.0 breaks other things on other targets, so there > is no universal (and maintainable) solution that I'm aware of. Perhaps we could all file an enhancement bug request to release an updated version of the compiler. Do Apple know that llvm-gcc is affected? Bill __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
