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