Okay! I've made a ticket for my libvlc issue:
https://trac.macports.org/ticket/58206
I think I'm doing it correctly.
Michael A. Leonetti
As warm as green tea
On 3/18/19 10:37 AM, Michael A. Leonetti wrote:
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.