[Top][All Lists]

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

[Octave-bug-tracker] [bug #57049] Mac build failure: CFLocaleCopyCurrent

From: Andrew Janke
Subject: [Octave-bug-tracker] [bug #57049] Mac build failure: CFLocaleCopyCurrent from CoreFoundation not found
Date: Mon, 14 Oct 2019 19:44:00 -0400 (EDT)
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:69.0) Gecko/20100101 Firefox/69.0

Follow-up Comment #6, bug #57049 (project octave):

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],
     LIBS="$LIBS -Wl,-framework -Wl,CoreFoundation"
          [[#include <CoreFoundation/CFLocale.h>]],
  if test $gt_cv_func_CFLocaleCopyCurrent = yes; then
      [Define to 1 if you have the Mac OS X function CFLocaleCopyCurrent in
the CoreFoundation framework.])


  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"

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.


Reply to this item at:


  Message sent via Savannah

reply via email to

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