bugGNU Octave - Bugs: bug #57049, Mac build failure:...

 
 

bug #57049: Mac build failure: CFLocaleCopyCurrent from CoreFoundation not found

Submitter:  Andrew Janke <apjanke>
Submitted:  Sat 12 Oct 2019 02:43:18 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Build Failure
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Mac OS
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 12 Feb 2020 12:03:54 PM UTC, comment #29: 

Works for me on macOS 10.14.

Sorry for the slow reply! I totally forgot about this bug once it was working again.

Andrew Janke <apjanke>
Mon 04 Nov 2019 03:56:32 AM UTC, comment #28: 

I pushed the changeset here (https://hg.savannah.gnu.org/hgweb/octave/rev/b2d30e873334) after modifying the commit message to follow the GNU standard that we use on the Octave project.

Marking as "Ready for Test".

Rik <rik5>
Group administrator
Mon 04 Nov 2019 02:26:53 AM UTC, comment #27: 

Okay, I tried a few approaches, and most of them worked (insofar as getting the build to succeed and I don't see any new obvious failures in the test suite).

I like @mmuetzel's approach of adding $INTL_MACOSX_LIBS to $GNULIB_LINK_DEPS and $MKOCTFILE_GNULIB_LINK_DEPS in configure.ac the best. It feels "righter" to me at that level. And the note from gnulib's `./bootstrap` says:


Use them in <program>_LDADD when linking a program, or
in <library>_a_LDFLAGS or <library>_la_LDFLAGS when linking a library.


In liboctave/module.mk, $(LIBOCTAVE_LINK_DEPS) is propagated to %canon_reldir%_%canon_reldir%_la_LIBADD, which I think is our equivalent of "<program_>LDADD" here. So that seems right-ish.

Here's a patch: https://savannah.gnu.org/bugs/download.php?file_id=47800. Works for me both under `brew` and a regular build, on macOS 10.14.6.

@cdf, can you test that patch out and see if it works for you too?

Andrew Janke <apjanke>
Mon 04 Nov 2019 12:20:43 AM UTC, comment #26: 

Or maybe it should go in the top-level Makefile.am, added to this line 64?


GNULIB_LINK_DEPS = @GNULIB_LINK_DEPS@


Like this:


GNULIB_LINK_DEPS = @GNULIB_LINK_DEPS@ @INTL_MACOSX_LIBS@



Andrew Janke <apjanke>
Mon 04 Nov 2019 12:14:41 AM UTC, comment #25: 

I think we're on the right track here. Just need to figure out the right way/place to translate the @INTL_MACOSX_LIBS@ autoconf/m4 macro into an environment variable or literal string that the downstream build steps can see. (Not sure if I'm using those terms right.)

It might also be that this should go into liboctave/module.mk as @INTL_MACOSX_LIBS@ in this little bit:


%canon_reldir%_%canon_reldir%_la_LIBADD += \
  libgnu/libgnu.la \
  $(LIBOCTAVE_LINK_DEPS)


I'm attaching a couple different patches to try out the various methods. Please don't merge any of them yet until I've been able to test them more.

Andrew Janke <apjanke>
Sun 03 Nov 2019 10:53:48 PM UTC, comment #24: 

I'm pretty sure that something along the lines in comment #23 is the correct way to go.  Let's wait for testing from Andrew.

Rik <rik5>
Group administrator
Sun 03 Nov 2019 08:11:08 PM UTC, comment #23: 

I crossed with your comment #21. I am seeing the same message on Ubuntu.

What about this change? (I am not sure about the "@" in that message from gnulib though.)

diff -r 39fac14ab25a configure.ac
--- a/configure.ac        Sun Nov 03 10:09:15 2019 -0500
+++ b/configure.ac        Sun Nov 03 21:09:15 2019 +0100
@@ -2758,7 +2758,7 @@

 ### These are recommended by the gnulib bootstrap script:

-GNULIB_LINK_DEPS="$FREXPF_LIBM $FREXP_LIBM $GETHOSTNAME_LIB $LIBSOCKET $LIB_CLOCK_GETTIME $LIB_CRYPTO $LIB_GETLOGIN $LIB_NANOSLEEP $LIB_SELECT $LTLIBICONV $LTLIBINTL $LTLIBTHREAD"
+GNULIB_LINK_DEPS="$FREXPF_LIBM $FREXP_LIBM $GETHOSTNAME_LIB $LIBSOCKET $LIB_CLOCK_GETTIME $LIB_CRYPTO $LIB_GETLOGIN $LIB_NANOSLEEP $LIB_SELECT $LTLIBICONV $LTLIBINTL $LTLIBTHREAD $INTL_MACOSX_LIBS"

 ### FIXME: This is a kluge to transform $libdir/libiconv.dll.a to -liconv.
 ### It would probably be better to fix gnulib to not give us an absolute
@@ -2776,7 +2776,7 @@
   ;;
 esac

-MKOCTFILE_GNULIB_LINK_DEPS="$FREXPF_LIBM $FREXP_LIBM $GETHOSTNAME_LIB $LIBSOCKET $LIB_CLOCK_GETTIME $LIB_CRYPTO $LIB_GETLOGIN $LIB_NANOSLEEP $LIB_SELECT $MKOCTFILE_LIBICONV $LIBINTL $LIBTHREAD"
+MKOCTFILE_GNULIB_LINK_DEPS="$FREXPF_LIBM $FREXP_LIBM $GETHOSTNAME_LIB $LIBSOCKET $LIB_CLOCK_GETTIME $LIB_CRYPTO $LIB_GETLOGIN $LIB_NANOSLEEP $LIB_SELECT $MKOCTFILE_LIBICONV $LIBINTL $LIBTHREAD $INTL_MACOSX_LIBS"

 AC_SUBST(GNULIB_LINK_DEPS)


Markus Mützel <mmuetzel>
Group administrator
Sun 03 Nov 2019 07:48:23 PM UTC, comment #22: 

Running the bootstrap script, I see that localename is pulled in as a dependency of some other module we include. This module requires to run gt_INTL_MACOSX which in turn defines INTL_MACOSX_LIBS. But we seem to not use it in any of our linker flags.
Adding that macro to the correct linker flags would probably fix the issue.

Markus Mützel <mmuetzel>
Group administrator
Sun 03 Nov 2019 07:25:54 PM UTC, comment #21: 

Ah, here's something else. The output of `./bootstrap` says this:


You may need to use the following Makefile variables when linking.
Use them in <program>_LDADD when linking a program, or
in <library>_a_LDFLAGS or <library>_la_LDFLAGS when linking a library.
  $(FREXPF_LIBM)
  $(FRESP_LIBM)
  [...]
  $(LTLIBTHREAD) when linking with libtool, $(LIBTHREAD) otherwise
  @INTL_MACOSX_LIBS@


And variants of all of those variables appear in GNULIB_LINK_DEPS="..." in configure.ac around line 2700, except for "@INTL_MACOSX_LIBS@". Might be we just need to add that in to GNULIB_LINK_DEPS. I'll play around with that, too

Andrew Janke <apjanke>
Sun 03 Nov 2019 06:49:47 PM UTC, comment #20: 

If I am reading that gnulib file correctly, they do not replace setlocale on Mac OS X. Thus, they probably won't provide any linker flags.

It would probably be best to write our own autoconf macro to check if we need to add linker flags. See also Rik's comment #5.

Markus Mützel <mmuetzel>
Group administrator
Sun 03 Nov 2019 06:28:59 PM UTC, comment #19: 

I tried simply enabling the gettext module (https://savannah.gnu.org/bugs/download.php?file_id=47790), but that didn't work. Same link failure for me when building under `brew`.

Andrew Janke <apjanke>
Sun 03 Nov 2019 05:55:37 PM UTC, comment #18: 

The more I look into this, the more I think it is an issue with gnulib's autoconf stuff.

I think we can fix it by patching gnulib's setlocale.m4, as it sits in Octave's own m4/ directory.


$ diff -c gnulib/m4/setlocale.m4 m4/setlocale.m4
*** gnulib/m4/setlocale.m4        2019-11-03 12:05:39.000000000 -0500
--- m4/setlocale.m4        2019-11-03 12:44:47.000000000 -0500
***************
*** 20,25 ****
--- 20,29 ----
        esac
        ;;
    esac
+
+   dnl Sometimes, on Mac OS X, libintl requires linking with CoreFoundation.
+   gt_INTL_MACOSX
+
  ])

  # Prerequisites of lib/setlocale.c.


What's the right way to patch our customized gnulib during the Octave build process? As I understand it, the files in m4/ are copied in during the "./bootstrap" part of the Octave build process. I don't see a patching step anywhere in there. Maybe it could be added in bootstrap_post_import_hook() in bootstrap.conf? (How would it know to only do the patching one time (the first time the file is copied), though?)

As an alternative, if we started using the gnulib gettext module, then it would pull in CoreFoundation correctly as a side effect. But that doesn't seem to be a Good Way to do it, since we don't actually need gettext's functionality.

Andrew Janke <apjanke>
Wed 23 Oct 2019 04:14:29 PM UTC, comment #17: 

I asked upstream on the gnulib mailing list about this a few days ago. No response yet. https://lists.gnu.org/archive/html/bug-gnulib/2019-10/msg00046.html

Andrew Janke <apjanke>
Wed 23 Oct 2019 01:26:52 PM UTC, comment #16: 

Oh, that's interesting! I didn't realize you were outside brew.

I'll make this a priority. Hopefully can find some time tonight to debug it.

Andrew Janke <apjanke>
Wed 23 Oct 2019 01:22:17 PM UTC, comment #15: 

@apjanke


I do not use homebrew (I build manually using macports for dependencies) but I do see this issue

Carlo de Falco <cdf>
Group Member
Wed 23 Oct 2019 01:16:56 PM UTC, comment #14: 

I'm still looking in to it. I believe the first option - getting the flags through autoconf, bootstrap - is feasible; I just haven't figured out how yet. The issue does seem to be Homebrew-specific - my non-brew builds are still working. Just haven't found time to do the debugging yet.

Andrew Janke <apjanke>
Tue 22 Oct 2019 05:59:17 PM UTC, comment #13: 

Is there any resolution for Mac developers?

Is there a way to get the write linker flags through the autoconf, bootstrap mechanism?

Or should we just document that Mac developers need to add these flags?

Or should we unconditionally add these to the linker flags when building on Mac?

Those seem like the three viable options at the moment.

Rik <rik5>
Group administrator
Tue 15 Oct 2019 10:33:13 PM UTC, comment #12: 

The libtool.m4 platform-specific linker options. The libtool.m4 file is copied (or symlinked) into Octave's m4 directory when libtoolize (or bootstrap or autoreconf) runs.

https://git.savannah.gnu.org/cgit/libtool.git/tree/m4/libtool.m4#n1074

Mike Miller <mtmiller>
Group Member
Tue 15 Oct 2019 10:24:17 PM UTC, comment #11: 

Well, I can't actually reproduce the build failure outside of brew. I'm building it directly using my wrapper scripts at https://github.com/apjanke/octave-build. But the link step is succeeding when I do that.

There's a couple differences in what libtool is doing in the two cases. When building inside Homebrew, it's using clang++ as its compiler command. When building outside Homebrew, it's using g++. And outside Homebrew, this gets added to the link step command:


-Wl,-undefined -Wl,dynamic_lookup


If I understand that right, it allows you to build a dylib file with some dangling unresolved symbols that get resolved at library load time. That could well be why the build succeeds in this case, where it fails under Homebrew which is doing stricter linkage.

I don't know why this extra `-undefined dynamic_lookup` is being included in the build in the non-brewed case.

Failed command from a brewed build:


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


Successful command outside brew:


libtool: link:
g++
-std=gnu++11
-dynamiclib
-Wl,-undefined
-Wl,dynamic_lookup
-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/libffi/lib
-L/usr/local/opt/qrupdate/lib
-L/usr/local/opt/qscintilla2/lib
-L/usr/local/opt/readline/lib
-L/usr/local/opt/sundials/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
-g -O2
-F/usr/local/opt/qt/lib
-pthread
-install_name  /tmp/test-octave/lib/octave/6.0.0/liboctave.7.dylib
-compatibility_version 8
-current_version 8.0
-Wl,-single_module


(Line breaks added manually for readability in both cases.)

Anybody know where the `-Wl,-undefined -Wl,dynamic_lookup` is coming from, so I can either remove it in the standalone build and reproduce the link breakage, or add it to my Homebrew formula as a workaround to get the build going?

Andrew Janke <apjanke>
Tue 15 Oct 2019 01:39:11 AM UTC, comment #10: 

The easiest way to test with the latest gnulib is


git clone https://git.savannah.gnu.org/git/gnulib.git gnulib-alt
./bootstrap --gnulib-srcdir=gnulib-alt
...


Or clone gnulib somewhere else and give --gnulib-srcdir=/path/to/other/gnulib.

Mike Miller <mtmiller>
Group Member
Tue 15 Oct 2019 12:13:05 AM UTC, comment #9: 

This might be an upstream bug in gnulib.  You might want to check to see if it has been reported.  If it hasn't then that is probably where it needs to go.

I see these other instances of INTL_MACXOSX_LIBS which might also be relevant.


gnulib/m4/gettext.m4:293:    if test -n "$INTL_MACOSX_LIBS"; then
gnulib/m4/gettext.m4:297:        LIBINTL="$LIBINTL $INTL_MACOSX_LIBS"
gnulib/m4/gettext.m4:298:        LTLIBINTL="$LTLIBINTL $INTL_MACOSX_LIBS"
gnulib/m4/intlmacosx.m4:17:dnl Defines INTL_MACOSX_LIBS.
gnulib/m4/intlmacosx.m4:65:  INTL_MACOSX_LIBS=
gnulib/m4/intlmacosx.m4:69:    INTL_MACOSX_LIBS="-Wl,-framework -Wl,CoreFoundation"
gnulib/m4/intlmacosx.m4:71:  AC_SUBST([INTL_MACOSX_LIBS])


It is also possible that the bug has been fixed.  We keep a static copy of gnulib under Mercurial control that we update occasionally, usually before a new release.  It is possible that updating gnulib would pull in a fix for this.  I never remember the exact sequence to pull and update this subrepo so I'm adding jwe to the CC list.

Rik <rik5>
Group administrator
Tue 15 Oct 2019 12:08:19 AM UTC, comment #8: 

Here's something: That CoreFoundation check for setlocale is done inside `gt_INTL_MACOSX` in m4/intlmacosx.m4. gt_INTL_MACOSX is only invoked from the m4/gettext.m4 file, in AM_GNU_GETTEXT. It's not invoked from gl_FUNC_SETLOCALE inside m4/setlocale.m4.

But the gnulib/m4/gettext.m4 file is not being copied into m4 by `./bootstrap` for me. And I see this in `./bootstrap`'s output:


autoreconf: configure.ac: not using Gettext


I read that as indicating that the Octave build is not using the gnulib gettext module.

I read through some of the gnulib stuff, and it seems to think that the setlocale dependency on CoreFoundation only happens when you're using libintl and gettext. (I hope I'm saying that right.) Perhaps it's mistaken about this, and it's not seeing that in a case like ours, the setlocale module still needs CoreFoundation even if the gettext module is not also used. This would be a bug in gnulib itself, not in Octave's use of it, I think.

Andrew Janke <apjanke>
Mon 14 Oct 2019 11:47:12 PM UTC, comment #7: 


> You might try "make maintainer-clean" to clear out most cruft.


This build is done using a fresh clone or export of the Octave repo each time. The only things the build process is doing are applying a couple patches, running `./bootstrap`, and then `configure && make` from inside a `build/` subdirectory. I don't think there's any cruft leftover from previous builds.

Andrew Janke <apjanke>
Mon 14 Oct 2019 11:44:00 PM UTC, comment #6: 

That seems like a bit of a hack. CoreFoundation is an indirect dependency: it's only needed because gnulib uses it. And gnulib provides autoconf stuff to pull in those libraries. I'd think that if that were working properly and Octave were using it properly, we'd pick up that framework automatically through our gnulib linkage, instead of having to pull it in ourselves.

The `m4/intlmacosx.m4` file provided by gnulib and (I think) generated by running `./bootstrap` contains this autoconf code for picking up CoreFoundation when CFLocaleCopyCurrent is needed.


  dnl Check for API introduced in Mac OS X 10.5.
  AC_CACHE_CHECK([for CFLocaleCopyCurrent], [gt_cv_func_CFLocaleCopyCurrent],
    [gt_save_LIBS="$LIBS"
     LIBS="$LIBS -Wl,-framework -Wl,CoreFoundation"
     AC_LINK_IFELSE(
       [AC_LANG_PROGRAM(
          [[#include <CoreFoundation/CFLocale.h>]],
          [[CFLocaleCopyCurrent();]])],
       [gt_cv_func_CFLocaleCopyCurrent=yes],
       [gt_cv_func_CFLocaleCopyCurrent=no])
     LIBS="$gt_save_LIBS"])
  if test $gt_cv_func_CFLocaleCopyCurrent = yes; then
    AC_DEFINE([HAVE_CFLOCALECOPYCURRENT], [1],
      [Define to 1 if you have the Mac OS X function CFLocaleCopyCurrent in the CoreFoundation framework.])
  fi

[...]

  INTL_MACOSX_LIBS=
  if test $gt_cv_func_CFPreferencesCopyAppValue = yes \
     || test $gt_cv_func_CFLocaleCopyCurrent = yes \
     || test $gt_cv_func_CFLocaleCopyPreferredLanguages = yes; then
    INTL_MACOSX_LIBS="-Wl,-framework -Wl,CoreFoundation"
  fi
  AC_SUBST([INTL_MACOSX_LIBS])


It seems to me that that is where Octave should be picking up CoreFoundation. I'm not enough of an autoconf expert to trace through this and figure out what's going on, though.

Andrew Janke <apjanke>
Sun 13 Oct 2019 03:00:50 PM UTC, comment #5: 

If this is a general (but new) requirement for Mac systems then a configure test should be written to determine when it is required and then LDFLAGS changed.

There is already a macro OCTAVE_HAVE_FRAMEWORK in m4/acinclude.m4 which can be used to check whether a particular framework (like Carbon) exists.

See this example in configure.ac


### Check for the Carbon framework on macOS systems.

OCTAVE_HAVE_FRAMEWORK([Carbon],
  [[#include <Carbon/Carbon.h>]], [[CGMainDisplayID ()]],
  [have_framework_carbon=yes], [have_framework_carbon=no])
if test $have_framework_carbon = yes; then
  AC_DEFINE(HAVE_FRAMEWORK_CARBON, 1,
    [Define to 1 if framework CARBON is available.])
  CARBON_LIBS="-framework Carbon"
  AC_MSG_NOTICE([adding -framework Carbon to CARBON_LIBS])
  AC_SUBST(CARBON_LIBS)
fi


Maybe something similar should exist for framework CoreFoundation.  The CARBON libraries themselves are pulled in via this statement in configure.ac


LIBOCTINTERP_LINK_DEPS="$FT2_LIBS $HDF5_LIBS $MAGICK_LIBS $Z_LIBS $FFTW_XLIBS $OPENGL_LIBS $FONTCONFIG_LIBS $FREETYPE_LIBS $X11_LIBS $CARBON_LIBS $GL2PS_LIBS $LLVM_LIBS $JAVA_LIBS $LAPACK_LIBS"


There are similar LINK_DEPS for LIBOCTAVE if that is where the dependency belongs.

Rik <rik5>
Group administrator
Sun 13 Oct 2019 05:42:36 AM UTC, comment #4: 

Hi,

I have been seeing the same issue and working around it by
setting


 LDFLAGS="-O2 -g -Wl,-framework -Wl,CoreFoundation "


when running configure

Carlo de Falco <cdf>
Group Member
Sat 12 Oct 2019 11:57:12 PM UTC, comment #3: 

gnulib-comp.m4 is an auto-generated file (not part of Octave distribution).

You might try "make maintainer-clean" to clear out most cruft.

Then do


hg stat -in m4 > i.list
rm `cat i.list`


There is nothing under version control in the libgnu/ directory so you can just remove that entirely


rm -rf libgnu/


Then you can run the usual


bootstrap
configure
make


sequence.

If removing the cruft doesn't work then it probably means throwing some compilation flags or ordering them differently specifically on the Mac platform.

Rik <rik5>
Group administrator
Sat 12 Oct 2019 03:02:31 PM UTC, comment #2: 

Maybe m4/gnulib-comp.m4 needs to be updated? These references to CoreFoundation is from the gnulib setlocale and localename modules (I think), and I don't see anything about setlocale or localename in m4/gnulib-comp.m4.

Andrew Janke <apjanke>
Sat 12 Oct 2019 02:54:52 PM UTC, comment #1: 

Err, autotools, not CMake.

Andrew Janke <apjanke>
Sat 12 Oct 2019 02:43:18 PM UTC, original submission:  

I'm getting a build failure on default on macOS 10.14.6 with Xcode 10.2.1.

To reproduce with Homebrew:

brew tap octave-app/octave-app
brew install octave-default

The build fails at one of the late link steps that produces liboctave.7.dylib.


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


CFLocaleCopyCurrent and friends are defined in the Mac Core Foundation framework.

Core Foundation is being linked in an earlier build step that looks like it's working on just gnulib.


/bin/sh ../libtool  --tag=CC   --mode=link clang  -I/Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/include -I/Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/include/darwin  -no-undefined          -liconv   -Wl,-framework -Wl,CoreFoundation -liconv -L/usr/local/opt/qscintilla2/lib -F/usr/local/opt/qt/lib -o libgnu.la  allocator.lo areadlink.lo areadlink-with-size.lo base64.lo bitrotate.lo c-ctype.lo c-strcasecmp.lo c-strncasecmp.lo canonicalize.lo careadlinkat.lo cloexec.lo af_alg.lo md2.lo md4.lo md5.lo sha1.lo sha256.lo sha512.lo dirname.lo basename.lo dirname-lgpl.lo basename-lgpl.lo stripslash.lo exitfail.lo fd-hook.lo fd-safer-flag.lo dup-safer-flag.lo file-set.lo filemode.lo filenamecat-lgpl.lo freading.lo getprogname.lo hard-locale.lo hash.lo hash-pjw.lo hash-triple.lo localcharset.lo localename.lo localename-table.lo glthread/lock.lo malloca.lo math.lo nproc.lo nstrftime.lo openat-die.lo progname.lo same.lo save-cwd.lo malloc/scratch_buffer_grow.lo malloc/scratch_buffer_grow_preserve.lo malloc/scratch_buffer_set_array_size.lo sig-handler.lo sockets.lo stat-time.lo striconveh.lo striconveha.lo strnlen1.lo sys_socket.lo tempname.lo glthread/threadlib.lo glthread/tls.lo tmpdir.lo u64.lo unicase/cased.lo unicase/empty-prefix-context.lo unicase/empty-suffix-context.lo unicase/ignorable.lo unicase/special-casing.lo unicase/tolower.lo unicase/toupper.lo unicase/u8-casemap.lo unicase/u8-tolower.lo unicase/u8-toupper.lo uniconv/u32-conv-to-enc.lo uniconv/u8-conv-from-enc.lo uniconv/u8-conv-to-enc.lo unictype/combiningclass.lo unictype/ctype_alnum.lo unictype/ctype_alpha.lo unictype/ctype_blank.lo unictype/ctype_cntrl.lo unictype/ctype_digit.lo unictype/ctype_graph.lo unictype/ctype_lower.lo unictype/ctype_print.lo unictype/ctype_punct.lo unictype/ctype_space.lo unictype/ctype_upper.lo unictype/ctype_xdigit.lo unictype/pr_soft_dotted.lo uninorm/decompose-internal.lo uninorm/u8-normalize.lo unistd.lo dup-safer.lo fd-safer.lo pipe-safer.lo unistr/u32-mblen.lo unistr/u32-to-u8.lo unistr/u8-check.lo unistr/u8-cpy.lo unistr/u8-mblen.lo unistr/u8-mbtouc.lo unistr/u8-mbtouc-aux.lo unistr/u8-mbtouc-unsafe.lo unistr/u8-mbtouc-unsafe-aux.lo unistr/u8-mbtoucr.lo unistr/u8-prev.lo unistr/u8-strmblen.lo unistr/u8-strmbtouc.lo unistr/u8-to-u32.lo unistr/u8-uctomb.lo unistr/u8-uctomb-aux.lo wctype-h.lo xmalloc.lo xalloc-die.lo xgetcwd.lo xsize.lo xstrndup.lo asnprintf.lo chdir-long.lo error.lo fflush.lo fnmatch.lo fpurge.lo fseek.lo fseeko.lo fstatat.lo getcwd.lo getcwd-lgpl.lo getlogin_r.lo getopt.lo getopt1.lo glob.lo glob_pattern_p.lo globfree.lo link.lo localtime-buffer.lo lstat.lo mempcpy.lo memrchr.lo mkfifo.lo mktime.lo nanosleep.lo open.lo openat.lo openat-proc.lo printf-args.lo printf-parse.lo putenv.lo readlink.lo secure_getenv.lo stat.lo strerror.lo strerror-override.lo symlink.lo time_rz.lo timegm.lo unlink.lo vasnprintf.lo  -lm


But it's not being included in the link step for liboctave.

The only references to CoreFoundation I see in the source tree are inside gnulib.


$ grep -r CoreFoundation *
gnulib/ChangeLog:        * lib/setlocale.c: Include header files for CoreFoundation. Declare
gnulib/lib/setlocale.c:#  include <CoreFoundation/CFLocale.h>
gnulib/lib/setlocale.c:#  include <CoreFoundation/CFPreferences.h>
gnulib/lib/setlocale.c:# include <CoreFoundation/CFPropertyList.h>
gnulib/lib/setlocale.c:# include <CoreFoundation/CFArray.h>
gnulib/lib/setlocale.c:# include <CoreFoundation/CFString.h>
gnulib/lib/localename.c:# include <CoreFoundation/CFString.h>
gnulib/lib/localename.c:#  include <CoreFoundation/CFLocale.h>
gnulib/lib/localename.c:#  include <CoreFoundation/CFPreferences.h>
gnulib/lib/localename.c:    /* Cache the locale name, since CoreFoundation calls are expensive.  */
gnulib/m4/gettext.m4:  dnl Sometimes, on Mac OS X, libintl requires linking with CoreFoundation.
gnulib/m4/intlmacosx.m4:     LIBS="$LIBS -Wl,-framework -Wl,CoreFoundation"
gnulib/m4/intlmacosx.m4:          [[#include <CoreFoundation/CFPreferences.h>]],
gnulib/m4/intlmacosx.m4:      [Define to 1 if you have the Mac OS X function CFPreferencesCopyAppValue in the CoreFoundation framework.])
gnulib/m4/intlmacosx.m4:     LIBS="$LIBS -Wl,-framework -Wl,CoreFoundation"
gnulib/m4/intlmacosx.m4:          [[#include <CoreFoundation/CFLocale.h>]],
gnulib/m4/intlmacosx.m4:      [Define to 1 if you have the Mac OS X function CFLocaleCopyCurrent in the CoreFoundation framework.])
gnulib/m4/intlmacosx.m4:     LIBS="$LIBS -Wl,-framework -Wl,CoreFoundation"
gnulib/m4/intlmacosx.m4:          [[#include <CoreFoundation/CFLocale.h>]],
gnulib/m4/intlmacosx.m4:      [Define to 1 if you have the Mac OS X function CFLocaleCopyPreferredLanguages in the CoreFoundation framework.])
gnulib/m4/intlmacosx.m4:    INTL_MACOSX_LIBS="-Wl,-framework -Wl,CoreFoundation"
$


Maybe those CMake things to include CoreFoundation aren't being propagated up to the liboctave build configuration properly?

Full build logs attached.

Andrew Janke <apjanke>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #47800:  octave-link-gnulib-mac-deps_try-05.patch added by apjanke (2KiB - application/octet-stream - Try linking $INTL_MACOSX_LIBS in configure.ac for both regular and mkoctfile cases)
file #47799:  octave-link-gnulib-mac-deps_try-04.patch added by apjanke (1KiB - application/octet-stream - Try linking @INTL_MACOSX_LIBS@ in Makefile.am)
file #47797:  octave-link-gnulib-mac_deps_try-03.patch added by apjanke (1KiB - application/octet-stream - Try linking @INTL_MACOSX_LIBS@ in liboctave/module.mk)
file #47796:  octave-default_build-logs_apj-with-patch-47795_angharad-20191103_01.zip added by apjanke (385KiB - application/zip - My build under brew with $INTL_MACOSX_LIBS in configure.ac)
file #47795:  octave-link-gnulib-mac-deps_try-02.patch added by apjanke (1KiB - application/octet-stream - Try linking with $INTL_MACOSX_LIBS in configure.ac)
file #47793:  octave-link-CoreFoundation.patch added by apjanke (3KiB - application/octet-stream)
file #47790:  octave-use-gnulib-gettext.patch added by apjanke (737B - application/octet-stream)
file #47660:  octave-build-failure-CF-linkage-2019_10_11-apj.tgz added by apjanke (370KiB - application/x-gzip - brew build log from failed build)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by cdf (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by apjanke (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 13 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-11-10 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2019-11-04 rik5 StatusConfirmed Ready For Test
    2019-11-04 apjanke Attached File- Added octave-link-gnulib-mac-deps_try-05.patch, #47800
    2019-11-04 apjanke Attached File- Added octave-link-gnulib-mac-deps_try-04.patch, #47799
    2019-11-04 apjanke Attached File- Added octave-link-gnulib-mac_deps_try-03.patch, #47797
    2019-11-04 apjanke Attached File- Added octave-default_build-logs_apj-with-patch-47795_angharad-20191103_01.zip, #47796
    2019-11-04 apjanke Attached File- Added octave-link-gnulib-mac-deps_try-02.patch, #47795
    2019-11-03 rik5 StatusNone Confirmed
    2019-11-03 apjanke Attached File- Added octave-link-CoreFoundation.patch, #47793
    2019-11-03 apjanke Attached File- Added octave-use-gnulib-gettext.patch, #47790
    2019-10-15 rik5 Carbon-Copy- Added jwe
    2019-10-12 apjanke Attached File- Added octave-build-failure-CF-linkage-2019_10_11-apj.tgz, #47660

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code