error while using make to compile Glibc-2.11.1 for Linux From Scratch

You need to install gawk.

sudo apt-get install gawk

---

The regex on Line 19 was

/\/[^/]+$/

It is a known issue that mawk does not understand unescaped '/' in character classes at least up to version 1.3.3-15 (the one supplied on Ubuntu 11.04 (Natty)). mawk will think the / inside the bracket terminates the regex, and interpret as \/[^, which is surely a syntax error due to unmatched ].

The fix for glibc is trivial: just add a \ before the /. But this may also be a dedicate "check" to ensure gawk is used. At least this is still not changed on glibc-2.14…

^{(Source of solution: http://www.linuxquestions.org/questions/linux-from-scratch-13/urgent-help-on-glibc-make-error-with-clfs-590753/)}

error while building Glibc-2.11.1 for Linux From Scratch

Why is it so ?

The file crti.S that is failing to build is generated by compiling csu/initfini.c, and then splitting the resulting initfini.s on "magic markers".

Unfortunately, this splitting is extremely dependent on the version of gcc that is used to generate initfini.s, and doesn't always work.

This entire mechanism has been eliminated in Feb 2012.

Your options are:

• build a newer version of glibc (current is 2.19), or
• build using older version of GCC (Google search shows many instances of gcc-4.6 causing this problem).

Glibc Compilation Error

The problem is caused by your GCC defining __i686. You can confirm that in fact it does that with this command:

gcc -dD -E -xc /dev/null | grep __i686

If this command produces output, then that's the problem. To fix it, use:

configure --prefix=/usr CC='gcc -U__i686'

or build a newer version of glibc.

========================================================================
EDIT:

Some other links which were useful:

Awk Issue

Gawk Installation

Update software on Ubuntu

Building Glibc 2.33 for Linux results in unit test failures

The reported failures all seem to be related to bugs and limitations in the Glibc 2.33 test harness, plus one VM-related bug.

Detailed test failure explanations

elf/tst-cpu-features-cpuinfo

This test is failing due to a VM software bug and not because of Glibc 2.33. The error log is shown below and can be ignored when the build is performed in a VM (although the build should probably be performed on a host to minimize any chance of optimizations getting disabled).

    [snip]
    Checking HAS_CPU_FEATURE (ERMS):
      HAS_CPU_FEATURE (ERMS): 1
      cpuinfo (erms): 0
     *** failure ***
    [snip]
    1 differences between /proc/cpuinfo and glibc code.

See https://sourceware.org/bugzilla/show_bug.cgi?id=26823, https://bugzilla.redhat.com/show_bug.cgi?id=1128638
and https://sourceware.org/bugzilla/show_bug.cgi?id=24080

nptl/tst-mutex10

This test is timing out.

Remaining 147 tests

These tests are failing due to a limitation in the test harness related "to when a build is configured for a non-standard prefix (i.e. not /usr)" (see the bug-atexit3 and nptl tests section of https://sourceware.org/glibc/wiki/Testing/Testsuite)

Workaround

**** Please note: The following directions should probably not be directly followed to create a new "stand-alone" build of Glibc 2.33. Instead, these directions should be incorporated into a larger set of steps that build an entire toolchain (GCC, Binutils, Glibc, etc.) ****

The following workaround can be used to build Glibc 2.33 in Ubuntu 21.04 with the default compiler. Optionally first, build Glibc 2.33 by setting the prefix to /usr and verify only the elf/tst-cpu-features-cpuinfo test fails (the test should only fail when built in a VM). Then, rebuild Glibc 2.33 with the desired prefix.

Build Glibc 2.33 with prefix set to /usr

**** WARNING: DO NOT PERFORM A make install OR THE SYSTEM WILL BE CORRUPTED ****

The following build steps will result in a build with only a single failure (elf/tst-cpu-features-cpuinfo) when performed on a VM and should result in no failures when performed directly on a host computer (configured as described in the question).

    wget https://ftp.gnu.org/gnu/glibc/glibc-2.33.tar.gz -P ${HOME}/Downloads
    rm -rf ${HOME}/Projects/BuildToolchainUsr && mkdir -p ${HOME}/Projects/BuildToolchainUsr/Build
    tar -xf ${HOME}/Downloads/glibc-2.33.tar.gz -C ${HOME}/Projects/BuildToolchainUsr
    cd ${HOME}/Projects/BuildToolchainUsr/Build
    ../glibc-2.33/configure --prefix=/usr 2>&1 | tee output-configure.txt
    make -j`nproc` 2>&1 | tee output-make.txt
    make check 2>&1 | tee output-make-check.txt

The above steps should result the following test results:

    UNSUPPORTED: elf/tst-audit10
    UNSUPPORTED: elf/tst-avx512
    UNSUPPORTED: elf/tst-cet-legacy-8
    UNSUPPORTED: elf/tst-cet-property-2
    FAIL: elf/tst-cpu-features-cpuinfo
    XPASS: elf/tst-protected1a
    XPASS: elf/tst-protected1b
    UNSUPPORTED: math/test-double-libmvec-sincos-avx512
    UNSUPPORTED: math/test-float-libmvec-sincosf-avx512
    UNSUPPORTED: misc/tst-pkey
    UNSUPPORTED: nptl/test-cond-printers
    UNSUPPORTED: nptl/test-condattr-printers
    UNSUPPORTED: nptl/test-mutex-printers
    UNSUPPORTED: nptl/test-mutexattr-printers
    UNSUPPORTED: nptl/test-rwlock-printers
    UNSUPPORTED: nptl/test-rwlockattr-printers
    UNSUPPORTED: posix/tst-cet-vfork-1
    Summary of test results:
          1 FAIL
       4352 PASS
         14 UNSUPPORTED
         17 XFAIL
          2 XPASS

Build Glibc 2.33 with the desired prefix

Glibc 2.33 can then be built with the following commands to use the desired prefix value. While 2 tests will fail (1 if built directly on a host), the failures are a result of the test harness's limitations and can be safely ignored.

Detailed workaround explanation

The workaround resolves all but one of the prefix related test failures by creating symlinks for libstdc++.so.6 and libgcc_s.so.1 plus executing the test suite twice, creating additional symlinks before the second execution. The first two symlinks ensure all unit tests are able to find both libstdc++.so.6 and libgcc_s.so.1. When the test suite is first run, a directory named testroot.pristine is created, which is used to provide a clean chroot for each unit test. At the start of an individual unit test, the testroot.pristine directory is copied to testroot.root (replacing any existing testroot.root directories) and a chroot is setup. Individual unit test can have test specific files that get copied into the testroot.root directory.

After the first execution of the test suite, there will be 5 failures (4 if run outside of a VM). Three of these failures are due to the unit tests assuming the prefix is always /usr. To resolve this, a second set of symlinks are created in the testroot.prestine directory, to ensure the 3 unit tests are able to find the required files. All of the *.out files in the Build directory are then deleted so the full test suite can be rerun without recreating the testroot.prestine directory.

    rm -rf ${HOME}/Projects/BuildToolchain && mkdir -p ${HOME}/Projects/BuildToolchain/Build
    tar -xf ${HOME}/Downloads/glibc-2.33.tar.gz -C ${HOME}/Projects/BuildToolchain
    cd ${HOME}/Projects/BuildToolchain/Build
    ../glibc-2.33/configure --prefix=${HOME}/Projects/BuildToolchain/Install 2>&1 | tee output-configure.txt
    make -j`nproc` 2>&1 | tee output-make.txt
    ln -s /lib/x86_64-linux-gnu/libstdc++.so.6
    ln -s /lib/x86_64-linux-gnu/libgcc_s.so.1
    TIMEOUTFACTOR=16 make check 2>&1 | tee output-make-checkA.txt
    mkdir testroot.pristine/usr
    ln -s ${HOME#/}/Projects/BuildToolchain/Install/etc testroot.pristine/etc
    ln -s ${HOME#/}/Projects/BuildToolchain/Install/lib testroot.pristine/lib64
    ln -s ${HOME#/}/Projects/BuildToolchain/Install/sbin testroot.pristine/sbin
    ln -s ${HOME#/}/Projects/BuildToolchain/Install/var testroot.pristine/var
    ln -s ..${HOME}/Projects/BuildToolchain/Install/bin testroot.pristine/usr/bin
    ln -s ..${HOME}/Projects/BuildToolchain/Install/include testroot.pristine/usr/include
    ln -s ..${HOME}/Projects/BuildToolchain/Install/lib testroot.pristine/usr/lib
    ln -s ..${HOME}/Projects/BuildToolchain/Install/lib testroot.pristine/usr/lib64
    ln -s ..${HOME}/Projects/BuildToolchain/Install/libexec testroot.pristine/usr/libexec
    ln -s ..${HOME}/Projects/BuildToolchain/Install/sbin testroot.pristine/usr/sbin
    ln -s ..${HOME}/Projects/BuildToolchain/Install/share testroot.pristine/usr/share
    find -name "*.out" -delete
    TIMEOUTFACTOR=16 make check 2>&1 | tee output-make-checkB.txt

Notes

TIMEOUTFACTOR: This environment variable is used to increase the timeout value used by the test harness.

The expected test output after the first make check command:

    FAIL: elf/check-abi-libc
    UNSUPPORTED: elf/tst-audit10
    UNSUPPORTED: elf/tst-avx512
    UNSUPPORTED: elf/tst-cet-legacy-8
    UNSUPPORTED: elf/tst-cet-property-2
    FAIL: elf/tst-cpu-features-cpuinfo
    FAIL: elf/tst-glibc-hwcaps-prepend-cache
    FAIL: elf/tst-ldconfig-ld_so_conf-update
    XPASS: elf/tst-protected1a
    XPASS: elf/tst-protected1b
    UNSUPPORTED: math/test-double-libmvec-sincos-avx512
    UNSUPPORTED: math/test-float-libmvec-sincosf-avx512
    UNSUPPORTED: misc/tst-pkey
    UNSUPPORTED: nptl/test-cond-printers
    UNSUPPORTED: nptl/test-condattr-printers
    UNSUPPORTED: nptl/test-mutex-printers
    UNSUPPORTED: nptl/test-mutexattr-printers
    UNSUPPORTED: nptl/test-rwlock-printers
    UNSUPPORTED: nptl/test-rwlockattr-printers
    FAIL: nss/tst-nss-files-hosts-long
    UNSUPPORTED: posix/tst-cet-vfork-1
    UNSUPPORTED: resolv/tst-resolv-ai_idn
    UNSUPPORTED: resolv/tst-resolv-ai_idn-latin1
    Summary of test results:
          5 FAIL
       4346 PASS
         16 UNSUPPORTED
         17 XFAIL
          2 XPASS

The expected test output after the second make check command:

    FAIL: elf/check-abi-libc
    UNSUPPORTED: elf/tst-audit10
    UNSUPPORTED: elf/tst-avx512
    UNSUPPORTED: elf/tst-cet-legacy-8
    UNSUPPORTED: elf/tst-cet-property-2
    FAIL: elf/tst-cpu-features-cpuinfo
    XPASS: elf/tst-protected1a
    XPASS: elf/tst-protected1b
    UNSUPPORTED: math/test-double-libmvec-sincos-avx512
    UNSUPPORTED: math/test-float-libmvec-sincosf-avx512
    UNSUPPORTED: misc/tst-pkey
    UNSUPPORTED: nptl/test-cond-printers
    UNSUPPORTED: nptl/test-condattr-printers
    UNSUPPORTED: nptl/test-mutex-printers
    UNSUPPORTED: nptl/test-mutexattr-printers
    UNSUPPORTED: nptl/test-rwlock-printers
    UNSUPPORTED: nptl/test-rwlockattr-printers
    UNSUPPORTED: posix/tst-cet-vfork-1
    UNSUPPORTED: resolv/tst-resolv-ai_idn
    UNSUPPORTED: resolv/tst-resolv-ai_idn-latin1
    Summary of test results:
          2 FAIL
       4349 PASS
         16 UNSUPPORTED
         17 XFAIL
          2 XPASS

Detailed test failure explanations

elf/check-abi-libc
This test fails because the _nl_default_dirname symbol stores the path to the locale file (see https://sourceware.org/pipermail/libc-alpha/2012-December/036816.html). When the prefix is set to /usr, the locale file path is /usr/share/locale but with the above directions, the path is ${HOME}/Projects/BuildToolchain/Install/share/locale (with the ${HOME} variable expanded). This failure can safely be ignored.

    --- ../sysdeps/unix/sysv/linux/x86_64/64/libc.abilist   2021-02-01 12:15:33.000000000 -0500
    +++ /home/sandy/Projects/BuildToolchain/Build/libc.symlist      2021-07-14 18:18:50.040682543 -0400
    @@ -499 +499 @@ GLIBC_2.2.5 _mcount F
    -GLIBC_2.2.5 _nl_default_dirname D 0x12
    +GLIBC_2.2.5 _nl_default_dirname D 0x39

How can I link to a specific glibc version?

You are correct in that glibc uses symbol versioning. If you are curious, the symbol versioning implementation introduced in glibc 2.1 is described here and is an extension of Sun's symbol versioning scheme described here.

One option is to statically link your binary. This is probably the easiest option.

You could also build your binary in a chroot build environment, or using a glibc-new => glibc-old cross-compiler.

According to the http://www.trevorpounds.com blog post Linking to Older Versioned Symbols (glibc), it is possible to to force any symbol to be linked against an older one so long as it is valid by using the same .symver pseudo-op that is used for defining versioned symbols in the first place. The following example is excerpted from the blog post.

The following example makes use of glibc’s realpath, but makes sure it is linked against an older 2.2.5 version.

#include <limits.h>
#include <stdlib.h>
#include <stdio.h>

__asm__(".symver realpath,realpath@GLIBC_2.2.5");
int main()
{
    const char* unresolved = "/lib64";
    char resolved[PATH_MAX+1];

    if(!realpath(unresolved, resolved))
        { return 1; }

    printf("%s\n", resolved);

    return 0;
}

How can I compile php-cgi binary using a custom glibc for suse enterprise linux out of cygwin?

How can I compile php-cgi binary using a custom glibc for suse enterprise linux out of cygwin?

Pretty straight to the point I think.

No, a very confused and circuitous question.

First, cygwin has absolutely nothing to do with your question: it's for running UNIX programs on Windows, which is not at all what you are asking about.

Second, your question appears to be: "how do I run pre-build php-cgi binary on a system that has older glibc than the one php-cgi has been built on?", and not about compiling anything.

To that question, the answer is: you can't (easily) -- UNIX systems do not support forward binary compatibility (build on a new system, run on an older one). Only backward compatibility is supported (old dynamically-linked binaries continue to run on newer systems).

Your best approach is to try to build php-cgi on your system (which would eliminate its dependency on GLIBC_2.7. If you can't, you should still be able to run such a binary against unpacked glibc-2.7 build, if that binary doesn't re-exec itself. The way to do that, assuming you unpacked glibc-2.7 into e.g. /tmp/glibc-2.7 is something like:

/tmp/glibc-2.7/lib/ld-linux.so.2 --library-path \
    /tmp/glibc-2.7/lib:/lib:/usr/lib \
  /path/to/php-cgi <args>

(The library path above may need some adjustments to make the loader find all the required libraries.)

Update:

is it practical to compile stuff for my linux box in cygwin

It is possible, but significantly more pain then simply compiling on the linux box itself (and so isn't really practical). You appear to lack any reason to want to do that, other than mis-guided belief that cygwin solves all problems.

---

Related Topics