When building R 3.2.1 on OpenBSD (amd64 platform) $LIBINTL contains the pathes
to static libraries (libintl.a and libiconv.a):
checking how to link with libintl... /usr/local/lib/libintl.a /usr/local/lib/libiconv.a -lc -Wl,-rpath,/usr/local/lib
... -L../../lib -lRblas -R/usr/local/lib/R/lib -lgfortran -lm -lquadmath /usr/local/lib/libintl.a /usr/local/lib/libiconv.a -lc -Wl,-rpath,/usr/local/lib -lreadline -lncurses -lpcre -llzma -lbz2 -lm -liconv -licuuc -licui18n
However, we would like to use the shared libraries (which do exist as
/usr/local/lib/libiconv.so.6.0 and /usr/local/lib/libintl.so.6.0) instead. At
the moment our fix is to use $LTLIBINTL instead but ideally it would be
possible to avoid patching on OpenBSD side.
For those interested in details:
- Original mail on LIBINTL->LTLIBINTL patches
- Two patches for addressing this problem in the OpenBSD package (search for
If you need further details or have questions please do not hesitate to
This isn't from R, but from m4/gettext.m4 which came from that project.
You'll need to track down why it is preferring static libs. In particular, what
"checking for GNU gettext in libintl... "
is doing on your platform. Note that on a generic ELF platform, you need libintl.so to be present, not just libintl.so.6.0, and it would link to the .so form. That might be what is different ....
(In reply to Brian Ripley from comment #1)
> This isn't from R, but from m4/gettext.m4 which came from that project.
> You'll need to track down why it is preferring static libs. In particular,
> "checking for GNU gettext in libintl... "
> is doing on your platform.
The problem appears to be an outdated version of m4/gettext-lib.m4 shipped
When concatenating lib-ld.m4, lib-link.m4, and lib-prefix.m4 from a recent
upstream gettext and replacing the m4/gettext-lib.m4 in R-devel with it, the
detection now works correctly:
$ cd gettext-0.19.5.1/gettext-runtime/gnulib-m4
$ ls lib-*
lib-ld.m4 lib-link.m4 lib-prefix.m4
$ cat lib-* > ~/src/R-devel/m4/gettext-lib.m4
After regenerating configure
$ rm configure
$ aclocal -I m4
now I have
checking how to link with libintl... /usr/local/lib/libintl.so.6.0 /usr/local/lib/libiconv.so.6.0 -lc -Wl,-rpath,/usr/local/lib
which looks fine to me. Moreover, the build itself also works now without
... -lRblas -R/usr/local/lib/R/lib -lgfortran -lm -lquadmath /usr/local/lib/libintl.so.6.0 /usr/local/lib/libiconv.so.6.0 -lc -Wl,-rpath,/usr/local/lib -lreadline -lncurses -lpcre -llzma -lbz2 -lz -lm -liconv -licuuc -licui18n
Note: it might be necessary to coordinate an update of m4/gettext-lib.m4 with m4/gettext.m4 in the R sources.
There are two parts to this, detecting an external libintl (other than libc), and configuration for the included src/extra/intl.
I have updated the first in R-devel, >= r69088. If this works for you we can port to R-patched. We do not intend to change the included src/extra/intl.
[All of my systems use the included libintl or have this in libc, so my ability to test is limited.]
I decided to experment with an external libintl on Solaris. If I install both static and dynamic versions, both R 3.2.2 and R-devel correctly select the dynamic versions, e.g. in 3.2.2
checking where the gettext function comes from... external libintl
checking how to link with libintl... /usr/local/lib/libintl.so /usr/local/lib/libiconv.so -lc -R/usr/local/lib
So whatever is going on on OpenBSD is not reproducible elsewhere.
R-devel >= r69088 works on OpenBSD and fixes the original problem.
There is no urgent need from my side to port this to R-patched (as we have the necessary patches in place at the moment).
Thank you very much!
The 3.2.x series will be active for several more months, so we may as well port there.