From cubranic at stat.ubc.ca  Tue Sep  1 16:40:36 2015
From: cubranic at stat.ubc.ca (Davor Cubranic)
Date: Tue, 01 Sep 2015 07:40:36 -0700
Subject: [Rd] R doesn't compile on FreeBSD 10.2
In-Reply-To: <55E53CBC.1020004@stats.ox.ac.uk>
References: <86fv302hft.fsf@stat.ubc.ca> <55E449DF.7010403@stats.ox.ac.uk>
	<86si6zzdg5.fsf@stat.ubc.ca> <55E53CBC.1020004@stats.ox.ac.uk>
Message-ID: <86twre2oez.fsf@stat.ubc.ca>

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.



[Rd] R doesn't compile on FreeBSD 10.2
Davor Cubranic