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
