Bug 16410 - Configure script break on FreeBSD 10
Summary: Configure script break on FreeBSD 10
Alias: None
Product: R
Classification: Unclassified
Component: Installation (show other bugs)
Version: R 3.2.0
Hardware: All FreeBSD
: P5 major
Assignee: R-core
Depends on:
Reported: 2015-06-04 15:46 UTC by Carlos Reyes
Modified: 2015-08-13 07:10 UTC (History)
2 users (show)

See Also:

Configure log on FreeBSD, autoconf 2.69, libtool 2.4.6 (573.95 KB, text/plain)
2015-07-23 04:54 UTC, Davor Cubranic

Note You need to log in before you can comment on or make changes to this bug.
Description Carlos Reyes 2015-06-04 15:46:01 UTC
The R configure script has lines like the following:




It gets confused and thinks I am running FreeBSD 1 instead of 10. The script contains complex logic to figure out the shared library load path. An internal variable, shlibpath_var, remains unset because of the bug. At various points during the configure phase and actual build I was getting errors like this because of the unset variable:

  ${}: bad substitution

The workaround is easy:

  ./configure --host=x86_64-unknown-freebsd9
Comment 1 Davor Cubranic 2015-07-19 17:43:56 UTC
This is caused by configure being produced by an old version of libtool: https://lists.gnu.org/archive/html/libtool-patches/2011-01/msg00035.html

I tried re-running autoconf (version 2.69, the installed libtool is 2.4.6) in the trunk, but got the following errors:

configure.ac:253: error: possibly undefined macro: AM_CONDITIONAL
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:651: error: possibly undefined macro: AC_DISABLE_STATIC
configure.ac:723: error: possibly undefined macro: AC_CHECK_LIBM
configure.ac:1970: error: possibly undefined macro: AM_LANGINFO_CODESET
configure.ac:2654: error: possibly undefined macro: AM_NLS
configure.ac:2658: error: possibly undefined macro: AM_GNU_GETTEXT_VERSION
configure.ac:2659: error: possibly undefined macro: AM_GNU_GETTEXT
Comment 2 Peter Dalgaard 2015-07-19 19:56:18 UTC
The incantations for rebuilding configure can be found here:


Notice that this includes m4/libtool.m4, which is based on Libtool 1.5.6 (last copyright date 2008) and this is likely the file that needs updating. It is a pretty complex beast, so I'm not sure we want to change it in R-patched, but maybe you can tell us the extent of the changes that are necessary.
Comment 3 Davor Cubranic 2015-07-23 04:52:40 UTC
I tried to simply copy over into the 'm4' folder the .m4 files that are available by the current libtool installed on the machine (libtool, ltoptions, ltsugar, ltversion, and lt~obsolete). Running aclocal and autoconf completed with no errors, but I got this error in make:

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
mkdir ../../../../library/tools/libs
installing 'sysdata.rda'
Error in dyn.load(file, DLLpath = DLLpath, ...) : 
  unable to load shared object '/usr/home/davor/R-trunk/library/tools/libs/tools.so':
  /usr/home/davor/R-trunk/library/tools/libs/tools.so: Undefined symbol "R_ClassSymbol"
Error: unable to load R code in package 'tools'
Execution halted
*** Error code 1

make[4]: stopped in /usr/home/davor/R-trunk/src/library/tools
*** Error code 1

make[3]: stopped in /usr/home/davor/R-trunk/src/library/tools
*** Error code 1

make[2]: stopped in /usr/home/davor/R-trunk/src/library
*** Error code 1

make[1]: stopped in /usr/home/davor/R-trunk/src
*** Error code 1

make: stopped in /usr/home/davor/R-trunk

I'll attach config.log, maybe it's missing a required flag.
Comment 4 Davor Cubranic 2015-07-23 04:54:15 UTC
Created attachment 1857 [details]
Configure log on FreeBSD, autoconf 2.69, libtool 2.4.6
Comment 5 Brian Ripley 2015-08-02 12:21:57 UTC
I have made minimal changes to libtool.m4 and hence configure, which should allow configure to run on FreeBSD 10. Please test R-patched >= r68795 .

The remaining issue seems to be specific to you, and you should ask on the R-devel list.

We will update libtool in R-devel, but that involves many more changes which are not safe for a patch update.
Comment 6 Davor Cubranic 2015-08-05 04:40:53 UTC
I can confirm that configure now runs fine with r65823, although I'm still seeing the linker error from comment #3. I'll follow up on R-devel.