linuxbrew overrides some basic toolchain commands

[mikhailkoliada]

brew gist-logs <formula> link OR brew config AND brew doctor output

HOMEBREW_VERSION: 3.6.1
ORIGIN: https://github.com/Homebrew/brew
HEAD: 6e2b162c4786e075323f038d46bfb566d91889e7
Last commit: 6 days ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 48b2cdd207af1ceac791a7bee77c47bb3425dee5
Core tap last commit: 23 hours ago
Core tap branch: master
HOMEBREW_PREFIX: /home/linuxbrew/.linuxbrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_CLEANUP_PERIODIC_FULL_DAYS: 3650
HOMEBREW_MAKE_JOBS: 1
HOMEBREW_NO_AUTO_UPDATE: set
Homebrew Ruby: 2.6.8 => /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.8_1/bin/ruby
CPU: single-core 64-bit haswell
Clang: N/A
Git: 2.25.1 => /bin/git
Curl: 7.68.0 => /bin/curl
Kernel: Linux 5.15.0-1019-azure x86_64 GNU/Linux
OS: Ubuntu 20.04.5 LTS (focal)
Host glibc: 2.31
/usr/bin/gcc: 9.4.0
/usr/bin/ruby: N/A
glibc: 2.35
gcc@11: 11.3.0
xorg: N/A

doctor:

Your system is ready to brew.

Verification

• I ran brew update and am still able to reproduce my issue.
• I have resolved all warnings from brew doctor and that did not fix my problem.

What were you trying to do (and why)?

calling some basic toolchain and glibc-provided commands with a default homebrew installation (locale, iconv, ar, as, ldd, etc)

What happened (include all command output)?

brew-owned commands supplied first as gcc@11 pulls binutils as well and brew installs non-diversified version of toolchain (unlike gcc). As by default the installation script adds brew first in $PATH, its commands has higher priority for any command call, that breaks lots of toolchain stuff due to inconsistency. Moving brew to the end of the $PATH also might cause troubles.

What did you expect to happen?

brew does not conflict with ubuntu-provided packages

Step-by-step reproduction instructions (by running brew commands)

brew install gcc@11

which -a ldd
which -a iconv
which -a locale
...

[SMillerDev]

calling some basic toolchain and glibc-provided commands with a default homebrew installation (locale, iconv, ar, as, ldd, etc)

Please provide these. Your reproduction instructions only prove that brew is in path, which is expected.

[mikhailkoliada]

@SMillerDev tell me what exactly you want me to provide please, as a basic example, as binutils is being installed, ldd ia being installed too, as a result we have:

which ldd 
/home/linuxbrew/.linuxbrew/bin/ldd

then if somebody wants to invoke ldd surely the brew's one gonna be used and give the following result

 ldd /bin/ls
linux-vdso.so.1 (0x00007ffef61bc000)
libselinux.so.1 => not found
libc.so.6 => /home/linuxbrew/.linuxbrew/Cellar/glibc/2.35/lib/libc.so.6 (0x00007f885f7eb000)
/lib64/ld-linux-x86-64.so.2 => /home/linuxbrew/.linuxbrew/Cellar/glibc/2.35/lib64/ld-linux-x86-64.so.2 (0x00007f885fa23000)

So, we can see that ls is linked with brew's libc, while in reality if we call system-provided ldd directly by invoking /usr/bin/ldd /bin/ls

we see that it uses a system-provided libc:

linux-vdso.so.1 (0x00007ffc39786000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f6d778a7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6d776b5000)
libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f6d77625000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6d7761f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6d77900000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6d775fc000)

Given the overall number of important toolchain binaries brew installs

I think it might cause, say, people who compile their binaries with gcc and binutils some kind of headache due to being a bit unpredictable. (Actually it has already caused problems for us in the actions/runner-images repository).

[carlocab]

Related: #109998

We should just make glibc keg-only.

[MikeMcQuaid]

Agreed.

@carlocab I think this also relates to e.g. binutils not being keg-only. I think we should consider making pretty much the entire build toolchain keg-only.

[danielnachun]

I think glibc and binutils are actually the only formulae in the global dependencies on older Linux that actually put binaries in $PATH. The rest are just libraries and gcc@11, whose binaries are versioned and shouldn't conflict with anything.

[MikeMcQuaid]

@danielnachun Thanks for the information ❤️.

Yes, in that case, I think both should be keg-only. Users can manually brew link as desired.

The rest are just libraries and gcc@11, whose binaries are versioned and shouldn't conflict with anything.

Handy 👍🏻

[carlocab]

The rest are just libraries and gcc@11, whose binaries are versioned and shouldn't conflict with anything.

Except for the GCC library symlinks we still create in $HOMEBREW_PREFIX/lib, but I guess those are slightly lower risk.

[carlocab]

#110880

[mikhailkoliada]

@carlocab when can we expect a PR to be merged approximately? Do not think on me being pushy, just our workflows depend on it right now.

[MikeMcQuaid]

@mikhailkoliada Can you clarify whether the issue is purely glibc in the PATH, binutils, gcc@11 or what? You can play around with this by doing brew unlink glibc etc.

[Bo98]

I'm planning to merge Homebrew/brew#13873 and #109998 today (after some testing).

This will allow glibc and binutils to be keg-only, which will I probably do this weekend (along with a 3.6.2 tag) to allow some time for any critical issues to be reported.

brew unlink glibc won't work well now - but it hopefully will after the changes I've linked are merged.

[mikhailkoliada]

@MikeMcQuaid gcc@11 is fine as it is versioned, glibc and bintils are culprits

[carlocab]

Could you elaborate on what the issue with binutils is? Ideally with a small example that reproduces the problem.

[Bo98]

I've released Homebrew 3.6.2 and related formula updates which hopefully address this. Let me know if there's any further issues.