Opened 3 weeks ago
Last modified 3 weeks ago
#71119 assigned defect
ruby33: error: something wrong with LDFLAGS
Reported by: | ttelford (Troy Telford) | Owned by: | kimuraw (kimura wataru) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.10.2 |
Keywords: | sequoia arm64 | Cc: | fhgwright (Fred Wright) |
Port: | ruby33 |
Description (last modified by ttelford (Troy Telford))
On arm64 & Sequoia, I'm seeing ruby33 builds fail:
config.log and main.log attached.
(edit: I had something that turned out to be a red herring for what I thought was wrong - removing noise)
Attachments (2)
Change History (9)
Changed 3 weeks ago by ttelford (Troy Telford)
Attachment: | config.log added |
---|
comment:1 Changed 3 weeks ago by ttelford (Troy Telford)
After reading the log (more) I'm going to revise: "Error not android" isn't the real problem, it's just configure finding what features are available... <sigh>. Time to keep reading.
comment:2 Changed 3 weeks ago by ttelford (Troy Telford)
Description: | modified (diff) |
---|
comment:3 Changed 3 weeks ago by ryandesign (Ryan Carsten Schmidt)
Cc: | fhgwright added |
---|---|
Owner: | set to kimuraw |
Port: | ruby33 added |
Status: | new → assigned |
Summary: | ruby33: on arm64 & Sequoia - fails in configure during `checking whether it is Android` → ruby33: error: something wrong with LDFLAGS |
The main.log says:
:info:configure checking whether LDFLAGS is valid... no :info:configure configure: error: something wrong with LDFLAGS="-L/opt/local/libexec/openssl3/lib -L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk -arch arm64"
Not sure what they mean by "valid" or why they're checking it; this is unusual of this project.
There is no error in the result of that configure check but there is a warning; maybe they consider warnings to make things "invalid". The warning is:
ld: warning: reexported library with install name '/opt/local/lib/libunwind.1.dylib' found at '/opt/local/lib/libunwind.1.dylib' couldn't be matched with any parent library and will be linked directly
This will be because you have the libunwind port installed, which we already know will break a lot of ports. Recommend you uninstall it. See #66250.
comment:4 follow-ups: 6 7 Changed 3 weeks ago by ttelford (Troy Telford)
I can certainly deactivate libunwind; it's not a requested port.
Unfortunately it's a dependency of a number of ports, probably the most notable is watchman.
I'll give it a try and report back.
comment:5 Changed 3 weeks ago by ttelford (Troy Telford)
port -f deactivate libunwind && port install libunwind
allows ruby33 to build successfully.
So it appears that one of those handy port conditionals that fails the build (and then prompts the user to deactivate the port and re-run the port install) would be in order, perhaps?
I seem to recall that clang-19
does just that, for what it's worth.
comment:6 Changed 3 weeks ago by jmroot (Joshua Root)
Replying to ttelford:
Unfortunately it's a dependency of a number of ports, probably the most notable is watchman.
I don't see how those could be correct dependencies. Watchman may well need libunwind, but the libunwind port is an older version that is only intended to be used on pre-libc++ OS versions (so 10.8 at the latest). On anything remotely recent it should be using the system libunwind.
comment:7 Changed 3 weeks ago by ryandesign (Ryan Carsten Schmidt)
Replying to ttelford:
Unfortunately it's a dependency of a number of ports, probably the most notable is watchman.
The watchman port does not depend on the libunwind port, but watchman's dependency edencommon does, and has ever since that port was added, but there wasn't any explanation for why.
Replying to ttelford:
So it appears that one of those handy port conditionals that fails the build (and then prompts the user to deactivate the port and re-run the port install) would be in order, perhaps?
We have resisted doing this because I would guess many, many ports fail to build when the libunwind port is installed, and I do not want to add this build conflict notation to many, many ports. Instead, I want the libunwind port to be changed so that the conflict goes away, hence ticket #66250.
config.log