perl: depend on libxcrypt

[danielnachun]

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

[danielnachun]

It also looks like perl needs libnsl on Linux, because that is no longer of glibc. I'll update this to include that.

[carlocab]

There is no linkage with libnsl, so this dependency doesn't seem to do anything. The previous run without this also did not register linkage with any libnsl, as far as I can tell.

If linkage with a system libnsl is not desired, then brew linkage needs to be adjusted to make sure it errors.

[danielnachun]

Oh weird, I guess it depends on the system then. On the OS I was testing this on it tried to find libnsl but I guess it doesn't do so depending on the host.

I think we actually need to adjust brew linkage to reject both libnsl.so.1 and libcrypt.so.1 as those are both still in the allowlist right now.

I guess better question now is, how do we stop perl from trying to link to libnsl if we don't want to add it as a dependency? It may be the case that this only happens when building from source on older systems but I'm not sure.

[danielnachun]

I am okay with dropping libnsl for now so we can merge the libxcrypt dependency as that is more critical. Does that sound okay?

[carlocab]

I guess better question now is, how do we stop perl from trying to link to libnsl if we don't want to add it as a dependency?

It might be a configure argument. If there isn't, I'd leave it alone. It's not really that important to stop opportunistic linkage, especially if it doesn't result in a build failure of some kind.

[danielnachun]

Actually it does result in a build failure which was why I wanted to fix this. Sorry I should have said that earlier!

[danielnachun]

Regrettably the Configure script hardcodes the list of libraries it searches for and there doesn't seem to be a way to change this, so I just removed it from the list with inreplace.

[danielnachun]

Nvm, I dug up some old stuff from Linuxbrew on how to override libswanted. The syntax is a little wacky but it does the job and avoids any use of inreplace.

[danielnachun]

This is the list of failures:

Cellar reference to perl interpreter:

• get-flash-videos
• perl-build

Cellar reference to libperl.so:

• collectd
• freeradius-server
• gnumeric
• grokj2k
• irssi
• pidgin
• postgresql
• postgresql@10
• postgresql@11
• postgresql@12
• postgresql@13
• rxvt-unicode
• uwsgi
• v
• vim
• weechat

Unrelated

• biber - probably failing because the biber version is incompatible with texlive
• dynare - this test is known to be flaky
• texlive - needs to depend on libnsl
• qt - will be fixed by qt: fix hardcoded versioned GCC references on Linux #107400

I will revision bump the formula with cellar references but I'm also going to open a tracking issue for these cases because none of them should require a revision bump when we revision bump Perl. We already do a really good job replacing cellar references but a handful of formulae have managed to evade our automated checks. If it turns out that we can fix some or all of these issues in brew instead of homebrew-core, we should prefer that when possible. But at the moment it's hard to say if these cellar references are getting through because of consistent issues or for reasons that are idiosyncratic to each formula.

[carlocab]

Something I don't understand here:

Why do all these formulae need revision bumps for perl to depend on libxcrypt?

Does the ABI of libperl.so change as a consequence of this?

[carlocab]

Ah, I see. These link with perl through a Cellar path. But that seems to have been fixed by your perl changes.

[BrewTestBot]

@carlocab has triggered a merge.

[carlocab]

This formula is just a script and a manpage, so the rev bump seems like it was a mistake.

[danielnachun]

Ah, I think confusion was that it failed during test because vim was broken. Had I run a test where vim was revision bumped but v was not, it would have succeeded. We'll be able to skip revision bumping this when we upgrade to Perl 5.36.

[carlocab]

Well, that's why we rev bump linkage failures before touching any test failures.

[danielnachun]

Ah, I see. These link with perl through a Cellar path. But that seems to have been fixed by your perl changes.

That's what I'm hoping we achieved here, although the only way to find for sure is to do a test revision bump and make sure nothing breaks. I might try that quickly since it doesn't need a long timeout label, and would tell us if we missed anything here.