特定の glibc バージョンにリンクするにはどうすればよいですか?

glibc はシンボルのバージョン管理を使用するという点で正しいです。興味のある方は、glibc 2.1 で導入されたシンボルバージョン管理の実装についてここで説明します。これは、ここで説明する Sun のシンボルバージョン管理スキームの拡張です。

1 つのオプションは、バイナリを静的にリンクすることです。これがおそらく最も簡単なオプションです。

chroot ビルド環境で、または glibc-new を使用してバイナリをビルドすることもできます。 => glibc-古いクロスコンパイラ.

http://www.trevorpounds.com ブログ投稿 Linking to Older Versioned Symbols (glibc) によると、、同じ.symverを使用して有効である限り、任意のシンボルを強制的に古いシンボルにリンクすることができます 最初にバージョン管理されたシンボルを定義するために使用される疑似操作。次の例は、ブログ投稿からの抜粋です。

次の例では、glibc の realpath を使用していますが、古い 2.2.5 バージョンに対してリンクされていることを確認してください。

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

__asm__(".symver realpath,[email protected]_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;
}

セットアップ 1:専用の GCC を使用せずに独自の glibc をコンパイルして使用する

シンボルのバージョン管理ハックだけでは不可能に思えるので、さらに一歩進んで、自分で glibc をコンパイルしましょう。

このセットアップは、GCC ツールチェーン全体を再コンパイルするのではなく、glibc のみを再コンパイルするため、うまくいく可能性があり、迅速です。

ただし、crt1.o などのホスト C ランタイムオブジェクトを使用するため、信頼性が高くありません。、 crti.o 、および crtn.o glibc によって提供されます。これについては、https://sourceware.org/glibc/wiki/Testing/Builds?action=recall&rev=21#Compile_against_glibc_in_an_installed_location で言及されています。と驚くほど巧妙な方法です。

より信頼性の高いセットアップについては、以下のセットアップ 2 を参照してください。

glibc をビルドしてローカルにインストール:

export glibc_install="$(pwd)/glibc/build/install"

git clone git://sourceware.org/git/glibc.git
cd glibc
git checkout glibc-2.28
mkdir build
cd build
../configure --prefix "$glibc_install"
make -j `nproc`
make install -j `nproc`

セットアップ 1:ビルドを確認する

test_glibc.c

#define _GNU_SOURCE
#include <assert.h>
#include <gnu/libc-version.h>
#include <stdatomic.h>
#include <stdio.h>
#include <threads.h>

atomic_int acnt;
int cnt;

int f(void* thr_data) {
    for(int n = 0; n < 1000; ++n) {
        ++cnt;
        ++acnt;
    }
    return 0;
}

int main(int argc, char **argv) {
    /* Basic library version check. */
    printf("gnu_get_libc_version() = %s\n", gnu_get_libc_version());

    /* Exercise thrd_create from -pthread,
     * which is not present in glibc 2.27 in Ubuntu 18.04.
     * https://stackoverflow.com/questions/56810/how-do-i-start-threads-in-plain-c/52453291#52453291 */
    thrd_t thr[10];
    for(int n = 0; n < 10; ++n)
        thrd_create(&thr[n], f, NULL);
    for(int n = 0; n < 10; ++n)
        thrd_join(thr[n], NULL);
    printf("The atomic counter is %u\n", acnt);
    printf("The non-atomic counter is %u\n", cnt);
}

test_glibc.sh でコンパイルして実行 :

#!/usr/bin/env bash
set -eux
gcc \
  -L "${glibc_install}/lib" \
  -I "${glibc_install}/include" \
  -Wl,--rpath="${glibc_install}/lib" \
  -Wl,--dynamic-linker="${glibc_install}/lib/ld-linux-x86-64.so.2" \
  -std=c11 \
  -o test_glibc.out \
  -v \
  test_glibc.c \
  -pthread \
;
ldd ./test_glibc.out
./test_glibc.out

プログラムは期待されるものを出力します:

gnu_get_libc_version() = 2.28
The atomic counter is 10000
The non-atomic counter is 8674

https://sourceware.org/glibc/wiki/Testing/Builds?action=recall&rev=21#Compile_against_glibc_in_an_installed_location but --sysroot から採用されたコマンド失敗しました:

cannot find /home/ciro/glibc/build/install/lib/libc.so.6 inside /home/ciro/glibc/build/install

だから私はそれを削除しました.

ldd 出力は ldd であることを確認します構築したばかりのライブラリは、実際に期待どおりに使用されています:

+ ldd test_glibc.out
        linux-vdso.so.1 (0x00007ffe4bfd3000)
        libpthread.so.0 => /home/ciro/glibc/build/install/lib/libpthread.so.0 (0x00007fc12ed92000)
        libc.so.6 => /home/ciro/glibc/build/install/lib/libc.so.6 (0x00007fc12e9dc000)
        /home/ciro/glibc/build/install/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fc12f1b3000)

gcc コンパイルのデバッグ出力は、私のホストランタイムオブジェクトが使用されたことを示しています。含まれています：

COLLECT_GCC_OPTIONS=/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crt1.o

セットアップ 1:glibc の変更

それでは、glibc を次のように変更しましょう:

diff --git a/nptl/thrd_create.c b/nptl/thrd_create.c
index 113ba0d93e..b00f088abb 100644
--- a/nptl/thrd_create.c
+++ b/nptl/thrd_create.c
@@ -16,11 +16,14 @@
    License along with the GNU C Library; if not, see
    <http://www.gnu.org/licenses/>.  */

+#include <stdio.h>
+
 #include "thrd_priv.h"

 int
 thrd_create (thrd_t *thr, thrd_start_t func, void *arg)
 {
+  puts("hacked");
   _Static_assert (sizeof (thr) == sizeof (pthread_t),
                   "sizeof (thr) != sizeof (pthread_t)");

次に、glibc を再コンパイルして再インストールし、プログラムを再コンパイルして再実行します。

cd glibc/build
make -j `nproc`
make -j `nproc` install
./test_glibc.sh

hacked が表示されます予想通り数回印刷されました。

これにより、ホストのものではなく、コンパイルした glibc を実際に使用したことがさらに確認されます。

Ubuntu 18.04 でテスト済み。

セットアップ 2:crosstool-NG の元のセットアップ

これはセットアップ 1 の代替であり、これまでに達成した中で最も正しいセットアップです。crt1.o などの C ランタイムオブジェクトを含め、私が観察できる限り、すべてが正しいです。、 crti.o 、および crtn.o .

このセットアップでは、必要な glibc を使用する完全な専用 GCC ツールチェーンをコンパイルします。

この方法の唯一の欠点は、ビルドに時間がかかることです。しかし、それ以下のもので本番環境のセットアップを危険にさらすことはありません.

crosstool-NG は、GCC、glibc、binutils など、ソースからすべてをダウンロードしてコンパイルする一連のスクリプトです。

はい、GCC ビルドシステムは非常に悪いので、別のプロジェクトが必要です。

crosstool-NG は追加の -Wl なしで実行可能ファイルのビルドをサポートしていないため、このセットアップは完全ではありません。 GCC 自体を構築したので、これは奇妙に感じます。しかし、すべてうまくいっているように見えるので、これはただの不便です.

crosstool-NG を入手して設定します:

git clone https://github.com/crosstool-ng/crosstool-ng
cd crosstool-ng
git checkout a6580b8e8b55345a5a342b5bd96e42c83e640ac5
export CT_PREFIX="$(pwd)/.build/install"
export PATH="/usr/lib/ccache:${PATH}"
./bootstrap
./configure --enable-local
make -j `nproc`
./ct-ng x86_64-unknown-linux-gnu
./ct-ng menuconfig

私が見ることができる唯一の必須オプションは、正しいカーネルヘッダーを使用するためにホストカーネルのバージョンと一致させることです。ホストカーネルのバージョンを確認するには:

uname -a

4.15.0-34-generic

だから menuconfig 私は:

Operating System
- Version of linux

だから私は選択します：

4.14.71

これは、最初の同等または古いバージョンです。カーネルには下位互換性があるため、古いものである必要があります。

これでビルドできます:

env -u LD_LIBRARY_PATH time ./ct-ng build CT_JOBS=`nproc`

コンパイルが完了するまで約 30 分から 2 時間待ちます。

セットアップ 2:オプションの構成

.config ./ct-ng x86_64-unknown-linux-gnu で生成した持っています:

CT_GLIBC_V_2_27=y

それを変更するには、menuconfig でする:

C-library
Version of glibc

.config を保存します、ビルドを続行します。

または、独自の glibc ソースを使用する場合。最新の git から glibc を使用するには、次のように進めます:

Paths and misc options
- Try features marked as EXPERIMENTAL :true に設定
C-library
- Source of glibc
  - Custom location :そう言ってください
  - Custom location
    - Custom source location :glibc ソースを含むディレクトリを指定します

glibc は次のように複製されました:

git clone git://sourceware.org/git/glibc.git
cd glibc
git checkout glibc-2.28

セットアップ 2:テストしてみる

必要なツールチェーンを構築したら、以下でテストします:

#!/usr/bin/env bash
set -eux
install_dir="${CT_PREFIX}/x86_64-unknown-linux-gnu"
PATH="${PATH}:${install_dir}/bin" \
  x86_64-unknown-linux-gnu-gcc \
  -Wl,--dynamic-linker="${install_dir}/x86_64-unknown-linux-gnu/sysroot/lib/ld-linux-x86-64.so.2" \
  -Wl,--rpath="${install_dir}/x86_64-unknown-linux-gnu/sysroot/lib" \
  -v \
  -o test_glibc.out \
  test_glibc.c \
  -pthread \
;
ldd test_glibc.out
./test_glibc.out

正しいランタイムオブジェクトが使用されたことを除いて、すべてがセットアップ 1 と同じように機能しているように見えます:

COLLECT_GCC_OPTIONS=/home/ciro/crosstool-ng/.build/install/x86_64-unknown-linux-gnu/bin/../x86_64-unknown-linux-gnu/sysroot/usr/lib/../lib64/crt1.o

セットアップ 2:効率的な glibc 再コンパイルの試みに失敗しました

以下で説明するように、クロスツール NG では不可能のようです。

再構築するだけなら;

env -u LD_LIBRARY_PATH time ./ct-ng build CT_JOBS=`nproc`

カスタム glibc ソースの場所への変更は考慮されますが、すべてをゼロから構築するため、反復的な開発には使用できません。

その場合:

./ct-ng list-steps

ビルド手順の概要が分かりやすくなっています:

Available build steps, in order:
  - companion_tools_for_build
  - companion_libs_for_build
  - binutils_for_build
  - companion_tools_for_host
  - companion_libs_for_host
  - binutils_for_host
  - cc_core_pass_1
  - kernel_headers
  - libc_start_files
  - cc_core_pass_2
  - libc
  - cc_for_build
  - cc_for_host
  - libc_post_cc
  - companion_libs_for_target
  - binutils_for_target
  - debug
  - test_suite
  - finish
Use "<step>" as action to execute only that step.
Use "+<step>" as action to execute up to that step.
Use "<step>+" as action to execute from that step onward.

したがって、いくつかの GCC ステップと絡み合った glibc ステップがあることがわかります。最も顕著なのは libc_start_files です。 cc_core_pass_2 の前に来る、これはおそらく cc_core_pass_1 とともに最も高価なステップです .

1 つのステップだけをビルドするには、最初に .config で「中間ステップの保存」を設定する必要があります。初期ビルドのオプション:

Paths and misc options
- Debug crosstool-NG
  - Save intermediate steps

そして、あなたは試すことができます:

env -u LD_LIBRARY_PATH time ./ct-ng libc+ -j`nproc`

残念ながら、+ https://github.com/crosstool-ng/crosstool-ng/issues/1033#issuecomment-424877536 で述べられているように必要です

<ブロック引用>

ただし、中間ステップで再起動すると、インストールディレクトリがそのステップ中の状態にリセットされることに注意してください。つまり、再構築された libc がありますが、この libc で構築された最終的なコンパイラはありません (したがって、libstdc++ のようなコンパイラライブラリもありません)。

そして、基本的には再構築が遅すぎて開発に適していません.crosstool-NGにパッチを当てずにこれを克服する方法がわかりません.

さらに、libc から始まるステップは Custom source location からソースを再度コピーしているようには見えませんでした、さらにこのメソッドを使用できなくします。

ボーナス:stdlibc++

C++ 標準ライブラリにも興味がある場合のボーナス:GCC libstdc++ C++ 標準ライブラリソースを編集して再構築する方法は?