Skip to content
This repository has been archived by the owner on Nov 27, 2017. It is now read-only.

Standalone installation of Linuxbrew #107

Closed
mbsullivan opened this issue Jul 31, 2014 · 143 comments
Closed

Standalone installation of Linuxbrew #107

mbsullivan opened this issue Jul 31, 2014 · 143 comments
Assignees

Comments

@mbsullivan
Copy link
Contributor

I just tested the installation of glibc under the bottle branch; it went pretty well, but there may be a couple missing dependencies. (I am installing it on a machine running CentOS 5.5, which is quite outdated.)

I haven't yet looked into how dependencies/version requirements are dictated in Homebrew/Linuxbrew, so I'll just describe the procedure I went through to get it installed. Here's what happened:

(1) prepared the bottle branch and installed patchelf using Linuxbrew's local gcc:

>cd $LINUXBREW; git checkout bottle
>brew install patchelf -v --cc=gcc-4.8

(2) tried glibc brew install glibc -v --cc=glibc, it fails with:

*** These critical programs are missing or too old: as ld

It seems to me like this means that a new version of binutils is a dependency.

(3) installed binutils brew install binutils -v --cc=gcc-4.8.

(4) The binutils recipe uses a program prefix 'g' (leading to gld and gas), which is non-standard for Linux distros I've used. This led to some errors, so I had to manually symlink $LINUXBREW/bin/ld and $LINUXBREW/bin/gas to the generated programs. Would this be considered a bug in linuxbrew's binutils?

(5) With the new binutils, an installation of glibc now runs into old kernel header files:

checking installed Linux kernel header files... TOO OLD!

It seems like this means that a new version of linux-headers is a dependency.

(4) Installed linux-headers with brew install linux-headers -v --cc=gcc-4.8. Something weird happened here... It seemed to not respect the --cc= version I gave it, and ended up using an old-and-busted gcc on the system path. (Any idea why this would happen?) I took this version of gcc out of my path and continued.

(5) With new binutils and linux-headers installed, glibc 2.19 installed like a charm.

One more thing: I might add a caveat to the installer to warn the user to unset LD_LIBRARY_PATH immediately if they've left it pointing to $LINUXBREW/lib/. Otherwise the new glibc will minorly hose your system if it expects an older one.

@sjackman
Copy link
Member

Short answer: brew install glibc --with-binutils --with-linux-headers

See if that gets you further. I'll try a more complete response later.

@mbsullivan
Copy link
Contributor Author

Hmm, okay great! That sounds promising. I'll remove glibc and all the dependencies and will see how it goes tomorrow.

@mbsullivan
Copy link
Contributor Author

I tried brew install glibc --with-binutils --with-linux-headers out today, and it works great! The only hiccup was with binutils, as above:

*** These critical programs are missing or too old: as ld

This leads me to two questions:
(1) Why are binutils and linux-headers marked as optional? Because you're assuming that they're probably somewhere on the system-wide paths?

(2) Under Linux, would it be appropriate to eliminate "--program-prefix=g" from the binutils formula?

@mbsullivan
Copy link
Contributor Author

Hmmm, while the installation of glibc went swimmingly, it seems to have broken any further builds. It always complains with errors like the following:

checking whether the C compiler works... no
...
configure: error: C compiler cannot create executables

I tried uninstalling and reinstalling my linuxbrew version of gcc, but with glibc 2.19 installed it gets equally angry with my (old) system version of gcc such that I cannot get the linuxbrew formula for gcc to build.

checking ABI=64
checking compiler /usr/bin/gcc -Os -w -pipe -march=core2 -isystem/work/3931105305/.linuxbrew_bottle/include... no
checking ABI=x32
checking compiler /usr/bin/gcc -Os -w -pipe -march=core2 -isystem/work/3931105305/.linuxbrew_bottle/include... no
checking ABI=32
checking compiler /usr/bin/gcc -Os -w -pipe -march=core2 -isystem/work/3931105305/.linuxbrew_bottle/include... no
configure: error: could not find a working compiler, see config.log for details

@sjackman
Copy link
Member

You'll have to clear your LD_LIBRARY_PATH:
unset LD_LIBRARY_PATH
Or alternatively,
brew unlink glibc

@mbsullivan
Copy link
Contributor Author

You'll have to clear your LD_LIBRARY_PATH:

That's not the issue -- it's already done. (If I hadn't cleared my LD_LIBRARY_PATH then no system coreutils would work, since the system is using an older glibc version.)

Or alternatively, brew unlink glibc

Wait, I'm confused... I thought that the whole point of the RPATH patch was to force brewed programs to use the proper libraries, even when they differ from binary to binary. So after I install glibc 2.19, why don't existing programs use the (old) system glibc with which they were brewed, and newly brewed programs use 2.19?

If I have to unlink glibc in order to keep things working, then what's the point of installing it in the first place?

@sjackman
Copy link
Member

sjackman commented Aug 2, 2014

Programs patched with patchelf when they were installed will continue to use the new glibc whether it's linked or not. I'm on vacation for my sister's wedding. I'll be back in a week to help troubleshoot.

@mbsullivan
Copy link
Contributor Author

Programs patched with patchelf when they were installed will continue to use the new glibc whether it's linked or not.

I tried to test whether this was the case but ldd says that my new programs are using a motley assortment of libraries, including the system glibc.

Following this procedure on the bottle branch:

(1) install patchelf,  gcc, binutils, linux-headers
(2) create symlinks to the brewed gas and gld binaries
(3) install glibc
(4) unlink glibc
(5) install luajit

Then ldd luajit gives:

>ldd ./luajit 
    libm.so.6 => /lib64/libm.so.6 (0x000000351fc00000)
    libdl.so.2 => /lib64/libdl.so.2 (0x000000351f800000)
    libgcc_s.so.1 => /opt/apps/gcc/4.7.1/lib64/libgcc_s.so.1 (0x00002b4dae62e000)
    libc.so.6 => /lib64/libc.so.6 (0x000000351f400000)
    /work/01166/mbsulliv/.linuxbrew_bottle/opt/glibc/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x000000351f000000)

Does ldd not respect the patchelf patch? Or am I misunderstanding something?

PS, I am using the old system ldd above. The ldd that is installed along with glibc 2.19 (located at .linuxbrew_bottle/opt/glibc/bin/ldd) does not recognize any programs as being dynamic executables, including luajit.

I'm on vacation for my sister's wedding. I'll be back in a week to help troubleshoot.

Haha, no rush and thank you for your help so far! I've actually gotten things to a good state using gcc-4.8/vim/libraries from the master branch of linuxbrew, so your work has already helped me. I'm testing the bottle branch and glibc because I'm interested in their possibilities, but it's not a time-critical matter at all.

@sjackman sjackman self-assigned this Aug 12, 2014
@sjackman
Copy link
Member

The ldd that is installed along with glibc 2.19 (located at .linuxbrew_bottle/opt/glibc/bin/ldd) does not recognize any programs as being dynamic executables, including luajit.

I have the same issue. I don't know why the newly installed ldd doesn't work. Try using LD_TRACE_LOADED_OBJECTS instead:

$ LD_TRACE_LOADED_OBJECTS=1 hello
    linux-vdso.so.1 (0x00007ffff11fd000)
    libc.so.6 => /projects/btl/linuxbrew/Cellar/glibc/2.19/lib/libc.so.6 (0x00002b2d1f2a6000)
    /projects/btl/linuxbrew/opt/glibc/lib/ld-linux-x86-64.so.2 (0x00002b2d1f087000)

I've created a new wiki page with instructions for a Standalone Installation of Linuxbrew.

@sjackman
Copy link
Member

I've merged the branch bottle into master.

@jrevillard
Copy link

Hi,
I just tried the new wiki page instructions and I get this error when I install hello:

==> ./configure --disable-debug --disable-dependency-tracking --disable-silent-rules --prefix=/home/jerome/linuxbrew/Cellar/hello/2.9
configure: WARNING: unrecognized options: --disable-debug
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... /home/jerome/linuxbrew/bin/gcc-4.9
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... configure: error: in `/tmp/hello-y31448/hello-2.9':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
==> Configuration
HOMEBREW_VERSION: 0.9.5
HEAD: d30e6f289fea2c50c933b2d1ac3b67e5e87f3cfc
HOMEBREW_PREFIX: /home/jerome/linuxbrew
CPU: 8-core 64-bit 6
OS X: 0-x86_64
X11: N/A
==> ENV
CC: /home/jerome/linuxbrew/bin/gcc-4.9 => /home/jerome/linuxbrew/Cellar/gcc/4.9.1/bin/gcc-4.9
CXX: /home/jerome/linuxbrew/bin/g++-4.9 => /home/jerome/linuxbrew/Cellar/gcc/4.9.1/bin/g++-4.9
OBJC: /home/jerome/linuxbrew/bin/gcc-4.9
OBJCXX: /home/jerome/linuxbrew/bin/g++-4.9
HOMEBREW_CC: gcc-4.9
CFLAGS: -Os -w -pipe -march=core2
CXXFLAGS: -Os -w -pipe -march=core2
CPPFLAGS: -isystem/home/jerome/linuxbrew/include
LDFLAGS: -L/home/jerome/linuxbrew/lib -Wl,-rpath,/home/jerome/linuxbrew/lib -Wl,--dynamic-linker=/home/jerome/linuxbrew/opt/glibc/lib/ld-linux-x86-64.so.2
MAKEFLAGS: -j8
CMAKE_PREFIX_PATH: /home/jerome/linuxbrew
PKG_CONFIG_LIBDIR: /home/jerome/linuxbrew/lib/pkgconfig:/usr/lib/pkgconfig
ACLOCAL_PATH: /home/jerome/linuxbrew/share/aclocal
PATH: /home/jerome/linuxbrew/bin:/home/jerome/rpms/bin:/home/jerome/rpms/usr/bin:/usr/bin:/bin:/home/jerome/linuxbrew/Library/Contributions/cmd

Error: hello 2.9 did not build
Logs:
     /home/jerome/Library/Logs/Homebrew/hello/01.configure
     /home/jerome/Library/Logs/Homebrew/hello/config.log

Any advice please ?

Best,
Jerome

@jrevillard
Copy link

By the way, here is what I found in the config.log

configure:3836: $? = 0
configure:3825: /home/jerome/linuxbrew/bin/gcc-4.9 -v >&5
Using built-in specs.
COLLECT_GCC=/home/jerome/linuxbrew/bin/gcc-4.9
COLLECT_LTO_WRAPPER=/home/jerome/linuxbrew/Cellar/gcc/4.9.1/libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/home/jerome/linuxbrew/Cellar/gcc/4.9.1 --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-4.9 --with-gmp=/home/jerome/linuxbrew/opt/gmp --with-mpfr=/home/jerome/linuxbrew/opt/mpfr --with-mpc=/home/jerome/linuxbrew/opt/libmpc --with-cloog=/home/jerome/linuxbrew/opt/cloog --with-isl=/home/jerome/linuxbrew/opt/isl --with-system-zlib --enable-libstdcxx-time=yes --enable-stage1-checking --enable-checking=release --enable-lto --disable-werror --with-pkgversion='Homebrew gcc 4.9.1 --without-multilib' --with-bugurl=https://github.com/Homebrew/homebrew/issues --enable-plugin --disable-nls --disable-multilib
Thread model: posix
gcc version 4.9.1 (Homebrew gcc 4.9.1 --without-multilib) 
configure:3836: $? = 0
configure:3825: /home/jerome/linuxbrew/bin/gcc-4.9 -V >&5
gcc-4.9: error: unrecognized command line option '-V'
gcc-4.9: fatal error: no input files
compilation terminated.
configure:3836: $? = 1
configure:3825: /home/jerome/linuxbrew/bin/gcc-4.9 -qversion >&5
gcc-4.9: error: unrecognized command line option '-qversion'
gcc-4.9: fatal error: no input files
compilation terminated.
configure:3836: $? = 1
configure:3856: checking whether the C compiler works
configure:3878: /home/jerome/linuxbrew/bin/gcc-4.9 -Os -w -pipe -march=core2 -isystem/home/jerome/linuxbrew/include -L/home/jerome/linuxbrew/lib -Wl,-rpath,/home/jerome/linuxbrew/lib -Wl,--dynamic-linker=/home/jerome/linuxbrew/opt/glibc/lib/ld-linux-x86-64.so.2 conftest.c  >&5
configure:3882: $? = 0
configure:3930: result: yes
configure:3933: checking for C compiler default output file name
configure:3935: result: a.out
configure:3941: checking for suffix of executables
configure:3948: /home/jerome/linuxbrew/bin/gcc-4.9 -o conftest -Os -w -pipe -march=core2 -isystem/home/jerome/linuxbrew/include -L/home/jerome/linuxbrew/lib -Wl,-rpath,/home/jerome/linuxbrew/lib -Wl,--dynamic-linker=/home/jerome/linuxbrew/opt/glibc/lib/ld-linux-x86-64.so.2 conftest.c  >&5
configure:3952: $? = 0
configure:3974: result: 
configure:3996: checking whether we are cross compiling
configure:4004: /home/jerome/linuxbrew/bin/gcc-4.9 -o conftest -Os -w -pipe -march=core2 -isystem/home/jerome/linuxbrew/include -L/home/jerome/linuxbrew/lib -Wl,-rpath,/home/jerome/linuxbrew/lib -Wl,--dynamic-linker=/home/jerome/linuxbrew/opt/glibc/lib/ld-linux-x86-64.so.2 conftest.c  >&5
configure:4008: $? = 0
configure:4015: ./conftest
Inconsistency detected by ld.so: get-dynamic-info.h: 134: elf_get_dynamic_info: Assertion `info[15] == ((void *)0)' failed!
configure:4019: $? = 127
configure:4026: error: in `/tmp/hello-y31448/hello-2.9':
configure:4028: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details

@jrevillard
Copy link

My problem might be related to this: at the end of of the glibc installation, I have plenty of patchelf errors:

...
/home/jerome/linuxbrew/Cellar/patchelf/0.8/bin/patchelf: error while loading shared libraries: /home/jerome/linuxbrew/lib/libc.so.6: ELF file OS ABI invalid
/home/jerome/linuxbrew/Cellar/patchelf/0.8/bin/patchelf: error while loading shared libraries: /home/jerome/linuxbrew/lib/libc.so.6: ELF file OS ABI invalid
/home/jerome/linuxbrew/Cellar/patchelf/0.8/bin/patchelf: error while loading shared libraries: /home/jerome/linuxbrew/lib/libc.so.6: ELF file OS ABI invalid
/home/jerome/linuxbrew/Cellar/patchelf/0.8/bin/patchelf: error while loading shared libraries: /home/jerome/linuxbrew/lib/libc.so.6: ELF file OS ABI invalid
==> Summary
/home/jerome/linuxbrew/Cellar/glibc/2.19: 1318 files, 43M, built in 4.6 minutes

After unlinking glibc, patchelf works again, but the glibc installation might not be complete right ?:

[jerome@srv11:~] 4m35s $ /home/jerome/linuxbrew/Cellar/patchelf/0.8/bin/patchelf
/home/jerome/linuxbrew/Cellar/patchelf/0.8/bin/patchelf: error while loading shared libraries: /home/jerome/linuxbrew/lib/libc.so.6: ELF file OS ABI invalid
[jerome@srv11:~] 127 $ brew unlink glibc
Unlinking /home/jerome/linuxbrew/Cellar/glibc/2.19... 318 symlinks removed
[jerome@srv11:~] $ /home/jerome/linuxbrew/Cellar/patchelf/0.8/bin/patchelf
syntax: /home/jerome/linuxbrew/Cellar/patchelf/0.8/bin/patchelf
  [--set-interpreter FILENAME]
  [--print-interpreter]
  [--set-rpath RPATH]
  [--shrink-rpath]
  [--print-rpath]
  [--force-rpath]
  [--remove-needed LIBRARY]
  [--debug]
  [--version]
  FILENAME

Best,
Jerome

@sjackman
Copy link
Member

Inconsistency detected by ld.so: get-dynamic-info.h: 134: elf_get_dynamic_info: Assertion `info[15] == ((void *)0)' failed!

I've managed to reproduce this error, but I have no idea what's causing it. I'll try to sort it out and get back to you.

@sjackman
Copy link
Member

Here's a related thread:
https://sourceware.org/ml/libc-help/2013-06/msg00038.html

@sjackman
Copy link
Member

@jrevillard What distribution of Linux are you using, and what version of GCC are you using to bootstrap the system?

@sjackman
Copy link
Member

@jrevillard The following patch may fix your issue. After applying the patch, try

brew update
brew reinstall glibc
cd `brew --prefix`
chmod +x lib/ld-linux-x86-64.so.2 lib/libc.so.6
brew test glibc
diff --git a/Library/Homebrew/extend/ENV/std.rb b/Library/Homebrew/extend/ENV/std.rb
index 9d067a6..1f484dd 100644
--- a/Library/Homebrew/extend/ENV/std.rb
+++ b/Library/Homebrew/extend/ENV/std.rb
@@ -57,7 +57,7 @@ module Stdenv

     append 'LDFLAGS', '-Wl,-headerpad_max_install_names' if OS.mac?

-    if OS.linux?
+    if OS.linux? && formula != "glibc"
       # Set the dynamic library search path
       append "LDFLAGS", "-Wl,-rpath,#{HOMEBREW_PREFIX}/lib"
       self["LD_RUN_PATH"] = "#{HOMEBREW_PREFIX}/lib"

@jrevillard
Copy link

Hi,

I'm building linuxbrew on a old Scientific Lunix 5 OS.
I updated linuxbrew and applied your patch but I still have the same problem:

$ brew reinstall glibc --debug
...
Fixing /home/jerome/linuxbrew/Cellar/glibc/2.19/lib/libc-2.19.so permissions from 755 to 444
/home/jerome/linuxbrew/Library/brew.rb (Formulary::StandardLoader): loading /home/jerome/linuxbrew/Library/Formula/patchelf.rb
Setting RPATH of /home/jerome/linuxbrew/Cellar/glibc/2.19/bin/gencat
/home/jerome/linuxbrew/opt/patchelf/bin/patchelf: error while loading shared libraries: /home/jerome/linuxbrew/lib/libc.so.6: ELF file OS ABI invalid
Error: Failed to fix install names
The formula built, but you may encounter issues using it or linking other
formula against it.
==> Failure while executing: /home/jerome/linuxbrew/opt/patchelf/bin/patchelf --set-rpath /home/jerome/linuxbrew/lib --set-interpreter /home/jerome/linuxbrew/opt/glibc/lib/ld-linux-x86-64.so.2 /home/jerome/linuxbrew/Cellar/glibc/2.19/bin/
/home/jerome/linuxbrew/Library/Homebrew/utils.rb:132:in `safe_system'
/home/jerome/linuxbrew/Library/Homebrew/keg_fix_install_names.rb:72:in `change_rpath'
/home/jerome/linuxbrew/Library/Homebrew/keg_fix_install_names.rb:8:in `fix_install_names'
/home/jerome/linuxbrew/Library/Homebrew/extend/pathname.rb:324:in `ensure_writable'
/home/jerome/linuxbrew/Library/Homebrew/keg_fix_install_names.rb:7:in `fix_install_names'
/home/jerome/linuxbrew/Library/Homebrew/keg_fix_install_names.rb:6:in `each'
/home/jerome/linuxbrew/Library/Homebrew/keg_fix_install_names.rb:6:in `fix_install_names'
/home/jerome/linuxbrew/Library/Homebrew/formula_installer.rb:584:in `fix_install_names'
/home/jerome/linuxbrew/Library/Homebrew/formula_installer.rb:405:in `finish'
/home/jerome/linuxbrew/Library/Homebrew/cmd/reinstall.rb:32:in `reinstall_formula'
/home/jerome/linuxbrew/Library/Homebrew/cmd/reinstall.rb:5:in `reinstall'
/home/jerome/linuxbrew/Library/Homebrew/cmd/reinstall.rb:5:in `each'
/home/jerome/linuxbrew/Library/Homebrew/cmd/reinstall.rb:5:in `reinstall'
/home/jerome/linuxbrew/Library/brew.rb:131:in `send'
/home/jerome/linuxbrew/Library/brew.rb:131
==> Summary
/home/jerome/linuxbrew/Cellar/glibc/2.19: 1318 files, 43M, built in 4.6 minutes
$ brew test glibc
Testing glibc
==> /home/jerome/linuxbrew/Cellar/glibc/2.19/lib/ld-linux-x86-64.so.2 2>&1 |grep ld.so
==> /home/jerome/linuxbrew/Cellar/glibc/2.19/lib/libc.so.6 --version
Inconsistency detected by ld.so: get-dynamic-info.h: 134: elf_get_dynamic_info: Assertion `info[15] == ((void *)0)' failed!
Error: glibc: failed
Failed executing: /home/jerome/linuxbrew/Cellar/glibc/2.19/lib/libc.so.6 --version 
/home/jerome/linuxbrew/Library/Homebrew/formula.rb:557:in `system'
/home/jerome/linuxbrew/Library/Homebrew/formula.rb:541:in `open'
/home/jerome/linuxbrew/Library/Homebrew/formula.rb:541:in `system'
/home/jerome/linuxbrew/Library/Formula/glibc.rb:36
/home/jerome/linuxbrew/Library/Homebrew/formula.rb:484:in `instance_eval'
/home/jerome/linuxbrew/Library/Homebrew/formula.rb:484:in `test'
/home/jerome/linuxbrew/Library/Homebrew/extend/fileutils.rb:21:in `mktemp'
/home/jerome/linuxbrew/Library/Homebrew/formula.rb:482:in `test'
/home/jerome/linuxbrew/Library/Homebrew/cmd/test.rb:57:in `test'
/usr/lib/ruby/1.8/timeout.rb:67:in `timeout'
/home/jerome/linuxbrew/Library/Homebrew/cmd/test.rb:56:in `test'
/home/jerome/linuxbrew/Library/Homebrew/cmd/test.rb:36:in `each'
/home/jerome/linuxbrew/Library/Homebrew/cmd/test.rb:36:in `test'
/home/jerome/linuxbrew/Library/brew.rb:131:in `send'
/home/jerome/linuxbrew/Library/brew.rb:131

Best,
Jerome

@jrevillard
Copy link

By the way, the boostrap gcc version is old of course

$ gcc -v
Utilisation des specs internes.
Target: x86_64-redhat-linux
Configuré avec: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --disable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux
Modèle de thread: posix
version gcc 4.1.2 20080704 (Red Hat 4.1.2-54)

@jrevillard
Copy link

I restarted from scratch, in fact now, with the fixes even the patchelf installation does not work properly:

==> Finishing up
ln -s ../Cellar/patchelf/0.8/bin/patchelf patchelf
ln -s ../../../Cellar/patchelf/0.8/share/man/man1/patchelf.1 patchelf.1
ln -s ../../Cellar/patchelf/0.8/share/doc/patchelf patchelf
/home/jerome/linuxbrew/Library/brew.rb (Formulary::StandardLoader): loading /home/jerome/linuxbrew/Library/Formula/glibc.rb
Setting RPATH of /home/jerome/linuxbrew/Cellar/patchelf/0.8/bin/patchelf
/home/jerome/linuxbrew/opt/patchelf/bin/patchelf --set-rpath /home/jerome/linuxbrew/lib /home/jerome/linuxbrew/Cellar/patchelf/0.8/bin/patchelf 
Error: Failed to fix install names
The formula built, but you may encounter issues using it or linking other
formula against it.
==> Failure while executing: /home/jerome/linuxbrew/opt/patchelf/bin/patchelf --set-rpath /home/jerome/linuxbrew/lib /home/jerome/linuxbrew/Cellar/patchelf/0.8/bin/patchelf 
/home/jerome/linuxbrew/Library/Homebrew/utils.rb:132:in `safe_system'
/home/jerome/linuxbrew/Library/Homebrew/keg_fix_install_names.rb:72:in `change_rpath'
/home/jerome/linuxbrew/Library/Homebrew/keg_fix_install_names.rb:8:in `fix_install_names'
/home/jerome/linuxbrew/Library/Homebrew/extend/pathname.rb:324:in `ensure_writable'
/home/jerome/linuxbrew/Library/Homebrew/keg_fix_install_names.rb:7:in `fix_install_names'
/home/jerome/linuxbrew/Library/Homebrew/keg_fix_install_names.rb:6:in `each'
/home/jerome/linuxbrew/Library/Homebrew/keg_fix_install_names.rb:6:in `fix_install_names'
/home/jerome/linuxbrew/Library/Homebrew/formula_installer.rb:584:in `fix_install_names'
/home/jerome/linuxbrew/Library/Homebrew/formula_installer.rb:405:in `finish'
/home/jerome/linuxbrew/Library/Homebrew/cmd/install.rb:120:in `install_formula'
/home/jerome/linuxbrew/Library/Homebrew/cmd/install.rb:45:in `install'
/home/jerome/linuxbrew/Library/Homebrew/cmd/install.rb:45:in `each'
/home/jerome/linuxbrew/Library/Homebrew/cmd/install.rb:45:in `install'
/home/jerome/linuxbrew/Library/brew.rb:131:in `send'
/home/jerome/linuxbrew/Library/brew.rb:131
==> Summary
/home/jerome/linuxbrew/Cellar/patchelf/0.8: 6 files, 232K, built in 7 seconds

@sjackman
Copy link
Member

@jrevillard The short answer is brew unlink glibc.

@mbsullivan
Copy link
Contributor Author

@sjackman, using LD_TRACE_LOADED_OBJECTS as indicated here seems to have no effect for me. The system libraries are still used.

Fantastic work with the standalone instructions, but I have a few issues with my machine setup. I will address them in a separate comment shortly.

@mbsullivan
Copy link
Contributor Author

PS, whoops sorry for closing.

@mbsullivan
Copy link
Contributor Author

So, my issues with the standalone instructions all relate to problems with gcc-4.9 so far rather than anything with the instructions themselves.

I have different problems on an old system and a new system, so I've separated them below:

Old system:

On a system with an old system installation of /usr/bin/gcc (gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-54)), I think I run into issues due to the age of the compiler. (PS, this is the same version as @jrevillard, but he seems to have gotten gcc-4.9 installed somehow.)

The error it throws is:

g++: braced spec '%:sanitize(address):%{!shared:libasan_preinit%O%s} %{static-libasan:%{!shared:-Bstatic --whole-archive -lasan --no-whole-archive -Bdynamic}}%{!static-libasan:-lasan}}     %{%:sanitize(thread):%{static-libtsan:%{!shared:-Bstatic --whole-archive -ltsan --no-whole-archive -Bdynamic}}%{!static-libtsan:-ltsan}}' is invalid at '%'
make[3]: *** [lto1] Error 1
make[3]: *** Waiting for unfinished jobs....
rm gcc.pod
make[3]: Leaving directory `/tmp/gcc-v31236/gcc-4.9.1/build/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/tmp/gcc-v31236/gcc-4.9.1/build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/tmp/gcc-v31236/gcc-4.9.1/build'
make: *** [bootstrap] Error 2

I have newer versions of gcc installed elsewhere on the system (not managed by this Linuxbrew branch). However, there is no way to use these versions in lieu of /usr/bin/gcc, right?

New system (Fedora Core 20, using gcc (GCC) 4.8.3 20140624 (Red Hat 4.8.3-1)):

I get the same error as @aktau in #123.

Mike

@sjackman
Copy link
Member

@mbsullivan To use a newer version of GCC, try

ln -s /usr/bin/gcc44 ~/.linuxbrew/bin/gcc-4.4
ln -s /usr/bin/g++44 ~/.linuxbrew/bin/g++-4.4
ln -s /usr/bin/gfortran44 ~/.linuxbrew/bin/gfortran-4.4
export HOMEBREW_CC=~/.linuxbrew/bin/gcc-4.4

@mbsullivan
Copy link
Contributor Author

@sjackman, no can do. No admin access.

EDIT: Wait, I read that backwards. I see now. Lemme try.

EDIT 2: It gets the same error linking to a system installation of gcc 4.7.1. It must be due to some other oddity in the system gcc setup then, I guess. Linuxbrew's gcc formula installed fine for me back when it was 4.8, but unfortunately versions/gcc48 does not work.

@jbaum98
Copy link
Contributor

jbaum98 commented Dec 2, 2014

Looking at #7 was very educational and I may have solved my problem using patchelf. Thanks for your help.

@jbaum98
Copy link
Contributor

jbaum98 commented Dec 2, 2014

Using patchelf I modified gcc, g++, cc1 and cc1plus so things build without setting LD_LIBRARY_PATH or changing Linuxbrew code. I also needed to reinstall diffutils, gpatch, and gawk after installing glibc to get rid of those segfaults. Now I get pretty far into building glibc when it says the linker can't find crti.o and libc_nonshared.a.

@sjackman
Copy link
Member

sjackman commented Dec 2, 2014

I'm glad to hear that you're making progress. Those packages you mention should all be installed before after glibc. I'd recommend wiping out your linuxbrew directory, starting from scratch, and following the standalone installation instructions quite carefully. If you run into an error, post the exact command line that produced the error and the complete log in a gist.

@jbaum98
Copy link
Contributor

jbaum98 commented Dec 2, 2014

I need to install those packages just to get to that point. My system has too old a version of gawk for glibc and needs diffutils for binutils. Reinstalling them after glibc fixes everything up until the error I mentioned above.

@sjackman
Copy link
Member

sjackman commented Dec 2, 2014

Ah, I see. Can you post the complete log in a gist?

@jbaum98
Copy link
Contributor

jbaum98 commented Dec 2, 2014

https://gist.github.com/7b4ffca62106ffa6bda4.git
I replicated the issue it's specifically the following command executed in gcc-4.9.2/build/x86_64-unknown-linux-gnu/libgcc

/usr/local/linuxbrew/tmp/gcc-H92WgH/gcc-4.9.2/build/./gcc/xgcc -B/usr/local/linuxbrew/tmp/gcc-H92WgH/gcc-4.9.2/build/./gcc/ -B/usr/local/linuxbrew/Cellar/gcc/4.9.2/x86_64-unknown-linux-gnu/bin/ -B/usr/local/linuxbrew/Cellar/gcc/4.9.2/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/linuxbrew/Cellar/gcc/4.9.2/x86_64-unknown-linux-gnu/include -isystem /usr/local/linuxbrew/Cellar/gcc/4.9.2/x86_64-unknown-linux-gnu/sys-include    -O2  -g -O2 -Os -w -pipe -march=core2 -DIN_GCC    -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fpic -mlong-double-80 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector  -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o ./libgcc_s.so.1.tmp -g -O2 -Os -w -pipe -march=core2 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o cpuinfo_s.o sfp-exceptions_s.o addtf3_s.o divtf3_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o fixtfti_s.o fixunstfti_s.o floattitf_s.o floatuntitf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o getf2_s.o letf2_s.o eqtf2_s.o _divtc3_s.o _multc3_s.o _powitf2_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so

@jbaum98
Copy link
Contributor

jbaum98 commented Dec 2, 2014

okay, the problem is fixed by executing the above command adding -B/usr/local/linuxbrew/lib, but how do I make that added automatically for all commands?

@sjackman
Copy link
Member

sjackman commented Dec 3, 2014

I don't see an error message in that gist, only a successful run of configure: configure: exit 0.

@jbaum98
Copy link
Contributor

jbaum98 commented Dec 3, 2014

Sorry my bad the configure runs fine, it's make that breaks. Where would I find a log for make?

@jbaum98
Copy link
Contributor

jbaum98 commented Dec 3, 2014

More info: the error given by the above command is:

/usr/local/linuxbrew/Cellar/binutils/2.24/x86_64-unknown-linux-gnu/bin/ld: cannot find crti.o: No such file or directory
/usr/local/linuxbrew/Cellar/binutils/2.24/x86_64-unknown-linux-gnu/bin/ld: cannot find /usr/lib64/libc_nonshared.a

I can get rid of the first by linking /usr/local/linuxbrew/lib/crti.o or by setting export LIBRARY_PATH=/usr/local/linuxbrew/lib in the debug shell, but I can't make it look anywhere but /usr/lib64 for libc_nonshared.a, which I don't have write permissions for.

@jbaum98
Copy link
Contributor

jbaum98 commented Dec 3, 2014

Maybe the issue is related to line in Standalone guide: ln -s lib ~/.linuxbrew/lib64. What is the current directory, because lib is not an absolute path. This is the only command I skipped. I tried linking all of /usr/local/lib, /usr/local/lib64, /usr/lib, /usr/lib64, /lib and /lib64 to /usr/local/linuxbrew/lib64 but none of them helped my error.

@jbaum98
Copy link
Contributor

jbaum98 commented Dec 3, 2014

@sjackman
Copy link
Member

sjackman commented Dec 3, 2014

What is the current directory, because lib is not an absolute path.

Symlinks are relative to the location of the symlink itself.

This is the only command I skipped.

Don't skip this command.

@sjackman
Copy link
Member

sjackman commented Dec 3, 2014

That being said, I don't think that the lib64 symlink is the source of your error. I think binutils has to be configured at its compile time to search a different location crti.o and libc.

@jbaum98
Copy link
Contributor

jbaum98 commented Dec 3, 2014

I can do that with crti.o because it isn't searching in a specific place, but for libc it complains /usr/lib64/libc_nonshared.a specifically at that location.

@jbaum98
Copy link
Contributor

jbaum98 commented Dec 4, 2014

In the debug shell I set GCC_EXEC_PREFIX to /usr/local/linuxbrew/lib, and now it seems to be working, or at least it got past that one error (it's running as right now). Is this a good solution that should be added in or will this cause other problems?

@sjackman
Copy link
Member

sjackman commented Dec 4, 2014

I'm not sure. I've confirmed that my gcc toolchain is linking against /usr/lib64/crti.o when it should be linking against /home/sjackman/.linuxbrew/lib/crti.o. I'll need to do some research to figure out how to fix that. If I set GCC_EXEC_PREFIX=/home/sjackman/.linuxbrew/lib I get the error message cc: error trying to exec 'cc1': execvp: No such file or directory.

@jbaum98
Copy link
Contributor

jbaum98 commented Dec 4, 2014

I also get an error setting GCC_EXEC_PREFIX at the beginning, which implies that it needs to be set after the process starts using that xgcc it builds in the beginning. We need to find a way to break up the make bootstrap into smaller pieces, or to somehow target only the later part. Based on this I think it has something to do with setting it for stages 2 and 3, but leaving it alone for stage 1.

@sjackman
Copy link
Member

sjackman commented Dec 4, 2014

The solution I think requires finding a configure flag to specify to either binutils or gcc where to find glibc. You could try asking on the GCC mailing list.

Am I correct in understanding that you don't have crti.o installed in either /usr/lib or /usr/lib64? Can you report find / -name crti.o?

@jbaum98
Copy link
Contributor

jbaum98 commented Dec 4, 2014

/usr/local/linuxbrew/Cellar/glibc/2.19/lib/crti.o
/usr/local/linuxbrew/lib/crti.o
/usr/local/lib/crti.o
/mnt/stateful_partition/dev_image/linuxbrew/Cellar/glibc/2.19/lib/crti.o
/mnt/stateful_partition/dev_image/linuxbrew/lib/crti.o
/mnt/stateful_partition/dev_image/lib/crti.o

I'm not positive about /mnt/stateful_partition/dev_image but I'm 99% sure it's a duplicate of my root directory for chromebooky reasons.

@jbaum98
Copy link
Contributor

jbaum98 commented Dec 4, 2014

I found how to split it up into the 3 stages, and it doesn't even make it past stage 1 before it starts using xgcc instead and the error happens.

@jbaum98
Copy link
Contributor

jbaum98 commented Dec 4, 2014

It might have something to do with ldconfig, because ldconfig usually doesn't look where glibc.

@sjackman
Copy link
Member

sjackman commented Dec 4, 2014

The real question is how to configure binutils/glibc when glibc is installed in a non-standard location.

@jbaum98
Copy link
Contributor

jbaum98 commented Dec 5, 2014

This may be just a chromebook specific issue, but at least for me ld.so.cache doesn't update because of permissions, so maybe that inhibits programs from looking there. Did you check if ldconfig -p includes linuxbrew directories?

@sjackman
Copy link
Member

sjackman commented Dec 5, 2014

ldconfig -p does not include Linuxbrew directories. Linuxbrew uses RPATH instead.

@jbaum98
Copy link
Contributor

jbaum98 commented Dec 5, 2014

http://www.tldp.org/HOWTO/Glibc2-HOWTO-6.html This seems to talk about that but I can't really understand what it's saying maybe you can make sense of it? The part that confuses me is what should be substituted for i486-linuxglibc2?

sjackman added a commit that referenced this issue Jan 22, 2016
Set LIBRARY_PATH so that GCC knows where to find the glibc libraries
and object files, such as crt1.o, crti.o and crtn.o.

See #107
See #200
@sjackman
Copy link
Member

I believe these issues are resolved. I'm closing this ticket. Feel free to open a new ticket if some of the issues raised here are still current.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants