osxbom: switch to lib-style dependency on libunwind

[cooljeanius]

In https://trac.macports.org/ticket/66250 it says that Macports-built libunwind can cause problems with other ports. This PR tweaks osxbom's dependency on libunwind to use a lib:-style dependency instead, so that the system libunwind can satisfy it instead.

Description

Type(s)

• enhancement

Tested on

macOS 15.5 24F74 x86_64
Xcode 16.4 16F6

Verification

Have you

• followed our Commit Message Guidelines?
• squashed and minimized your commits?
• checked that there aren't other open pull requests for the same change?
• referenced existing tickets on Trac with full URL in commit message?
• checked your Portfile with port lint?
• tried existing tests with sudo port test?
• tried a full install with sudo port -vst install?
• tested basic functionality of all binary files?
• checked that the Portfile's most important variants haven't been broken?

[ryandesign]

Why are the libmacho and libmacho-headers dependencies needed at all? I tried removing them from the port and was still able to build it.

[cooljeanius]

Why are the libmacho and libmacho-headers dependencies needed at all? I tried removing them from the port and was still able to build it.

I think they were discovered by trace mode

[ryandesign]

I asked because I recalled a previous instance where I dealt with libmacho and could not understand why we had ports for it when it's part of the OS.

Apparently the libmacho we have in MacPorts is newer than what is in old macOS so I guess that's better for some things.

I also kind of assumed it was like libunwind in causing problems for other ports, but perhaps the problem is not general. (The above-referenced ticket was specific to wine and the user intentionally disabling other ports' universal variants which wine needed.)

Per another old ticket, the libmacho-headers port is intended to be used when you're using the libmacho port. You're using one but not the other. Would the libmacho library be used if you added a dependency on that port? If so, let's add that. And if not, how does this port use the headers but not the library?

[reneeotten]

@cooljeanius is there any indication that there is an issue with libunwind? If we would want to merge this PR, then please at least address @ryandesign his comments. It has been almost three months, so let's either wrap this up or close it.

[reneeotten]

Feel free to reopen once you have responded to the review comments.

[cooljeanius]

I asked because I recalled a previous instance where I dealt with libmacho and could not understand why we had ports for it when it's part of the OS.

Apparently the libmacho we have in MacPorts is newer than what is in old macOS so I guess that's better for some things.

I also kind of assumed it was like libunwind in causing problems for other ports, but perhaps the problem is not general. (The above-referenced ticket was specific to wine and the user intentionally disabling other ports' universal variants which wine needed.)

Per another old ticket, the libmacho-headers port is intended to be used when you're using the libmacho port. You're using one but not the other. Would the libmacho library be used if you added a dependency on that port? If so, let's add that. And if not, how does this port use the headers but not the library?

The configure script checks for <mach-o/arch.h>, which is used for the type NXArchInfo, which... I guess I don't actually currently use, so I can remove it... let me do that and then reopen...

[cooljeanius]

I asked because I recalled a previous instance where I dealt with libmacho and could not understand why we had ports for it when it's part of the OS.
Apparently the libmacho we have in MacPorts is newer than what is in old macOS so I guess that's better for some things.
I also kind of assumed it was like libunwind in causing problems for other ports, but perhaps the problem is not general. (The above-referenced ticket was specific to wine and the user intentionally disabling other ports' universal variants which wine needed.)
Per another old ticket, the libmacho-headers port is intended to be used when you're using the libmacho port. You're using one but not the other. Would the libmacho library be used if you added a dependency on that port? If so, let's add that. And if not, how does this port use the headers but not the library?

The configure script checks for <mach-o/arch.h>, which is used for the type NXArchInfo, which... I guess I don't actually currently use, so I can remove it... let me do that and then reopen...

...oh right, NXArchInfo is the return type of NXGetArchInfoFromName, which is currently only referenced from the annotated disassembly of the system lsbom... I do hope to use it here eventually, but in the meantime I guess it's ok if I just drop the dependency on libmacho-headers...

[cooljeanius]

OK, uh... where is the "reopen" button?

[cooljeanius]

OK, uh... where is the "reopen" button?

...actually... I think I screwed something up when attempting to rebase; I'm just going to open a new one...

[cooljeanius]

OK, uh... where is the "reopen" button?

...actually... I think I screwed something up when attempting to rebase; I'm just going to open a new one...

OK, done in #30477