Octave link failure with gnulib setlocale, missing CoreFoundation

[Andrew Janke]

Hi, Gnulib folks,

I'm running into a compilation problem with GNU Octave on macOS 10.14.6 
that looks like it could be due to our interaction with gnulib.

Here's the downstream bug report: https://savannah.gnu.org/bugs/?57049.

The build fails in a late link operation that's trying to produce 
liboctave.7.dylib. This links in our libgnu.a archive, which is the 
static file we're building gnulib into.

 libtool: link: clang++ -std=gnu++11 -dynamiclib  -o 
liboctave/.libs/liboctave.7.dylib 
liboctave/.libs/liboctave_la-liboctave-build-info.o 
liboctave/.libs/liboctave_la-version.o 
-Wl,-force_load,liboctave/array/.libs/libarray.a 
-Wl,-force_load,liboctave/external/blas-xtra/.libs/libxerbla.a 
-Wl,-force_load,liboctave/external/ranlib/.libs/libranlib.a 
-Wl,-force_load,liboctave/external/.libs/libexternal.a 
-Wl,-force_load,liboctave/numeric/.libs/libnumeric.a 
-Wl,-force_load,liboctave/operators/.libs/liboperators.a 
-Wl,-force_load,liboctave/system/.libs/libsystem.a 
-Wl,-force_load,liboctave/util/.libs/libutil.a 
-Wl,-force_load,liboctave/wrappers/.libs/libwrappers.a 
-Wl,-force_load,libgnu/.libs/libgnu.a 
-L/usr/local/Cellar/arpack/3.7.0_3/libexec/lib 
-L/usr/local/Cellar/fftw/3.3.8_1/lib -L/usr/local/Cellar/pcre/8.43/lib 
-L/usr/local/opt/qscintilla2/lib -lcurl -lcholmod -lumfpack -lamd -lcamd 
-lcolamd -lccolamd -lcxsparse -lsuitesparseconfig 
/usr/local/Cellar/arpack/3.7.0_3/libexec/lib/libarpack.dylib 
-L/usr/local/opt/openblas/lib -lopenblas -lqrupdate -lfftw3_threads 
-lfftw3 -lfftw3f_threads -lfftw3f -L/usr/local/opt/veclibfort/lib 
-lvecLibFort -lreadline -lncurses -lpcre -ldl 
-L/usr/local/Cellar/gcc/9.2.0_1/lib/gcc/9/gcc/x86_64-apple-darwin18/9.2.0 
-L/usr/local/Cellar/gcc/9.2.0_1/lib/gcc/9/gcc/x86_64-apple-darwin18/9.2.0/../../.. 
-lgfortran -lquadmath -liconv -lm  -pthread -F/usr/local/opt/qt/lib 
-pthread -install_name 
/usr/local/Cellar/octave-default/default/lib/octave/6.0.0/liboctave.7.dylib 
-compatibility_version 8 -current_version 8.0 -Wl,-single_module
Undefined symbols for architecture x86_64:
  "_CFLocaleCopyCurrent", referenced from:
      _gl_locale_name_default in libgnu.a(localename.o)
  "_CFLocaleGetIdentifier", referenced from:
      _gl_locale_name_default in libgnu.a(localename.o)
  "_CFRelease", referenced from:
      _gl_locale_name_default in libgnu.a(localename.o)
  "_CFStringGetCString", referenced from:
      _gl_locale_name_default in libgnu.a(localename.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see 
invocation)
make[2]: *** [liboctave/liboctave.la] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Those undefined symbols are functions from CoreFoundation.

Looking through the autoconf m4 files in gnulib, it looks like 
m4/intlmacosx.m4 has code to pull it in, in the gt_INTL_MACOSX macro. 
However, gt_INTL_MACOSX is only invoked in the m4/gettext.m4 file, in 
AM_GNU_GETTEXT, not from gl_FUNC_SETLOCALE in m4/setlocale.m4. This 
autoconf code seems to be assuming that the CoreFoundation linkage is 
only needed if you're using the gettext gnulib module in addition to the 
setlocale module, or that it's a prereq. But GNU Octave is (sometimes) 
using the gnulb setlocale module without the gettext module.

Could this be a bug in the gnulib autoconf stuff? Or are we using it wrong?

Cheers,
Andrew Janke