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 sunaudiodev To find the necessary bits, look in setup.py in detect_modules() for the module's name. ...
ping
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
*** Bug 220333 has been marked as a duplicate of this bug. ***
*** Bug 220334 has been marked as a duplicate of this bug. ***
*** Bug 220335 has been marked as a duplicate of this bug. ***
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.
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
No reply from reporter since two years! Feedback timeout.