How to have macports-built software use an alternate libc++.dylib ?

[Ken Cunningham]

For purposes of testing newer libc++ versions, and as there are some new features in newer libc++ (filesystem, eg) releases that will soon become attractive, it would be desirable if we could find a way to build software against a different libc++ than the one in the system's lib directory.

I know there are tools in the macOS to do this -- I think the one we would need to use is:

DYLD_LIBRARY_PATH /path/to/alternate/libc++.dylib

And I see in macports.conf that it is possible to have MacPorts use these extra environment variables if desired.

Obviously we'd have to sort out how to not install the new version of libc++ into the sysroot accidentally, but once we secured that end of things, how would we go about building a macports installation against an alternate libc++.dylib that we would keep installed somewhere like ${prefix}/lib/libc++.dylib ?

Best,


Ken



# Extra environment variables to keep. MacPorts sanitizes its
# environment while processing ports, keeping:
# - DISPLAY
# - DYLD_FALLBACK_FRAMEWORK_PATH, DYLD_FALLBACK_LIBRARY_PATH,
#   DYLD_FRAMEWORK_PATH, DYLD_INSERT_LIBRARIES, DYLD_LIBRARY_PATH
# - JAVA_HOME
# - ARCHIVE_SITE_LOCAL, MASTER_SITE_LOCAL, PATCH_SITE_LOCAL
# - PORTSRC
# - ALL_PROXY, FTP_PROXY, http_proxy, HTTPS_PROXY, NO_PROXY, RSYNC_PROXY
# - GROUP, USER
# - COLUMNS, LINES
# Variables listed in extra_env are added to this list. This has no
# default value; setting it is intended for advanced users and is
# unsupported. (Note that sudo(8) sanitizes its environment on OS X 10.5
# and later, so it may have to be configured to pass the desired
# variables to MacPorts.)
#extra_env           	KEEP_THIS THIS_TOO