Bug 220332

ping

Comment 2 Kubilay Kocak 2017-08-28 04:25:32 UTC

Thank you for your report.

1) The following bugs will be closed duplicates of this bug, given they describe identical symptoms (and likely, conditions and causes):

- bug 220333 (lang/python33)
- bug 220334 (lang/python34)
- bug 220335 (lang/python35)

Pretty cool that the bug numbers match the port versions :)

2) Could you please move the patches from those issues into this one (with obvious descriptions, eg "patch lang/pythonXY")

3) I can see both "cc: error:"'s in a default CURRENT environment having disabled the LIBFFI options, as well as in a poudriere build (12amd64 jail). However, it is not obvious that the error is related to the warnings that just precede it (related to ncurses) and doesn't appear to impact the build or packaging. 

It would be good to get a better idea of where and for what the compiler invocation is failing, along with additional details about the system configuration and the impact you are observing due to the error (if any), including:

- Version of FreeBSD (uname -a)
- Contents of /etc/make.conf if relevant
- Compiler overrides used, if any
- Include a full build log (as an attachment)

4) Is this reproducible for lang/python36?

Additional Notes:

- Python < 3.7 bundles libffi, so accordingly does not receive fixes/updates as often or as quickly. It was removed in 3.7 for this reason [1]

- The print-multi-os-directory block in Modules/_ctypes/libffi/configure.ac appears (intended) to be scoped to GCC

 # These variables are only ever used when we cross-build to X86_WIN32.
 # And we only support this with GCC, so...
 if test "x$GCC" = "xyes"; then

[1] https://bugs.python.org/issue27979
[2] https://hg.python.org/cpython/file/3.6/Modules/_ctypes/libffi/configure.ac#l594

Comment 3 Kubilay Kocak 2017-08-28 04:26:00 UTC

*** Bug 220333 has been marked as a duplicate of this bug. ***

Comment 4 Kubilay Kocak 2017-08-28 04:26:14 UTC

*** Bug 220334 has been marked as a duplicate of this bug. ***

Comment 5 Kubilay Kocak 2017-08-28 04:26:32 UTC

*** Bug 220335 has been marked as a duplicate of this bug. ***

Comment 6 Kubilay Kocak 2017-08-28 05:12:02 UTC

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.

Comment 7 Kubilay Kocak 2017-08-28 05:34:22 UTC

I believe a more correct way scope this block would be to check whether the compiler supports the flag before using it, rather than using the gnu compiler check macro. 

There is an ac_check_compile_flag macro in the autoconf archive [1] that does this. 

This should be reported and submitted upstream at libffi, and then in Python to improve 2.7-3.6. Local patches of these upstream patches could be carried if necessary (if they fix actual issues caused by the bug) in the FreeBSD Ports until newer versions or libffi/Python are released.

[1] https://www.gnu.org/software/autoconf-archive/ax_check_compile_flag.html#ax_check_compile_flag

Comment 8 Walter Schwarzenfeld 2019-08-14 08:40:44 UTC

No reply from  reporter since two years! Feedback timeout.