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)

config.log (47.4 KB) - added by ttelford (Troy Telford) 3 weeks ago.
config.log
main.log (31.9 KB) - added by ttelford (Troy Telford) 3 weeks ago.
main.log

Download all attachments as: .zip

Change History (9)

Changed 3 weeks ago by ttelford (Troy Telford)

Attachment: config.log added

config.log

Changed 3 weeks ago by ttelford (Troy Telford)

Attachment: main.log added

main.log

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: newassigned
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 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 in reply to:  4 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 in reply to:  4 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.

Note: See TracTickets for help on using tickets.