rust portgroup not stripping dynamic libraries?

[dgilman (David Gilman)]

This is a continuation of 70646. For whatever reason the Rust toolchain is emitting binaries that dynamically link against libiconv but don't actually use any symbols from it.

08:40.david@macmini:~/macports-ports ripgrep @ v2.11.0-archive-8228-g363626662d1$ otool -L /opt/local/bin/rg
/opt/local/bin/rg:
	/opt/local/lib/libiconv.2.dylib (compatibility version 9.0.0, current version 9.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1356.0.0)

This is not a problem for the ripgrep that's distributed by upstream which points to issues with the MacPorts-built rust toolchain. ripgrep and gitu had the situation worked around by manually adding iconv as port dependencies, however, the underlying cause still remains. Maybe -dead_strip_dylibs is not getting passed to the linker? There seems to be support for this flag in rustc.

[dgilmanAIDENTIFIED (David Gilman)]

In bdc26f7f9b6fa502de4cb777bd865f786ed4607f/macports-ports (master):

ripgrep: make pcre variant default

Also add (unused) dependency on iconv.
See #73654 for tracking the
underlying rustc issue.

Closes: #70646

[ryandesign (Ryan Carsten Schmidt)]

Replying to dgilman:

This is not a problem for the ripgrep that's distributed by upstream

Yes, it is:

% otool -L ripgrep-15.1.0-x86_64-apple-darwin/rg
ripgrep-15.1.0-x86_64-apple-darwin/rg:
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)

which points to issues with the MacPorts-built rust toolchain

I find no occurrences of "iconv" in the rust or rust_build portgroups.

Looking at a build log for ripgrep on a buildbot machine, the only occurrences of "iconv" are the dependency. No -lconv anywhere, as one would see when linking a C program, so rust must not print any information when it links with libraries, which seems like a bad design that hinders debugging.

I found this upstream rust libc bug from August 2022: ​libiconv is still unconditionally linked to all binaries on macOS. It was allegedly ​fixed in October 2022.

There was a subsequent commit in January 2024: ​Remove inconv (sic) linking on apple with no reference to a bug report.

Are we sure those changes are included in MacPorts, either in the rust port or in individual ports that use rust (I'm not sure which is required)? For example, the ripgrep Portfile references libc 0.2.177 which was released October 2025 so I'd think it would include those changes.

In February 2025 the libiconv dependency was added to our gitu Portfile which at that time referenced libc 0.2.168 which was released December 2024, again after the above changes.

I don't know if there are places that rust might link things with libiconv outside of its libc.

[ryandesign (Ryan Carsten Schmidt)]

The rust Portfile references many different versions of rust libc, some of which predate the 2024 fix:

% grep ' libc ' $(port file rust)
        libc                           0.2.150  89d92a4743f9a61002fae18374ed11e7973f530cb3a3255fb354818118b2203c \
        libc                           0.2.151  302d7ab3130588088d277783b1e2d2e10c9e9e4a16dd9050e6ec93fb3e7048f4 \
        libc                           0.2.153  9c198f91728a82281a64e1f4f9eeb25d82cb32a5de251c6bd1b5154d63a8e7bd \
        libc                           0.2.141  3304a64d199bb964be99741b7a14d26972741915b3649639149b2479bb46f4b5 \
        libc                           0.2.147  b4668fb0ea861c1df094127ac5f1da3409a82116a4ba74fca2e58ef927159bb3 \
        libc                           0.2.155  97b3888a4aecf77e811145cadf6eef5901f4782c53886191b2f693f24761847c \
        libc                           0.2.168  5aaeb2981e0606ca11d79718f8bb01164f1d6ed75080182d3abf017e6d244b6d \
        libc                           0.2.171  c19937216e9d3aa9956d9bb8dfc0b0c8beb6058fc4f7a4dc4d850edf86a237d6 \
        libc                           0.2.174  1171693293099992e19cddea4e8b849964e9846f4acee11b3948bcc337be8776 \
        libc                           0.2.175  6a82ae493e598baaea5209805c49bbf2ea7de956d50d7da0da1164f9c6d28543 \
        libc                           0.2.177  2874a2af47a2325c2001a6e6fad9b16a53b802102b528163885171cf92b15976 \
        libc                           0.2.178  37c93d8daa9d8a012fd8ab92f088405fb202ea0b6ab73ee2482ae66af4f42091 \

Dunno why rust would need that many different versions of libc or which one it uses when.

[dgilman (David Gilman)]

I did the analysis on upstream built rg on Friday and wrote this ticket Monday so I think I lost some of my own context. Agreed they are both dynamically linking against iconv, but also want to point out that nm -a doesn't have any iconv symbols. There's also no dlopen in there (but there is dlsym which also seems bogus).

Maybe this can just be closed wontfix in light of ​https://github.com/rust-lang/libc/issues/3248 which is tracking the unnecessary linking against iconv. Alternatively, is it worth just using the portgroup to add a dependency on iconv for everything built with rust? The linker will still panic on you if you find a way to run ripgrep on a system without MacPorts iconv.

[ryandesign (Ryan Carsten Schmidt)]

I think it's fine to have a MacPorts ticket tracking the unnecessary libiconv linkage. Maybe we should retitle it.

That upstream issue seems to be an overview of all the things they want to do for libc 1.0. I'm surprised there isn't a separate issue specifically about the libiconv overlinkage.

Sure, it is possible to program the portgroup to add the libiconv dependency.

Or, in ​a linked issue, I saw the suggestion to write a wrapper script to use as a compiler that simply deletes the -liconv flag but passes all other arguments along. The portgroup could automate something like that. But the given wrapper uses zig, which we don't, so I'm not sure if this workaround is usable for us. It also presumes that there is no software built with rust that needs libiconv. It seems like it would be simpler to find wherever in rust it's linking with libiconv and patch it not to do that.

If we fix our rust not to link with libiconv, or if upstream releases a rust that no longer does this, I think we may want to individually revbump each port built with rust so it picks up this change. That would be a lot of work so if we're patching rust to do this, before we do it we probably want confirmation that this is the right thing to do.

It sure would be great to see some upstream comment on this situation.