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.) 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_ClassSymbolInterestintly, 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.) Davor
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 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.