Thanks for writing back!
I agree. I installed a VM immediately with El Capitan and put the latest
version of Xcode supported! It seems like the libvlc MacPorts won't
compile. Looks like there are some issues with the libvlc code like
access/avcapture.m doesn't like @available on line 337 and can't find
os/lock.h in audio_output/coreaudio_common.h on line 35.
I'll post a bug, but El Capitan may just be too old.
Michael A. Leonetti
As warm as green tea
On 3/14/19 5:21 PM, Ryan Schmidt wrote:
On Mar 13, 2019, at 16:12, Mojca Miklavec wrote:
Dear Michael,
On Wed, 13 Mar 2019 at 16:03, Michael A. Leonetti wrote:
How an I install the port packages that support El Capitan (or any specific
MacOS version) and above to link against?
By far the least painful way would be to install El Capitan inside a
VM and build there.
I'll second that. If you want to install ports that will run on El Capitan or
later, the most straightforward way to accomplish that is to do it on a machine
running El Capitan.
The other option would be to contribute patches to provide better
support for doing these kind of builds (which would in fact be
useful). You can ask MacPorts to do universal builds, you can ask it
to link against a different SDK etc., but it mostly lacks better
support for building for an older OS. When I tried to do some
bootstrapping for 10.5 on 10.6 one of the biggest issue was that the
ports sometimes use code that is only executed on a particular OS
version. Even if you set the environmental variables to link against
an older SDK, define the variable for the target OS etc. ... you might
still be bitten by those if-else parts of the code that check what
your current OS is, not the OS you want to target.
Personally I would welcome patches to fix that, but that would
probably take quite some effort.
MacPorts has support for building for older systems, but individual ports may
not support it. If you find any ports that don't support it, it is a bug that
should be fixed.
You will want to begin by uninstalling any ports you had already installed, and set
"buildfromsource always" in macports.conf so that you don't get pre-compiled binaries
from our server which were not built for the OS version you requested. Or you may want to use a
separate MacPorts installation for this project, configured to use a nonstandard prefix; in that
case, "buildfromsource always" is the default; binaries are not available for nonstandard
prefixes.
You can set e.g. "macosx_deployment_target 10.11" in macports.conf. MacPorts
passes this value to every phase of every port's build as an environment variable, so
it's difficult for a port to ignore it. The only ports that would not handle this
correctly are those whose portfile or build systems override this. We have often found
build systems with hardcoded deployment targets. We should clear those when we find them
to allow the MacPorts setting to be used.
You can also set macosx_sdk_version in macports.conf, but Apple recommends that
you always build with the latest SDK regardless what OS you're targeting, so
ideally it should not be necessary to change the SDK version. If it is
necessary to change it, you will probably find many more ports that do not
honor this setting, since each port must individually support it by passing the
required values on to the build system via variables like CFLAGS, CXXFLAGS,
LDFLAGS. MacPorts handles this correctly for autotools ports, and the cmake
portgroup handles it for ports using cmake, but there are many nonstandard
build systems out there that handle it in their own way, which it is up to the
portfile author to correctly determine and account for.
And Mojca correctly mentioned that many ports that vary their behavior based on
OS version do so based on the build OS version, rather than the deployment OS
version, which in some cases is probably not the correct thing to do. Each
instance of an OS version comparison in each Portfile would have to be examined
to see if it is correct or needs to be changed.
P.S: Michael, if you have further questions, please write to the mailing list
addresses at lists.macports.org, rather than the older domain name you used
which was retired in 2016. The older domain still forwards to the new one, but
some users cannot read those forwards due to restrictions imposed by their
email service providers.
