[Rd] R doesn't compile on FreeBSD 10.2
Prof Brian Ripley
ripley at stats.ox.ac.uk
Tue Sep 1 17:12:16 CEST 2015
The datetime.R issue looks familiar. Darwin (the basis for OS X) copied
a lot of things from FreeBSD, bugs and all. So I expect the same remedy
applies (http://cran.r-project.org/doc/manuals/r-patched/R-admin.html#OS-X):
'Configure option --with-internal-tzcode is the default on OS X, as the
system implementation of time zones does not work correctly for times
before 1902 or after 2037 (despite using a 64-bit time_t).'
On 01/09/2015 15:40, Davor Cubranic wrote:
> I tried compiling using GCC. First, I changed config.site to:
> ~/R-3.2.2$ svn diff config.site
> Index: config.site
> ===================================================================
> --- config.site (revision 69236)
> +++ config.site (working copy)
> @@ -278,3 +278,8 @@
>
> ## Path to the version of pkg-config to be used for locating cairographics.
> ## PKGCONF =
> +F77=gfortran48
> +FC=${F77}
> +CC=gcc48
> +CXX=g++48
> +OBJC=gcc48
>
> Then plain-vanilla configure && make worked without a hitch:
>
> ~/R-3.2.2$ ./configure
> [...]
> R is now configured for x86_64-unknown-freebsd10.2
>
> Source directory: .
> Installation directory: /usr/local
>
> C compiler: gcc48 -std=gnu99 -g -O2
> Fortran 77 compiler: gfortran48 -g -O2
>
> C++ compiler: g++48 -g -O2
> C++ 11 compiler: g++48 -std=c++11 -g -O2
> Fortran 90/95 compiler: gfortran48 -g -O2
> Obj-C compiler: gcc48 -g -O2 -fobjc-exceptions
>
> Interfaces supported: X11, tcltk
> External libraries: readline, zlib, bzlib, lzma, PCRE, curl
> Additional capabilities: PNG, JPEG, TIFF, NLS, cairo, ICU
> Options enabled: shared BLAS, R profiling
>
> Capabilities skipped:
> Options not enabled: memory profiling
>
> Recommended packages: yes
>
> "make" completes, and "make check" again fails in datetime.R:
>
> > Sys.setenv(TZ = "Europe/London") # pretty much portable.
> > (z <- as.POSIXct("1848-01-01 12:00"))
> Error in as.POSIXlt.character(x, tz, ...) :
> character string is not in a standard unambiguous format
>
> The next date check is fine, though:
> > (z <- as.POSIXct("2040-01-01 12:00"))
> [1] "2040-01-01 12:00:00 GMT"
>
> as was the 1848 one when TZ="UTC":
> > Sys.setenv(TZ = "UTC")
> > (z <- as.POSIXct("1848-01-01 12:00"))
> [1] "1848-01-01 12:00:00 UTC"
>
> This is probably a quirk of FreeBSD's datetime support, I'll see what
> the port used to do for 3.0.2.
>
> Also, there is an issue tracking updating the port to the current
> release: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195783. I've
> posted the summary of this thread there, thanks for your help.
>
> Davor
>
>
> Prof Brian Ripley writes:
>
>> On 31/08/2015 16:26, Davor Cubranic wrote:
>>> Prof Brian Ripley writes:
>>>
>>>> Second, we don't have all the pertinent information such as the
>>>> configure options used and the architecture (x86_64?). I am going to
>>>> have to guess none as none were mentioned, but using --enable-R-shlib
>>>> would be pertinent.
>>>>
>>>> On 31/08/2015 05:47, Davor Cubranic wrote:
>>>>> On FreeBSD 10.2, I get the following error when compiling R from the
>>>>> Subversion trunk (with "configure && make"):
>>>>
>>>> You have not told us which revision. A basic check is to see if you can
>>>> build the latest released version, as the trunk is 'Under development'.
>>>
>>> As suggested, I tried compiling from Subversion tag 3.2.2 (r69054).
>>> I used no command-line options to 'configure', as mentioned in my
>>> previous email, and this is the output:
>>>
>>> R is now configured for x86_64-unknown-freebsd10.2
>>>
>>> Source directory: .
>>> Installation directory: /usr/local
>>>
>>> C compiler: cc -g -O2
>>> Fortran 77 compiler: gfortran48 -g -O2
>>>
>>> C++ compiler: c++ -g -O2
>>> C++ 11 compiler: c++ -std=c++11 -g -O2
>>> Fortran 90/95 compiler: gfortran48 -g -O2
>>> Obj-C compiler: cc -g -O2 -fobjc-exceptions
>>>
>>> Interfaces supported: X11, tcltk
>>> External libraries: readline, zlib, bzlib, lzma, PCRE, curl
>>> Additional capabilities: PNG, JPEG, TIFF, NLS, cairo, ICU
>>> Options enabled: shared BLAS, R profiling
>>>
>>> Capabilities skipped:
>>> Options not enabled: memory profiling
>>>
>>> Recommended packages: yes
>>>
>>> (I thought this, and more, would be included in config.log, but please
>>> let me know if there is other place to get the configuration details
>>> that are relevant.)
>>
>> You need to tell us exactly which commands you used: nowhere records
>> everything.
>>
>>>
>>> Still the same error:
>>>
>>> --- tools.so ---
>>> cc -shared -L/usr/local/lib -o tools.so text.o init.o Rmd5.o md5.o signals.o install.o getfmts.o http.o gramLatex.o gramRd.o
>>> --- all ---
>>> --- shlib ---
>>> mkdir ../../../../library/tools/libs
>>> --- sysdata ---
>>> installing 'sysdata.rda'
>>> Error in dyn.load(file, DLLpath = DLLpath, ...) :
>>> unable to load shared object '/usr/home/davor/R-3.2.2/library/tools/libs/tools.so':
>>> /usr/home/davor/R-3.2.2/library/tools/libs/tools.so: Undefined symbol "R_ClassSymbol"
>>> Error: unable to load R code in package 'tools'
>>> Execution halted
>>>
>>>> Here is a series of checks for that symbol (results from a working Linux
>>>> system):
>>>>
>>>> auk% nm -g bin/exec/R | grep R_ClassSymbol
>>>> 0000000000962ec0 B R_ClassSymbol
>>>>
>>>> auk% nm -g src/main/main.o | grep R_ClassSymbol
>>>> 0000000000000008 C R_ClassSymbol
>>>>
>>>> auk% nm -g library/tools/libs/tools.so | grep R_ClassSymbol
>>>> U R_ClassSymbol
>>>>
>>>> auk% nm -g src/library/tools/src/gramRd.o | grep R_ClassSymbol
>>>> U R_ClassSymbol
>>>
>>> Interestintly, checking for R_ClassSymbol gives the same output as on
>>> your working Linux system:
>>>
>>> ~/R-3.2.2$ nm -g bin/exec/R | grep R_ClassSymbol
>>> 00000000008f8ff8 B R_ClassSymbol
>>>
>>> ~/R-3.2.2$ nm -g src/main/main.o | grep R_ClassSymbol
>>> 0000000000000008 C R_ClassSymbol
>>>
>>> ~/R-3.2.2$ nm -g library/tools/libs/tools.so | grep R_ClassSymbol
>>> U R_ClassSymbol
>>>
>>> ~/R-3.2.2$ nm -g src/library/tools/src/gramRd.o | grep R_ClassSymbol
>>> U R_ClassSymbol
>>>
>>>> So R_ClassSymbol is unresolved in the tools package and should be
>>>> resolved by loading into the main R executable. On Linux that is
>>>> achieved by the linker flag
>>>>
>>>> -Wl,--export-dynamic
>>>>
>>>> as part of MAIN_LDFLAGS in Makeconf in the top-level directory. We have
>>>> in configure.ac
>>>>
>>>> freebsd*)
>>>> main_ldflags="-export-dynamic"
>>>> shlib_ldflags="-shared"
>>>>
>>>> but those were from the days when FreeBSD used gcc, and it is possible
>>>> that your use of clang[*] requires -Wl,--export-dynamic . If so, add to
>>>> config.site
>>>>
>>>> MAIN_LDFLAGS="-Wl,--export-dynamic"
>>>>
>>>> It would also be worth trying a build with --enable-R-shlib, as that
>>>> resolves R_ClassSymbol and similar differently.
>>>
>>> I tried 'configure --enable-R-shlib', still the same error.
>>>
>>> I then tried adding MAIN_LDFLAGS as you suggested, and the install
>>> worked. Thanks you very much! ("make check" fails in datetime.R, but
>>> that's something I'll follow up in a separate email.)
>>>
>>> Should configure.ac be changed to account for this on FreeBSD's using
>>> clang? (I should probably also try compiling with GCC, which I had to
>>> install anyways for gfortran.)
>>
>> It is more complicated than that, in the absence of any definitive
>> FreeBSD documentation. There are five possibilities:
>>
>> -export-dynamic
>> -rdynamic
>> -Wl,--export-dynamic
>> -Wl,-export-dynamic
>> -Wl,-E
>>
>> The first two work for GCC (and have for a long time, although only the
>> second is currently documented) and are accepted by compilers claiming
>> to be GCC-compliant (clang and icc). That clang does nothing with the
>> first seems a clear bug in clang (at least on some OSes (which from the
>> sources do include FreeBSD) it does support the second and maps it to
>> the fourth). Not least as a compiler called 'gcc' may not be
>> GCC-compliant (that on OS X is based on clang).
>>
>> It seems the GNU linker supports all -WL forms (but only the first and
>> last are documented): some other linkers require the fourth line. And
>> that means that GCC's -rdynamic on ELF platforms is documented to
>> generate a linker flag, -export-dynamic, that the GNU linker is not
>> documented to support.
>>
>> If FreeBSD continues to use ELF and GNU ld, -Wl,--export-dynamic seems
>> the safest choice, but if they change linker (and there are/will be
>> alternatives such as gold and lld) -rdynamic might be more future-proof.
>>
>> It seems R has very few FreeBSD users. The core team cannot be expected
>> to support all minority platforms and we rely on the OS teams to inform
>> us what is required. Now it seems that there *is* a FreeBSD port for R:
>> https://www.freebsd.org/ports/math.html albeit at R 3.0.2 but updated
>> for texinfo 6.0 a couple of months ago, so that is the place to get
>> needed changes recorded.
--
Brian D. Ripley, ripley at stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford
1 South Parks Road, Oxford OX1 3TG, UK
More information about the R-devel
mailing list