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 <j...@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
smime.p7s
Description: S/MIME cryptographic signature
