python35: fails to build due to "dyld: Symbol not found: _utimensat"

[lbschenkel (Leonardo Brondani Schenkel)]

Since I use LibreSSL, Python needs to be rebuilt from source on my machine. In the latest version, 3.5.4_2, I started experiencing the following issue:

running install
running build
running build_ext
INFO: Can't locate Tcl/Tk libs and/or headers

Python build finished successfully!
The necessary bits to build these optional modules were not found:
_dbm                  _tkinter              nis
ossaudiodev           spwd
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

The following modules found by detect_modules() in setup.py, have been
built by the Makefile instead, as configured by the Setup files:
atexit                pwd                   time
running build_scripts
copying and adjusting /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_python35/python35/work/Python-3.5.4/Tools/scripts/pydoc3 -> build/scripts-3.5
copying and adjusting /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_python35/python35/work/Python-3.5.4/Tools/scripts/idle3 -> build/scripts-3.5
copying and adjusting /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_python35/python35/work/Python-3.5.4/Tools/scripts/2to3 -> build/scripts-3.5
copying and adjusting /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_python35/python35/work/Python-3.5.4/Tools/scripts/pyvenv -> build/scripts-3.5
changing mode of build/scripts-3.5/pydoc3 from 644 to 755
changing mode of build/scripts-3.5/idle3 from 644 to 755
changing mode of build/scripts-3.5/2to3 from 644 to 755
changing mode of build/scripts-3.5/pyvenv from 644 to 755
renaming build/scripts-3.5/pydoc3 to build/scripts-3.5/pydoc3.5
renaming build/scripts-3.5/idle3 to build/scripts-3.5/idle3.5
renaming build/scripts-3.5/2to3 to build/scripts-3.5/2to3-3.5
renaming build/scripts-3.5/pyvenv to build/scripts-3.5/pyvenv-3.5
running install_lib
creating /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_python35/python35/work/destroot/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/lib-dynload
creating /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_python35/python35/work/destroot/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/lib-dynload/__pycache__
copying build/lib.macosx-10.12-x86_64-3.5/__pycache__/_sysconfigdata.cpython-35.opt-1.pyc -> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_python35/python35/work/destroot/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/lib-dynload/__pycache__
dyld: lazy symbol binding failed: Symbol not found: _utimensat
  Referenced from: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_python35/python35/work/Python-3.5.4/Python.framework/Versions/3.5/Python
  Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: _utimensat
  Referenced from: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_python35/python35/work/Python-3.5.4/Python.framework/Versions/3.5/Python
  Expected in: /usr/lib/libSystem.B.dylib

make: *** [sharedinstall] Abort trap: 6
make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_python35/python35/work/Python-3.5.4'
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_python35/python35/work/Python-3.5.4" && /usr/bin/make -w frameworkinstall maninstall MAKE="/usr/bin/make CC=/usr/bin/clang" DESTDIR=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_python35/python35/work/destroot
Exit code: 2
Error: Failed to destroot python35: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_python35/python35/main.log for details.
Error: rev-upgrade failed: Error rebuilding python35
Error: Follow https://guide.macports.org/#project.tickets to report a bug.

By searching in Trac I believe that this is actually related to a recent upgrade of Xcode (Xcode 9.0 9A235 on macOS 10.12.6 16G29), because I saw similar recent reports for other ports.

[jmroot (Joshua Root)]

This would be due to building against the 10.13 SDK. This sort of thing is why we don't support building with an older deployment target and a current SDK in general. Anything that detects features at build time instead of runtime gets it wrong.

[lbschenkel (Leonardo Brondani Schenkel)]

Since the App Store will keep "pushing" the update to anybody with 8.0 installed, I presume a sizeable chunk of MacPorts users will end up with 9.0 installed in the near future. That's how I ended up with it: simply accepted all updates, realized Xcode got updated after the fact.

Should I downgrade or is there any way I can "tame" Xcode 9?

[jmroot (Joshua Root)]

In 983af6868686a23ff9202701dba1dae5d9327800/macports-ports:

python35: fix build with 10.13 SDK on 10.12

No rev bump needed as the build failed.
Fixes: #54893

[lbschenkel (Leonardo Brondani Schenkel)]

Btw, when I do a port cat python35 I can see the changes you've made but the port still fails to build with the exact same error.

I also tried to install python36 and the same problem manifests. I didn't try all 3.x versions yet, though.

[jmroot (Joshua Root)]

I actually can't reproduce this. Configuring python36 with Xcode 9 gives this in the config.log:

configure:11279: checking for utimensat
configure:11279: /usr/bin/clang -o conftest -pipe -Os -arch x86_64 -I/opt/local/include -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 conftest.c -lintl -ldl  >&5
Undefined symbols for architecture x86_64:
  "_utimensat", referenced from:
      _main in conftest-c2bb0b.o

So HAVE_UTIMENSAT is never defined, so posixmodule.c never tries to use utimensat.

[lbschenkel (Leonardo Brondani Schenkel)]

Hmmm... What should I do next? Should I put a full debug and config log?

[lbschenkel (Leonardo Brondani Schenkel)]

Just the relevant snippet for now: port configure python36

configure:11279: checking for utimensat
configure:11279: /usr/bin/clang -o conftest -pipe -Os -arch x86_64 -I/opt/local/include -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 conftest.c -lintl -ldl  >&5
configure:11279: $? = 0
configure:11279: result: yes

I'm thinking out loud here: do you have command line tools installed? (I don't, since no port required it so far.) If you do, could it be that your headers in /usr/include (for 10.12) are the ones being picked up and for me the ones inside Xcode (10.13) are the ones being used? I would have mentioned that before, but just now while trying to reason about the difference between our boxes I realized that I don't have the command line tools.

[jmroot (Joshua Root)]

Complete logs wouldn't hurt yeah.

[jmroot (Joshua Root)]

Replying to lbschenkel:

I'm thinking out loud here: do you have command line tools installed? (I don't, since no port required it so far.) If you do, could it be that your headers in /usr/include (for 10.12) are the ones being picked up and for me the ones inside Xcode (10.13) are the ones being used? I would have mentioned that before, but just now while trying to reason about the difference between our boxes I realized that I don't have the command line tools.

Yes, I do have CLT installed.

[lbschenkel (Leonardo Brondani Schenkel)]

I'm attaching the the complete build and config logs. I have compressed them due to the size.

[jmroot (Joshua Root)]

I really don't get why this doesn't work. Apparently the symbol is non-null but still not usable. Either I don't understand how to use weak linking or it's not working.

Could you do a build with debug symbols on (configure.optflags=-g) just to confirm that it's failing where I think it is?

[lbschenkel (Leonardo Brondani Schenkel)]

Attaching new build log. I hope I did it right by changing the Portfile and including configure.optflags=-g.

[lbschenkel (Leonardo Brondani Schenkel)]

With configure.optflags=-g

[jmroot (Joshua Root)]

Sorry, I should have specified: the line number information will be in the backtrace in the crash report that is generated in ~/Library/Logs/DiagnosticReports/.

[lbschenkel (Leonardo Brondani Schenkel)]

Crash report. Redacted some machine idenfiers.

[jmroot (Joshua Root)]

Are you sure that's the right one? It might actually be in /Library rather than ~/Library since builds don't run as your user.

[lbschenkel (Leonardo Brondani Schenkel)]

You're right. I attached the right one now.

[jmroot (Joshua Root)]

Thanks. Unfortunately that's not as helpful as I'd hoped.

[jmroot (Joshua Root)]

Reported upstream: ​https://bugs.python.org/issue31601

[lbschenkel (Leonardo Brondani Schenkel)]

Thanks for the help. I know how difficult it is to diagnose/fix this. I reported in the interest of letting you know and hoping that there could be a simple fix/workaround that would add 10.12+Xcode 9 compatibility so other users could benefit. It may not be that simple.

Personally I can either downgrade Xcode to 8 or upgrade macOS to 10.13. I'm going to wait for a few days and decide what to do.

[lbschenkel (Leonardo Brondani Schenkel)]

Hello again, I found a workaround. The idea is not mine, I saw the same issue happened with Homebrew and saw how the people over there fixed it. They made a global environment override to "help" autotools: ​https://github.com/Homebrew/brew/pull/3182/files

So I tried including this in the Portfile:

configure.env ac_cv_func_futimens=no ac_cv_func_utimensat=no

and it worked! It's not super elegant, but it does the job.

Naturally this workaround just needs to be activated on 10.12 or earlier, since 10.13 includes the functions.

I don't know if MacPorts has a mechanism to do this, but maybe this could be set by MacPorts globally to avoid having to implement the same workaround in all affected ports.

[lbschenkel (Leonardo Brondani Schenkel)]

Given that upstream seems to be dragging their feet on this, should we implement the workaround downstream or just close this?

[jmroot (Joshua Root)]

AFAICT, this isn't an issue if you have the CLTs installed, which is why that's part of the MacPorts installation instructions.