[Bug 220332] lang/python27,33,34,35: "cc: error: unsupported option '-print-multi-os-directory'"

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220332

--- Comment #6 from Kubilay Kocak <koobs at FreeBSD.org> ---
Tracing it back (scoping to gcc):

Modules/_ctypes/libffi/configure.ac: 

if test "x$GCC" = "xyes";

Python/configure:

{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_c_compiler_gnu" >&5
$as_echo "$ac_cv_c_compiler_gnu" >&6; }
if test $ac_compiler_gnu = yes; then
  GCC=yes
else
  GCC=
fi

config.log:

...

configure:4152: checking whether we are using the GNU C compiler
configure:4171: cc -c -O2 -pipe -march=sandybridge  -fstack-protector-strong
-fno-strict-aliasing -I/usr/local/include conftest.c >&5
configure:4171: $? = 0
configure:4180: result: yes

...

## ---------------- ##
## Cache variables. ##
## ---------------- ##

...

ac_cv_c_compiler_gnu=yes

...

See also:

AC_PROG_CC wrongly setting $GCC=yes while clang is used
https://lists.gnu.org/archive/html/autoconf/2014-09/msg00022.html

This appears to explain why it is being run in the first place.

However ..

In Modules/_ctypes/libffi/configure:

...

sourced from _ctypes/libffi/m4/libtool.m4

  # Ok, now we have the path, separated by spaces, we can step through it
  # and add multilib dir if necessary...
  lt_tmp_lt_search_path_spec=
  lt_multi_os_dir=/`$CC $CPPFLAGS $CFLAGS $LDFLAGS -print-multi-os-directory
2>/dev/null`
  # ...but if some path component already ends with the multilib dir we assume
  # that all is fine and trust -print-search-dirs as is (GCC 4.2? or newer).
  case "$lt_multi_os_dir; $lt_search_path_spec " in
  "/; "* | "/.; "* | "/./; "* | *"$lt_multi_os_dir "* | *"$lt_multi_os_dir/ "*)
    lt_multi_os_dir=
    ;;
  esac

...

sourced from ctypes/libffi/configure.ac

  multi_os_directory=`$CC $CFLAGS -print-multi-os-directory`
  case $multi_os_directory in
    .) ;; # Avoid trailing /.
    ../*) toolexeclibdir=$toolexeclibdir/$multi_os_directory ;;
  esac


My current (potentially naive/incomplete/incorrect) reading of the code is that
it is (just) a compiler invocation in order to test for multilib support, or
certain values from a compiler that supports that option, which would result in
the observed error output instead for any compiler that didn't (as expected for
clang?, being a NOOP?).

The comment in Modules/_ctypes/libffi/m4/libtool.m4

  # Ok, now we have the path, separated by spaces, we can step through it
  # and add multilib dir if necessary...


That is, the 'if necessary part', appears to be an additional clue that its
just a check, without impact if the expected results are not found.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.