Bug 220332 - lang/python27,33,34,35: "cc: error: unsupported option '-print-multi-os-directory'"
Summary: lang/python27,33,34,35: "cc: error: unsupported option '-print-multi-os-direc...
Status: Closed Feedback Timeout
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Walter Schwarzenfeld
Keywords: needs-qa
: 220333 220334 220335 (view as bug list)
Depends on:
Reported: 2017-06-28 12:19 UTC by rozhuk.im
Modified: 2019-08-14 08:40 UTC (History)
4 users (show)

See Also:
bugzilla: maintainer-feedback? (python)

fix "cc: error: unsupported option '-print-multi-os-directory'" (829 bytes, patch)
2017-06-28 12:19 UTC, rozhuk.im
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description rozhuk.im 2017-06-28 12:19:39 UTC
Created attachment 183883 [details]
fix "cc: error: unsupported option '-print-multi-os-directory'"

If option UNSET: LIBFFI    Use libffi from ports instead of bundled version

/usr/include/curses.h:1256:58: note: expanded from macro 'mvwinch'
#define mvwinch(win,y,x)                (wmove((win),(y),(x)) == ERR ? NCURSES_CAST(chtype, ERR) : winch(win))
/usr/include/curses.h:231:34: note: expanded from macro 'NCURSES_CAST'
#define NCURSES_CAST(type,value) (type)(value)
1 warning generated.
cc: error: unsupported option '-print-multi-os-directory'
cc: error: no input files

Python build finished, but the necessary bits to build these modules were not found:
_bsddb             dl                 gdbm            
imageop            linuxaudiodev      spwd            
To find the necessary bits, look in setup.py in detect_modules() for the module's name.
Comment 1 rozhuk.im 2017-08-20 23:10:51 UTC
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 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 freebsd_committer freebsd_triage 2017-08-28 04:26:00 UTC
*** Bug 220333 has been marked as a duplicate of this bug. ***
Comment 4 Kubilay Kocak freebsd_committer freebsd_triage 2017-08-28 04:26:14 UTC
*** Bug 220334 has been marked as a duplicate of this bug. ***
Comment 5 Kubilay Kocak freebsd_committer freebsd_triage 2017-08-28 04:26:32 UTC
*** Bug 220335 has been marked as a duplicate of this bug. ***
Comment 6 Kubilay Kocak freebsd_committer freebsd_triage 2017-08-28 05:12:02 UTC
Tracing it back (scoping to gcc):


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


{ $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



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




See also:

AC_PROG_CC wrongly setting $GCC=yes while clang is used

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_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/ "*)


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

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 freebsd_committer freebsd_triage 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 freebsd_triage 2019-08-14 08:40:44 UTC
No reply from  reporter since two years! Feedback timeout.