weechat @3.5_0+ruby: error: invalid arch name '-arch -lx86_64'

[hexadecagram ({16/7})]

% port installed ruby\*
The following ports are currently installed:
  ruby30 @3.0.4_0 (active)
  ruby_select @1.3_0 (active)
% sudo port clean weechat; sudo port install weechat +aspell+lua+perl+python+ruby+scheme+tcl
--->  Cleaning weechat
--->  Computing dependencies for weechat
The following dependencies will be installed:
 openssl10
 ruby
Continue? [Y/n]: n
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  No broken ports found.
% sudo port clean weechat; sudo port install weechat +ruby
--->  Cleaning weechat
--->  Computing dependencies for weechat
The following dependencies will be installed:
 openssl10
 ruby
Continue? [Y/n]: n
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  No broken ports found.

It would seem that a previous attempt at fixing this has already been attempted upstream and at one point was successful: ​https://github.com/weechat/weechat/issues/714

[jmroot (Joshua Root)]

The commands you've shown appear to be working as expected. The ruby variant in weechat adds a dependency on ruby, not ruby30. Are you asking for it to be updated to use a newer ruby version?

[hexadecagram ({16/7})]

As demonstrated in my initial submission, I have ruby30 installed. If I continue on with the build, the package ruby wants to build 1.8.7 from source, which it succeeds in doing, however, the weechat build later fails:

% sudo port clean weechat; sudo port install weechat +aspell+lua+perl+python+ruby+scheme+tcl
--->  Cleaning weechat
--->  Computing dependencies for weechat
The following dependencies will be installed:
 openssl10
 ruby
Continue? [Y/n]:
--->  Fetching archive for openssl10
...
--->  Activating openssl10 @1.0.2u_4
--->  Cleaning openssl10
--->  Fetching archive for ruby
...
--->  Activating ruby @1.8.7-p374_15
--->  Cleaning ruby
--->  Fetching archive for weechat
--->  Attempting to fetch weechat-3.5_0+aspell+lua+perl+python+python310+ruby+scheme+tcl.darwin_21.x86_64.tbz2 from https://packages.macports.org/weechat
--->  Attempting to fetch weechat-3.5_0+aspell+lua+perl+python+python310+ruby+scheme+tcl.darwin_21.x86_64.tbz2 from https://ywg.ca.packages.macports.org/mirror/macports/packages/weechat
--->  Attempting to fetch weechat-3.5_0+aspell+lua+perl+python+python310+ruby+scheme+tcl.darwin_21.x86_64.tbz2 from https://kmq.jp.packages.macports.org/weechat
--->  Fetching distfiles for weechat
--->  Verifying checksums for weechat
--->  Extracting weechat
--->  Configuring weechat
--->  Building weechat
Error: Failed to build weechat: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_irc_weechat/weechat/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port weechat failed
--->  Some of the ports you installed have notes:
  ruby has the following notes:
    This port is deprecated since the project is no longer maintained upstream. It is likely to be removed from
    MacPorts at some point in the future. If you find this port useful and would like to see it continue, please
    consider posting to the macports-users mailing list. See https://trac.macports.org/wiki/MailingLists for more
    details.

    To make this the default Ruby (i.e., the version run by the 'ruby' commands), run:
        sudo port select --set ruby ruby18

I will attach main.log if it's any consequence but the primary issue here is that support for ruby 1.8.7 has long since ended: ​https://www.ruby-lang.org/en/news/2011/10/06/plans-for-1-8-7/

Therefore, this actually seems to be a problem with the ruby package but I figured the first step would be to make the maintainer for weechat (@cardi) aware, on account of the upstream issue I linked.

[ryandesign (Ryan Carsten Schmidt)]

The log shows the error is:

:info:build /usr/bin/clang -pipe -Os -DNDEBUG -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -fsigned-char -fms-extensions -Wall -Wextra -Werror-implicit-function-declaration -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -mmacosx-version-min=12.0 -bundle -Wl,-headerpad_max_install_names -L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -o ruby.so CMakeFiles/ruby.dir/weechat-ruby.c.o CMakeFiles/ruby.dir/weechat-ruby-api.c.o  -L/opt/local/libexec/openssl11/lib -L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -arch -lx86_64 -Wl,-undefined,dynamic_lookup -Wl,-multiply_defined,suppress -lruby.3.0 -L/usr/local/opt/ruby/lib ../libweechat_plugins_scripts.a 
:info:build clang: error: invalid arch name '-arch -lx86_64'

Indeed, -lx86_64 is not a valid architecture. It should say x86_64 not -lx86_64. I wonder how that is getting in there.

The mention of -L/usr/local/opt/ruby/lib is also distressing, since we would not want anything you may have installed in /usr/local to be found. If you do have anything in /usr/local, it could be interfering with this build. I also see -lruby.3.0 in the log, suggesting it has found ruby 3.0 somewhere and is trying to use it, which is wrong since that's not the ruby it declares a dependency on.

If the maintainer wishes to change weechat to depend on a newer ruby that's of course fine, but is orthogonal to the other issues which still need to be addressed.

There is no "problem with the ruby package": the ruby port provides ruby version 1.8.x. Other ports provide other versions of ruby. If that's not how you expected or want it to work, you could file another ticket for the ruby port.

[cardi (calvin ardi)]

Apologies in advance for my lack of Ruby knowledge: I don't use the Ruby plugin in WeeChat, but I will help to try to resolve this.

It looks like WeeChat does automatic detection of the Ruby version ​(1) but, AFAIK, the Portfile won't allow us to specify "any installed version of Ruby is fine" as a dependency.

To partially resolve this, I think the following needs to be added to the Portfile:

• add variants for each Ruby version (like ​`python`, `python37`, `python38`, ...)
• force WeeChat to detect and use the Ruby version the user selects by patching FindRuby.cmake ​(2) in a similar way to ​Python

Re: the other issues (-lx86_64 and -L/usr/local/opt/ruby/lib), I'll have to debug the build to see if I have these issues on my side as well.

[cardi (calvin ardi)]

Replying to cardi:

Re: the other issues (-lx86_64 and -L/usr/local/opt/ruby/lib), I'll have to debug the build to see if I have these issues on my side as well.

I've been working on a patch to FindRuby.cmake to remove the hard-coded paths, and I'm now running into the same issue of "invalid arch name", except on an arm64 platform.

This particular command fails when specifying the +ruby variant (added linebreaks to make it easier to read):

/usr/bin/clang -pipe -Os -DNDEBUG -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk 
-fsigned-char -fms-extensions -Wall -Wextra -Werror-implicit-function-declaration -arch arm64 
-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -mmacosx-version-min=12.0 -bundle 
-Wl,-headerpad_max_install_names -L/opt/local/lib -Wl,-headerpad_max_install_names 
-Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -o ruby.so 
"CMakeFiles/ruby.dir/weechat-ruby.c.o" "CMakeFiles/ruby.dir/weechat-ruby-api.c.o"  
-L/opt/local/libexec/openssl11/lib -L/opt/local/lib -Wl,-headerpad_max_install_names 
-Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -arch -larm64 
-Wl,-undefined,dynamic_lookup -Wl,-multiply_defined,suppress -lruby.3.0 
../libweechat_plugins_scripts.a

What's interesting is that the architecture is correctly specified on the second line -arch arm64 but somehow mangled in a repeated invocation on the third line from the bottom -arch -larm64.

Poking around in the build directory, the command being executed above is in the file src/plugins/ruby/CMakeFiles/ruby.dir/link.txt.

I'm not familiar enough with CMake to understand what's creating that file, and it isn't obvious to me how all those options are strung together (e.g., why are various parameters, like -L/opt/local/lib or -Wl,-headerpad_max_install_names repeated multiple times?).

Any help in pinpointing where this -arch -l{arm64,x86_64} is added would be appreciated–I can follow up with adding updated ruby variants after.

[cardi (calvin ardi)]

I poked around some more to understand why the architecture is being prefixed with -l, e.g., -arch -l{arm64,x86_64}, and I think I've figured it out.

The RUBY_LDFLAGS is copied from /opt/local/lib/pkgconfig/ruby-3.0.pc:

DLDFLAGS=-L/opt/local/libexec/openssl11/lib -L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -arch arm64 -Wl,-multiply_defined,suppress -Wl,-undefined,dynamic_lookup -L/opt/local/lib

When CMake finds Ruby (using ​FindPkgConfig.cmake), it copies the value of DLDFLAGS and replaces all spaces ( ) with semicolons (;). This leads to the following RUBY_LDFLAGS:

:info:configure -- Checking for one of the modules 'ruby-3.0'
:info:configure -- CMAKE_SYSTEM_NAME="Darwin"
:info:configure -- RUBY_LDFLAGS="-L/opt/local/libexec/openssl11/lib;-L/opt/local/lib;-Wl,-headerpad_max_install_names;-Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk;-arch;arm64;-Wl,-multiply_defined,suppress;-Wl,-undefined,dynamic_lookup;-lruby.3.0"

Note in particular: -arch;arm64;.

When the semicolons are converted back into spaces, arm64 gets prefixed with -l: I'm not quite sure where this happens.

Nonetheless, I think I'll have a patch that will remove -arch;arm64; since the architecture is already specified earlier in the command.

Moving forward, either upstream will need to handle the space in -arch arm64 or the MacPorts build of Ruby (or upstream Ruby?) needs to remove the space between the -arch flag and its value when writing the pkgconfig: I'm not sure what the "right" way should be.

[kencu (Ken)]

Good sleuthing.

Usually the arch setting would be in the CXX or C flags, and added to the link that way.

the link line is supposed to be something like:

(COMPILER) (C_or_CXXFLAGS) (LDFLAGS) source_file

So perhaps the 'fix' is to get the archs out of the LDFLAGS completely, as you said. Looks like a MacPorts thing, not an upstream thing.

[cardi (calvin ardi)]

In 32506e83d07b9ab62de124b57496c95cdb7587fa/macports-ports (master):

weechat: update to 3.8, fix ruby variant build, update {python,ruby} variants (​https://github.com/macports/macports-ports/pull/17422)

• adds variants for ruby 3.0 (+ruby30), 3.1 (+ruby31), and 3.2 (+ruby32) and updates +ruby variant to use ruby 3.2 (+ruby32)

• adds +python311 variant for python 3.11, and updates +python variant to use python 3.11 (+python311)

• adds a patchfile to fix a build error (`error: invalid arch name '-arch -lx86_64'`) when installing the ruby variant

the patch to one of the CMake files removes the hardcoded paths that
ruby is assumed to be installed to, and removes the -arch ${os.arch}
in RUBY_LDFLAGS provided by pkg-config as the space in between -arch
and ${os.arch} led to string substitution errors during the build
process

see the corresponding trac ticket for details

Closes: #65100