Building Gcc with Glibc in a Non-Standard Location Without Root

Building GCC with glibc in a non-standard location without root

I am in a hurry so I can't analyze your error messages in detail.

Newer glibc and old glibc are not only ABI incompatible, but also headers, see gcc bug 52922.

Therefore any mixing will result in errors like you encountered, you need to be extremely careful.

Hand tuning is hopelessly tedious.

If your goal is to use gcc-4.7.2, I recommend you to Gentoo Prefix. I have many instances of Gentoo Prefix running on RHEL 5 (which have 2.6.18 kernel, gcc-4.1 and glibc-2.5 as you do). This compiles gcc-4.7.2 on top of glibc-2.5.

If your want some fun of using newer glibc, take a look at Prefix/libc. It is a work-in-progress though. Expect many breakage. But it won't be a big draw back as you are trying to compile out a modern toolchain by hand, will it?

Error while building glibc

It looks like you are trying to make install, without first doing a successful make all.

Multiple glibc libraries on a single host

It is very possible to have multiple versions of glibc on the same system (we do that every day).

However, you need to know that glibc consists of many pieces (200+ shared libraries) which all must match. One of the pieces is ld-linux.so.2, and it must match libc.so.6, or you'll see the errors you are seeing.

The absolute path to ld-linux.so.2 is hard-coded into the executable at link time, and can not be easily changed after the link is done (Update: can be done with patchelf; see this answer below).

To build an executable that will work with the new glibc, do this:

g++ main.o -o myapp ... \
   -Wl,--rpath=/path/to/newglibc \
   -Wl,--dynamic-linker=/path/to/newglibc/ld-linux.so.2

The -rpath linker option will make the runtime loader search for libraries in /path/to/newglibc (so you wouldn't have to set LD_LIBRARY_PATH before running it), and the -dynamic-linker option will "bake" path to correct ld-linux.so.2 into the application.

If you can't relink the myapp application (e.g. because it is a third-party binary), not all is lost, but it gets trickier. One solution is to set a proper chroot environment for it. Another possibility is to use rtldi and a binary editor. Update: or you can use patchelf.

How to build a C program using a custom version of glibc and static linking?

Following a couple of suggestions from the glibc help mailing list (libc-help@sourceware.org), I have a solution. It turns out that this task is a bit tricky because you have to tell the linker to omit everything it would normally include automatically (and silently), and then include back everything that it needs, including a bunch of start and end files. Some of the start and end files come from libc and some come from gcc, so the make rule is a bit complicated. Below is a general sample makefile to illustrate the approach. I will assume that you are building a program called prog from a source file called prog.c and that you have installed your custom glibc in directory /home/my_acct/glibc_install.

TARGET = prog
OBJ = $(TARGET).o
SRC = $(TARGET).c
CC = gcc
CFLAGS = -g
LDFLAGS = -nostdlib -nostartfiles -static
GLIBCDIR = /home/my_acct/glibc_install/lib
STARTFILES = $(GLIBCDIR)/crt1.o $(GLIBCDIR)/crti.o `gcc --print-file-name=crtbegin.o`
ENDFILES = `gcc --print-file-name=crtend.o` $(GLIBCDIR)/crtn.o
LIBGROUP = -Wl,--start-group $(GLIBCDIR)/libc.a -lgcc -lgcc_eh -Wl,--end-group

$(TARGET): $(OBJ)
        $(CC) $(LDFLAGS) -o $@ $(STARTFILES) $^ $(LIBGROUP) $(ENDFILES) 

$(OBJ): $(SRC)
        $(CC) $(CFLAGS) -c $^

clean:
        rm -f *.o *.~ $(TARGET)

Removing glibc dependency when compiling with gcc

Is it possible to compile a program using gcc without depending on glibc?

Yes, there are alternative libc versions, such as Musl, uClibc, dietLibc, etc. See their documentation on how to use them.

Your problem does not appear to be a GLIBC dependency, but rather a mismatch between your build and your target hosts. In particular, your target has older GLIBC than your build host.

The easiest to solution for that problem is to build on an old-enough system -- your binary will run on anything that is as-old or newer. You could do that inside a VM or in a docker container, so you don't have to downgrade your main system.

You could also link your program statically (add -static flag), but beware -- for many non-trivial programs this will make your binary less portable.

Building shared libc.so for System V ABI under GNU ABI

After different combinations of configuration options I got an answer.
The right configuration commands:

For x32 systems:

../configure --prefix=... --enable-kernel=2.4.0 --with-cpu=i686 --build=i686-unknown-linux-gnu CC="gcc -i686" CXX="g++ -i686"

For x64 systems:

../configure --prefix=... --enable-kernel=2.4.0 --with-cpu=i686 --build=i686-unknown-linux-gnu CC="gcc -m32" CXX="g++ -m32"

And you need to export CFLAGS with the next value:

export CFLAGS="-mtune=native -O2 -pipe"

---

Related Topics