bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Octave link failure with gnulib setlocale, missing CoreFoundation


From: Bruno Haible
Subject: Re: Octave link failure with gnulib setlocale, missing CoreFoundation
Date: Mon, 18 Nov 2019 12:58:40 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-166-generic; KDE/5.18.0; x86_64; ; )

Hi,

Andrew Janke wrote on 2019-10-16:
> 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.

Yes, linker options  -Wl,-framework -Wl,CoreFoundation
could get rid of this link failure. However...

> 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. 

Yes.

> 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.

gt_INTL_MACOSX is also required by gl_LOCALENAME in m4/localename.m4,
part of module 'localename'. And module 'localename' is needed by module
'setlocale', but only if REPLACE_SETLOCALE is 1 - which it only is on
native Windows, Cygwin, and Android.

When building a static library and executables that link with it, there
would be no error, because localename.o would be present in the static
library but not needed by any of the executables on macOS (only on
Windows and Android would it be needed).

However, you are building a shared library. I'd suggest to pass the
option --conditional-dependencies to gnulib-tool. [1] Then you don't
need to link with  -Wl,-framework -Wl,CoreFoundation.

Bruno

[1] 
https://www.gnu.org/software/gnulib/manual/html_node/Conditional-dependencies.html





reply via email to

[Prev in Thread] Current Thread [Next in Thread]