Homebrew
Replies: 4 comments 20 replies
-
|
@Homebrew/linux can you help? |
Beta Was this translation helpful? Give feedback.
-
|
If I'm not mistaken, on a system like CentOS, the very first formula that should be getting installed during the initial install is |
Beta Was this translation helpful? Give feedback.
-
|
Yes, that was the most confusing thing to me. From what I've read, homebrew should automatically detect if the user's version of glibc is too old and automatically try to install a new one if it is. However, this was not happening for me. Before fixing it properly, I had try to install brew many times from scratch without success so I had definitely been able to reproduce this on my personal system. However, I'm not sure if this also affects other RHEL 7/CentOS 7 systems. One thing to note, however, is that I am not installing using the default install script but installing in a non-default location. The reason is because the server admins have not done anything to support a default homebrew install (like create the linuxbrew user). |
Beta Was this translation helpful? Give feedback.
-
|
The non-default prefix shouldn't be an issue, because that is what I and many of my coworkers use without issues. Did Homebrew try to install newer versions of |
Beta Was this translation helpful? Give feedback.
-
|
Initially I had manually compiled versions of git and curl compatible with homebrew and then pointed homebrew to them, and then installed them manually with homebrew (after sorting out the glibc debacle). |
Beta Was this translation helpful? Give feedback.
-
|
I'm running into this issue on RHEL 7.4. Since that distro's copies of curl and git are too old, I placed newer versions in the path. The installer doesn't detect that the version of glibc is too old and install a newer version. Nor does it install curl and git, so that subsequent brew calls keep complaining about these.
|
Beta Was this translation helpful? Give feedback.
-
|
I think you need For the two issues that require changes to the formulae, those would be useful to contribute as PRs. CentOS installations, typically on enterprise/HPC systems without root access in a non-default folder, tend to be a lot "dirtier" because a lot of things get built from source and pick up whatever libraries are found on the system. I and other CentOS 7 users have been contributing fixes to make this better but every CentOS system is different so we have to make some changes here or there. Note that I am working on a solution to greatly reduce the number of packages that will have to be built from source: Homebrew/brew#12534. It's not ready to merge yet but it's getting closer. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! Adding The bigger issue here is though that this requires a lot of manual intervention. At this point, I think it is too fragile to rely on. Is it realistic to expect brew to automatically handle these issues in the future (installing library packages for libs that have linkage errors)? I'll see whether I can get access to a linuxbrew account so I can install most packages from bottle. But that will not solve these linkage issues, will it? I realize making brew run reliably on multiple distributions (especially these old ones) is a complex task, so I highly appreciate the effort!
For util-linux, does that mean adding a The cap-ng issue can be easily solved by installing the libcap-ng package, so perhaps it's not necessary to change the formula? |
Beta Was this translation helpful? Give feedback.
-
These problems should go away (at least for popular packages) once we get rid of the needing to build them from source outside of the default directories. That's why I'm working on that PR I mentioned above.
This would be a good PR to contribute if possible.
I'll have to build this from source in a CentOS 7 VM to see what's happening here.
I missed that
Thanks, I'm one of the maintainers who is the most interested in making Linuxbrew work better on older enterprise Linux systems. It's hard but progress has been made! |
Beta Was this translation helpful? Give feedback.
-
|
A small update on this from my end. I have recently discovered spack, which seems to better support my use case (at this point in time at least). While not as straightforward to use as Homebrew, it doesn't require any manual interaction similar to what I described above. The fact that it supports installing specific versions of packages also gives it an edge, which is something I always missed in Homebrew. |
Beta Was this translation helpful? Give feedback.
-
good to know. thanks a lot |
Beta Was this translation helpful? Give feedback.
-
|
gcc is also failing to build:
|
Beta Was this translation helpful? Give feedback.
-
|
For this, just use |
Beta Was this translation helpful? Give feedback.
-
|
On Centos7,
|
Beta Was this translation helpful? Give feedback.
-
By following these two commands, how can I check whether gcc-11 is installed?
from above, I did not see gcc-11. Could you please help? |
Beta Was this translation helpful? Give feedback.
-
The commands you ran have the following effect:
Therefore, if both commands completed without error, |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hey,
When trying to bootstrap Homebrew on Centos 7, I've successfully used my own versions of curl and git (manually built from source) to install gcc@5 (after I've edited its formula to use its bottle), but I can't seem to install glibc. For reference, my brew config is
and the error message I get is
I've done a little investigating myself and it seems that in the version of glibc that Homebrew installs, 2.23, the source that springs this error comes from here:
https://elixir.bootlin.com/glibc/glibc-2.23/source/elf/get-dynamic-info.h#L143
For convenience, this is the encompassing code block:
It appears that the assertion
assert (info[DT_RPATH] == NULL);is only checked if the macroRTLD_BOOTSTRAPis defined. That macro is defined here:https://elixir.bootlin.com/glibc/glibc-2.23/source/elf/rtld.c#L349.
From https://stackoverflow.com/questions/44224327/loading-the-dynamic-linker and https://titanwolf.org/Network/Articles/Article?AID=37989c11-53d7-4ae9-a459-d7ca2567a6da#gsc.tab=0, it appears that this bootstrap code is how ld.so relocates itself into binaries, as it is itself a shared object file. Thus, it appears something has gone wrong with this self-relocation process. But I'm not sure how to proceed. Any thoughts?
EDIT:
After doing some more digging, I think there might be a legitimate issue with how Homebrew patches ELF files/shared object libraries, with respect to installing glibc. Running objdump and searching for RPATH on the version of ld.so that homebrew installs versus the system install, I get
Which seems to indicate to me that homebrew (when compiling from source) is naively patching all ELF/shared object files to set their RPATH to the Homebrew libraries, but because ld.so is self relocating it itself does not need its RPATH set (and specifically guards against this). However, I'm not sure my analysis is entirely correct and there might be some further issues with my system configuration, as I've seen some other users of Centos 7 around here successfully use homebrew on their systems.
EDIT 2:
Digging into the homebrew source a little bit, I found where homebrew does the ELF patching for linux:
https://github.com/Homebrew/brew/blob/master/Library/Homebrew/extend/os/linux/keg_relocate.rb
It appears that there is an attempt to not patch ld.so by homebrew, as can be seen in this code block near the top:
However, this does not appear to be triggering on my system. I'm wondering if this is reproducible on any other Centos 7 systems like mine? Maybe somebody could also check the RPATH of their homebrew ld.so with readelf/objdump.
EDIT 3:
I have tried fixing this myself by using my manually compiled version of patchelf to remove the erroneous rpath from my ld.so, like so
which seems to have successfully removed rpath, but upon running
brew postinstallI get the same error message as above. Maybe the locale binary from homebrew glibc has the old version of ld.so inside of it? I'm very hazy on the details of the compilation of glibc. Hopefully this problem can just be stopped at the source by ensuring ld.so really does not have its rpath patched during homebrew's installation of glibc.EDIT 4:
I have fixed my problem. In EDIT 3, I had failed to notice that the error message when executing
ld.sohad changed toindicating that
ld.soalso had had itsRUNPATHset. Indeed, runningobjdumpagain gives meindicating that homebrew had also set the
RUNPATHofld.soto an empty string. Removing this withpatchelflet me successfully runbrew postinstall. I will leave this up in case anybody finds this interesting or wants to probe further into how this happened.Beta Was this translation helpful? Give feedback.
All reactions