How can I install a MacPorts port that is linked with an earlier MacOS release?

Michael A. Leonetti michael at theleonetti.com
Mon Mar 18 17:01:59 UTC 2019


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.
>>


More information about the macports-users mailing list