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
