Stack-Based Ports No Longer Building on ARM

[Steven Smith]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3898 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20220824/07e33784/attachment.bin>