From cubranic at stat.ubc.ca  Wed Sep  2 08:52:37 2015
From: cubranic at stat.ubc.ca (Davor Cubranic)
Date: Tue, 01 Sep 2015 23:52:37 -0700
Subject: [Rd] R doesn't compile on FreeBSD 10.2
In-Reply-To: <55E5C050.6000909@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>
	<86twre2oez.fsf@stat.ubc.ca> <55E5C050.6000909@stats.ox.ac.uk>
Message-ID: <86io7t5n4a.fsf@stat.ubc.ca>


I tried "./configure --with-internal-tzcode && make", but it caused
problems seemingly with any parsing of time. Example:

  ~/R-3.2.2$ make check
  Testing examples for package ?base?
  Testing examples for package ?tools?
  Warning in as.POSIXlt.POSIXct(x, tz) : unknown timezone ''
  Warning in as.POSIXlt.POSIXct(x, tz) : unknown timezone 'GMT'
  Warning in as.POSIXlt.POSIXct(x, tz) :
    unknown timezone 'America/New_York'
    comparing ?tools-Ex.Rout? to ?tools-Ex.Rout.save? ... OK
  [...]
  running code in 'simple-true.R' ... OK
    comparing 'simple-true.Rout' to './simple-true.Rout.save' ...231,237d230
  < Warning messages:
  < 1: In strptime(xx, f <- "%Y-%m-%d %H:%M:%OS", tz = tz) :
  <   unknown timezone ''
  < 2: In strptime(xx, f <- "%Y-%m-%d %H:%M:%OS", tz = tz) :
  <   unknown timezone 'GMT'
  < 3: In strptime(xx, f <- "%Y-%m-%d %H:%M:%OS", tz = tz) :
  <   unknown timezone 'America/New_York'
  *** Error code 1

  Stop.
  [...]

Interestingly, doing the same (using option "--with-internal-tzcode")
with r69235 from the trunk, everything works fine and "make check"
completes with no errors.

Davor


Prof Brian Ripley writes:

> 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.

-- 
Sent with my mu4e



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