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