Hi, I am running FreeBSD 11.0-RELEASE-p3. math/R fails to compile after lang/gcc was updated. Please help. Thanks. --- R.bin --- gcc49 -std=gnu99 -O2 -pipe -DLIBICONV_PLUG -fstack-protector -Wl,-rpath=/usr/lcal/lib/gcc49 -isystem /usr/local/include -fno-strict-aliasing -flto -Wl,--expot-dynamic -fopenmp -L../../lib -Wl,-rpath=/usr/local/lib/gcc49 -L/usr/local/li/gcc49 -B/usr/local/bin -L/usr/local/lib -L/usr/local/lib -fstack-protector -Wl-rpath=/usr/local/lib/gcc49 -L/usr/local/lib/gcc49 -o R.bin Rmain.o -lR ../../lib/libR.so: undefined reference to `tre_regfree' ../../lib/libR.so: undefined reference to `tre_version' ../../lib/libR.so: undefined reference to `tre_regnexecb' ../../lib/libR.so: undefined reference to `tre_regexecb' ../../lib/libR.so: undefined reference to `tre_regerror' ../../lib/libR.so: undefined reference to `tre_regwcomp' ../../lib/libR.so: undefined reference to `tre_regaparams_default' ../../lib/libR.so: undefined reference to `tre_regncompb' ../../lib/libR.so: undefined reference to `tre_regaexec' ../../lib/libR.so: undefined reference to `tre_regaexecb' ../../lib/libR.so: undefined reference to `tre_regwexec' ../../lib/libR.so: undefined reference to `tre_regawexec' ../../lib/libR.so: undefined reference to `tre_regexec' ../../lib/libR.so: undefined reference to `tre_regcomp' ../../lib/libR.so: undefined reference to `tre_regcompb' collect2: error: ld returned 1 exit status *** [R.bin] Error code 1 make[5]: stopped in /usr/ports/math/R/work/R-3.3.2/src/main 1 error make[5]: stopped in /usr/ports/math/R/work/R-3.3.2/src/main *** [R] Error code 2 make[4]: stopped in /usr/ports/math/R/work/R-3.3.2/src/main 1 error make[4]: stopped in /usr/ports/math/R/work/R-3.3.2/src/main *** [R] Error code 1 make[3]: stopped in /usr/ports/math/R/work/R-3.3.2/src 1 error make[3]: stopped in /usr/ports/math/R/work/R-3.3.2/src *** [R] Error code 1 make[2]: stopped in /usr/ports/math/R/work/R-3.3.2 1 error make[2]: stopped in /usr/ports/math/R/work/R-3.3.2 ===> Compilation failed unexpectedly.
Unchecking the LTO and OPENMP made math/R to compile and install. But it worked for gcc48 with no issues.
Hi, Thanks for your report. After some testing, I believe the problem is specific to the LTO option. I think you are also correct to suspect the issue is related to the switch from version 4.8 to 4.9 as the default GCC version. Only after the switch to GCC version 4.9 do the following warnings appear. /usr/local/bin/ar: regcomp.o: plugin needed to handle lto object /usr/local/bin/ar: regerror.o: plugin needed to handle lto object /usr/local/bin/ar: regexec.o: plugin needed to handle lto object /usr/local/bin/ar: tre-ast.o: plugin needed to handle lto object /usr/local/bin/ar: tre-compile.o: plugin needed to handle lto object /usr/local/bin/ar: tre-match-approx.o: plugin needed to handle lto object /usr/local/bin/ar: tre-match-backtrack.o: plugin needed to handle lto object /usr/local/bin/ar: tre-match-parallel.o: plugin needed to handle lto object /usr/local/bin/ar: tre-mem.o: plugin needed to handle lto object /usr/local/bin/ar: tre-parse.o: plugin needed to handle lto object /usr/local/bin/ar: tre-stack.o: plugin needed to handle lto object /usr/local/bin/ar: xmalloc.o: plugin needed to handle lto object I haven't found a solution yet, but hopefully will soon.
Fix awaiting review: https://reviews.freebsd.org/D8650
A commit references this bug: Author: jrm Date: Tue Nov 29 21:32:13 UTC 2016 New revision: 427398 URL: https://svnweb.freebsd.org/changeset/ports/427398 Log: Fix build issue when the LTO option is enabled, do not register ${PREFIX}/lib/R/lib with ldconfig, and fix typo. GCC 4.9 now generates slim object files which only contain intermediate language representation for LTO. This means, either -ffat-lto-objects must be used to create files which also contain object code or gcc-ar/gcc-ranlib must be used to create static libraries suitable for LTO processing. This patch sets AR/RANLIB to gcc-ar/gcc-ranlib. The libraries under ${PREFIX}/lib/R/lib are not intended (by upstream) to be registered with ldconfig, but are opened by dlopen(3). This means pkg will not register shared library dependencies, so we will have to adjust and bump ports as necessary. When necessary, unfortunately, is unclear based on how things work upstream. Fix typo: OPENMP_USE=compiler:openmp should have been OPENMP_USES=compiler:openmp. Bump PORTREVISION. PR: 214785 214666 Reported by: taozhenext@gmail.com (214785), dbn (214666) Approved by: swills (mentor) Differential Revision: https://reviews.freebsd.org/D8650 Changes: head/math/R/Makefile head/math/R/pkg-plist
Fix committed. Thanks! Please reopen if necessary.