Linuxbrew-core: CentOS6 install of gcc --without-glibc fails with crti.o not found

[jhdub23]

I'm trying to install linuxbrew on CentOS6 without sudo, following the instructions on the wiki.. However, it's failing on brew install gcc --without-glibc:

ld: crti.o: No such file: No such file or directory
collect2: error: ld returned 1 exit status

Commands:

git clone https://github.com/Linuxbrew/brew.git .linuxbrew_rhel6
export HOMEBREW_NO_ANALYTICS=1
export HOMEBREW_NO_AUTO_UPDATE=1
export HOMEBREW_BUILD_FROM_SOURCE=1
export PATH=.:/data3/jhwest/work/tmp/.linuxbrew_rhel6/bin:/bin:/usr/bin
brew tap linuxbrew/xorg
brew install gcc --without-glibc

Logs are at gist-logs

Can anyone suggest a quick fix/workaround?

Checklist is as follows:

• [x] Confirmed this is a problem with brew installing one, specific formula and not every time you run brew? If it's a general brew problem please file this issue at https://github.com/Linuxbrew/brew/issues/new.
• [x] If you have a macOS system and can replicate the problem on macOS with Homebrew, please report the issue to Homebrew/core and follow their issue template from your macOS system. If you are unsure, please report the issue to Linuxbrew.
• [x] ran brew update and can still reproduce the problem?
• [x] ran brew doctor, fixed all issues and can still reproduce the problem?
• [x] Ran brew gist-logs <formula> (where <formula> is the name of the formula that failed) and included the output link?
• [ ] If brew gist-logs didn't work: ran brew config and brew doctor and included their output with your issue?

[fengwang]

same problem here when installing gcc.

[yinchunxiang]

same problem

[achen26]

also running into this problem when trying to install filebeat without sudo access

[robxu9]

For me, I found out that it was trying to look for crti.o and crtn.o in /usr/lib instead of /usr/lib64, which is where CentOS puts them.

Running brew edit gcc and sticking ENV["LIBRARY_PATH"] = "/usr/lib64" in an else statement to if build.with? "glibc" solved that issue. I had to brew edit glibc and define LIBRARY_PATH there to get it to build afterwards as well.

[jhdub23]

Thank you robxu9. That worked.

[iMichka]

@xu-cheng @sjackman I think there is room for some improvement for gcc. Our users have found a workaround, I think we should try to implement this properly in brew.

[sjackman]

Yes, agreed. Instructions to reproduce the issue in a centos:6 Docker image and a PR to resolve the issue would be very welcome.

[sjackman]

@robxu9 Thanks for finding the fix, Robert! Would you like to submit a PR?

[tueda]

The LIBRARY_PATH fix works also on Scientific Linux CERN 6.9, where I got an almost same error /usr/lib/crti.o: could not read symbols: File in wrong format.

[iMichka]

@robxu9 something like this: https://github.com/Linuxbrew/homebrew-core/pull/7632 ?

[iMichka]

This should be now fixed with #7632, please update and test.

[tueda]

7632 doesn't help for me because it finds /usr/lib/crti.o instead of the correct one at /usr/lib64/crti.o. Could it be OK to give a priority to /usr/lib64 than /usr/lib for others?

[iMichka]

I don't mind putting the /usr/lib64 folder first.

So you have two crti.o files in two different lib folders? And they are not the same? Which packages did install these files?

[tueda]

What I see is

$ file /usr/lib/crti.o
/usr/lib/crti.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
$ file /usr/lib64/crti.o
/usr/lib64/crti.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

I'm not sure how these files were installed because I have no root privilege on this machine. I'm also not sure if it is a common practice to have 32 bit files in /usr/lib and 64 bit files in /usr/lib64. Maybe it's specific to the machine or administrator's customization.

[iMichka]

Looks funny. Not sure it is common, I am new to all this multi arch stuff on centos ... I would have expected the 32 bit one to be in /usr/lib32/.

• Is /usr/lib a symlink to something (/usr/lib32/ or /usr/lib64/?).
• Are you on a 32 bit OS?

I need to rewrite he code for the include path to check the arch, and then setup the paths in the right order.

[iMichka]

I changed the order here: https://github.com/Linuxbrew/homebrew-core/pull/7635

Can you confirm that this change helps for that error?

[tueda]

Sorry if confusing: I'm not on CentOS but on Scientific Linux (but it should be almost the same, I guess).

$ cat /etc/redhat-release
Scientific Linux CERN SLC release 6.9 (Carbon)
$ uname -a
Linux ws01 2.6.32-696.10.2.el6.x86_64 #1 SMP Thu Sep 14 16:35:02 CEST 2017 x86_64 x86_64 x86_64 GNU/Linux

/usr/lib/ is not a symlink and I have no /usr/lib32/.

I will try your change of #7635. Thanks.

[tueda]

Indeed the cookbook in #7635 worked to me.

Clean install without root on my environment (SLC 6.9): the following works:

sh -c "$(curl -fsSL https://raw.githubusercontent.com/Linuxbrew/install/master/install.sh)"
PATH=$HOME/.linuxbrew/bin:$HOME/.linuxbrew/sbin:$PATH
HOMEBREW_NO_AUTO_UPDATE=1 HOMEBREW_BUILD_FROM_SOURCE=1 brew install https://raw.githubusercontent.com/iMichka/homebrew-core-1/47538613258561a89d9b4403f30621d439bb841c/Formula/gcc.rb --without-glibc  # 7635

[iMichka]

Ok, thanks. I merged #7635, and updated all the other gcc formulae using the same code in (#7640).

This fixes building gcc from source with brew install gcc --without-glibc on centos and scientific linux.

I am closing this issue, as the initial error is fixed.

If there are other problems with other formulae, please open a new issue.

[sjackman]

I've never seen /usr/lib32 on a wild system. On CentOS the two folders are named…
/usr/lib for 32-bit libraries
/usr/lib64 for 64-bit libraries

On Debian and Ubuntu, the two folders are named…
/usr/lib for 32-bit libraries
/usr/lib/x86_64-linux-gnu for 64-bit libraries

On a theoretical 64-bit non multiarch system, the 64-bit libraries should be named /usr/lib and there would be no 32-bit library folder, but I don't know of a common example.

[glensc]

/lib32 is afaik used on ubuntu, and /libx32 is used for X32_ABI ;)

[sjackman]

A default installation of Ubuntu does not have a /lib32 directory. /libx32 is frightening! 😱