Stack-Based Ports No Longer Building on ARM

[Joshua Root]

My suggested solution is to modify the libunwind port to install 
somewhere else so it isn't found with the default flags, and add 
appropriate flags to any ports that really need that version.

- Josh

On 2022-8-24 22:25 , Steven Smith wrote:
> Thank you! That was the issue: somehow I had native libunwind installed and that was breaking the build.
> 
> What’s the solution to make this robust in case some port installs native libunwind?
> 
> Is there a right way of prepending a system path to the library flags so that the compiler doesn’t find MacPorts’s libunwind? Or is there a way to declare a conflict with MacPorts’s native libunwind? Something like this should probably go into a platform arm {} block in haskell_stack-1.0.tcl.
> 
> Steve
> 
> 
>> On Aug 24, 2022, at 7:43 AM, Joshua Root <jmr at macports.org> wrote:
>>
>> On 2022-8-24 21:20 , Steven Smith wrote:
>>> I’ve observed on my M1 box that stack-based ports no longer build because of compiler issues with mixed architecture libraries, as more ports become native ARM. I’ve done enough troubleshooting (reinstalling CLT, Xcode, use_code=yes and so forth) to believe that this is a general problem—error messages are below.
>>
>> Regarding the libunwind error you're seeing, this is because stack/alex is linking with the libunwind in /opt/local/lib but doesn't declare a dependency on the libunwind port. If a dependency were declared, the port would be installed +universal when needed.
>>
>> But I think a dependency is not appropriate because the system libunwind is probably fine, as it is for most ports. The libunwind port installs an older version which I think is intended to be used on systems that are even older. I'm not sure if all the ports that do declare deps on libunwind really need it, but I think it might be best to install libunwind somewhere other than /opt/local/lib so that innocent bystanders don't accidentally link with it.
>>
>> - Josh
>