glibcがシンボルのバージョン管理を使用しているという点で正しいです。興味がある場合は、glibc 2.1で導入されたシンボルバージョン管理の実装についてここで説明します。これは、ここで説明するSunのシンボルバージョン管理スキームの拡張です。
1つのオプションは、バイナリを静的にリンクすることです。これはおそらく最も簡単なオプションです。
chrootビルド環境で、またはglibc- new =>glibc - oldクロスコンパイラを使用してバイナリをビルドすることもできます。
http://www.trevorpounds.comのブログ投稿LinkingtoOlder Versioned Symbols（glibc）によると、同じ.symver疑似を使用して有効である限り、任意のシンボルを古いシンボルに対して強制的にリンクさせることができます。そもそもバージョン管理されたシンボルを定義するために使用されるop。次の例は、ブログ投稿から抜粋したものです。
次の例では、glibcのrealpathを使用していますが、古い2.2.5バージョンに対してリンクされていることを確認してください。
#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;
}
シンボルバージョン管理のハックだけでは実行できないように思われるので、さらに一歩進んでglibcを自分でコンパイルしてみましょう。
このセットアップは機能する可能性があり、GCCツールチェーン全体を再コンパイルするのではなく、glibcだけを再コンパイルするため、迅速です。
crt1.oただし、、、などのホストCランタイムオブジェクトを使用し、glibcによって提供されるためcrti.o、信頼性は高くありません。crtn.oこれについては、https ：//sourceware.org/glibc/wiki/Testing/Builds？action = recall＆rev = 21＃Compile_against_glibc_in_an_installed_locationで説明されています。これらのオブジェクトは、glibcが依存する初期セットアップを実行するため、問題が発生しても驚かないでしょう。そして驚くほど微妙な方法。
より信頼性の高いセットアップについては、以下のセットアップ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`
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から適応されましたが--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
それでは、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を実際に使用したことを確認します。
Ubuntu18.04でテスト済み。
crt1.oこれはセットアップ1の代替であり、これまでに達成した中で最も正しいセットアップです。、、、などの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時間待ちます。
.configで生成したものは次の./ct-ng x86_64-unknown-linux-gnuとおりです。
CT_GLIBC_V_2_27=y
これを変更するには、次のようにしmenuconfigます。
C-libraryVersion 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
必要なツールチェーンを構築したら、次のコマンドでテストします。
#!/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
以下で説明するように、crosstool-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ます。
.config1つのステップだけをビルドするには、最初に最初のビルドのオプションで[中間ステップを保存]を設定する必要があります。
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、このメソッドはさらに使用できなくなりました。
C ++標準ライブラリにも興味がある場合のボーナス：GCC libstdc ++ C ++標準ライブラリソースを編集して再構築する方法は？
-staticでリンクします。-staticを使用してリンクすると、リンカーは実行可能ファイル内にライブラリを埋め込むため、実行可能ファイルは大きくなりますが、プログラムはシステムのライブラリではなく独自のライブラリを使用するため、古いバージョンのglibcを使用するシステムで実行できます。 。
私の意見では、最も怠惰な解決策（特に最新の最先端のC / C ++機能や最新のコンパイラ機能に依存していない場合）はまだ言及されていないので、ここにあります：
まだサポートしたい最も古いGLIBCを使用してシステムを構築するだけです。
これは、chroot、KVM / Virtualbox、dockerなどのテクノロジーを使用して、このような古いディストリビューションをPCで直接使用したくない場合でも、実際には非常に簡単に実行できます。詳細には、ソフトウェアのポータブルバイナリを最大限に作成するには、次の手順に従うことをお勧めします。
サンドボックス/仮想化/...の毒を選び、それを使用して仮想の古いUbuntu LTSを取得し、デフォルトでそこにあるgcc /g++でコンパイルします。これにより、GLIBCはその環境で使用可能なものに自動的に制限されます。
基本的なライブラリ以外の外部ライブラリに依存することは避けてください。たとえば、glibc、libGL、libxcb / X11 / waylandのもの、libasound / libpulseaudio、使用する場合はGTK +などの地上レベルのシステムを動的にリンクする必要がありますが、それ以外の場合は静的にリンクすることが望ましいです。可能であれば、libs/それらを一緒に出荷します。特に、イメージローダー、マルチメディアデコーダーなどのほとんどの自己完結型ライブラリは、静的に出荷した場合、他のディストリビューションでの破損が少なくなる可能性があります（破損は、別のメジャーバージョンのどこかにのみ存在する場合などに発生する可能性があります）。
このアプローチでは、手動でシンボルを微調整することなく、完全に静的なバイナリを実行せずに（glibcがそれを嫌うため、より複雑なプログラムでは機能しなくなり、ライセンスの問題が発生する可能性があります）、設定せずに、古いGLIBC互換のバイナリを取得できます。カスタムツールチェーン、カスタムglibcコピー、その他何でも。
このリポジトリ：
https ：//github.com/wheybags/glibc_version_header
受け入れられた回答に記載されている詳細を処理するヘッダーファイルを提供します。
基本的に：
-include /path/to/header.hコンパイラフラグに追加 するリンカーフラグも追加します。
-static-libgcc -static-libstdc++ -pthread
ただし、これらはアプリの要件によって異なります。