自分のglibcをコンパイルしようとしています。インターネットからダウンロードしたソースコードをglibc含むディレクトリがあります。glibcそのディレクトリから、と入力しましたmkdir ../build-glibc。ここで、build-glibc入力したディレクトリから../glibc/configure、構成を実行しました。今、私はどのように呼び出すかわかりませんmake。glibc構成が設定されていないため、ディレクトリから呼び出すことはできませんbuild-glibc。また、makefileがそのディレクトリにないため、から呼び出すこともできません。この問題を解決するにはどうすればよいですか？
29414 次
4 に答える
30
セットアップ1：専用GCCなしのglibc
このセットアップは機能する可能性があり、GCCツールチェーン全体を再コンパイルするのではなく、glibcだけを再コンパイルするため、迅速です。
このセットアップで私が抱えている唯一の問題は、、、などのランタイムオブジェクトを使用するための優れた方法が見つからずcrt1.o、glibcによって提供されていることです。現在、ホストcrti.oオブジェクトを使用しています。crtn.oこれについては、https ：//sourceware.org/glibc/wiki/Testing/Builds？action = recall＆rev = 21＃Compile_against_glibc_in_an_installed_locationで説明されています。これらのオブジェクトは、glibcが依存する初期セットアップを実行するため、問題が発生しても驚かないでしょう。そして驚くほど微妙な方法。以下のこれを解決する試みを参照してください。
glibcをビルドし、ローカルにインストールします。
git clone git://sourceware.org/git/glibc.git
cd glibc
git checkout glibc-2.32
mkdir build
cd build
export glibc_install="$(pwd)/install"
../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
https://sourceware.org/glibc/wiki/Testing/Builds?action=recall&rev=21#Compile_against_glibc_in_an_installed_locationから適応されたコマンド
プログラムは期待されるものを出力します：
gnu_get_libc_version() = 2.32
The atomic counter is 10000
The non-atomic counter is 8674
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を実際に使用したことを確認します。
Ubuntu20.10でテスト済み。
セットアップ1：正しいcrt*オブジェクトの使用を試みます
https://sourceware.org/glibc/wiki/Testing/Builds?action=recall&rev=21#Compile_against_glibc_in_an_installed_location--sysrootは、gccコマンドに追加することを提案していますが、次のとおりです。
- ログによると、オブジェクトは実際には私たちのものに変更されません
/usr/bin/ld: cannot find libgcc_s.so.1おそらく、このGCCが提供するオブジェクトに使用されるため、コンパイルが失敗しsysrootます。これは、glibcをビルドしただけなので、そのsysrootにはありません。
https://stackoverflow.com/a/66634184/895245でZeZNiQは、次のように渡すことで、おそらく正しい回避策を提供します。
-nostartfiles
すべてのオブジェクトが続きます。を使用して完全なコマンドから正しいオブジェクトを抽出し、-nostartfilesそれらを手動で渡す必要があります。
たとえば、私のamd64マシンでは、使用されているオブジェクトが彼の32ビットコマンドとは異なっていたため、これは少し面倒です。
参考文献：
- GCCのデフォルトのcrti.oの検索ディレクトリを変更するにはどうすればよいですか？
- https://gcc.gnu.org/legacy-ml/gcc-help/2015-02/msg00016.html
- https://gcc.gnu.org/legacy-ml/gcc-help/2001-11/msg00029.html
セットアップ2：crosstool-NGの手付かずのセットアップ
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
env -u LD_LIBRARY_PATH time ./ct-ng build CT_JOBS=`nproc`
ビルドには約30分から2時間かかります。
私が見ることができる唯一の必須の構成オプションは、正しいカーネルヘッダーを使用するために、ホストカーネルのバージョンと一致させることです。次のコマンドでホストカーネルのバージョンを検索します。
uname -a
それは私を示しています：
4.15.0-34-generic
だからmenuconfig私はそうします：
Operating SystemVersion of linux
だから私は選択します：
4.14.71
これは最初の同等以上のバージョンです。カーネルには下位互換性があるため、古いものにする必要があります。
セットアップ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 optionsTry features marked as EXPERIMENTAL：trueに設定
C-librarySource of glibcCustom location： イエスと言うCustom locationCustom 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再コンパイルの試行に失敗しました
以下で説明するように、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 optionsDebug crosstool-NGSave 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 ++標準ライブラリソースを編集して再構築する方法は？
于 2018-09-22T08:00:46.587 に答える
8
スクリプトが正常に終了すると、はディレクトリMakefileに存在します。build-glibcconfigure
すべてが順調に進んでいて、configureそれでもうまくいかないMakefile場合は、おそらく特異性を見逃しているでしょう。
for glibcを実行している間、デフォルトの場所（）にインストールするとシステムが機能しなくなる可能性があるためconfigure、通常は代替手段を提供することが期待されます。提供しない場合は、をオンにする必要があります。--prefix/usr/local--disable-sanity-checks
そうでない場合は、config.logファイルを探してその内容を読んでください。
于 2012-05-02T11:36:20.130 に答える
2
Ciroの以前の回答/ソリューションに追加https://stackoverflow.com/a/52454710/4726668：
@CiroSantilli回答を編集すると、「推奨される編集キューがいっぱいです」と返されます。スクリプトで呼び出しているlddスクリプトはtest_glibc.sh、ホストのダイナミックリンカを指しています/home/ciro/glibc/build/install/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fc12f1b3000)。これを修正するには、でtest_glibc.sh、に変更lddし${glibc_install}/bin/lddます。crtこれには、ビルドされた*.oファイルもスクリプトに追加する必要があります。
-nostartfiles \
${glibc_install}/lib/crti.o \
${glibc_install}/lib/crtn.o \
${glibc_install}/lib/crt1.o \
私のGNU/Linux i386 / i686（32ビットx86 arch）マシンでは、次のように動作し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.so.2" \
-std=c11 \
-nostartfiles \
${glibc_install}/lib/crti.o \
${glibc_install}/lib/crtn.o \
${glibc_install}/lib/crt1.o \
-o test_glibc.out \
-v \
test_glibc.c \
-pthread \
;
${glibc_install}/bin/ldd ./test_glibc.out
./test_glibc.out
于 2021-03-15T07:53:59.880 に答える
1
glibc/version.h2021年6月27日にglibc開発バージョン2.33.9000（を参照）を使用してUbuntu20.04で最後にテストされました。
glibcをダウンロードしてビルドし、そのベンチマークを実行する方法
glibcのソースコードはここから手動で入手できます：https ：//www.gnu.org/software/libc/sources.html ：
git clone https://sourceware.org/git/glibc.git
cd glibc
git checkout master
GitHubのサードパーティミラー：https ：//github.com/bminor/glibc/tree/master/benchtests
参照：
glibcとそのベンチテストを手動で構築したい場合は、次のようにしてください。
# IMPORTANT: begin AT THE SAME DIRECTORY LEVEL as the `glibc` source code
# directory, NOT inside the `glibc` source code dir! In other words, if
# you are in the correct dir, running `ls` will show the `glibc` source
# code dir (that you just cloned) inside the dir you are in.
mkdir -p glibc-build
mkdir -p glibc-install
cd glibc-build
../glibc/configure --prefix="$(realpath "../glibc-install")"
time make -j8 # build with 8 threads (jobs); on a fast laptop this takes ~3 min.
time make install # (optional: install to the `glibc-install` dir you created)
# Build the benchtests (everything inside the `glibc/benchtests` dir) too;
# see the makefile 'glibc/benchtests/Makefile' for more build commands.
time make bench-build -j8
# Now you have this executable file you can use for malloc speed tests, for instance!:
# ../glibc-build/benchtests/bench-malloc-thread
# To build **and run** all glibc benchtests, do:
time make bench
参照：
- https://www.gnu.org/software/libc/manual/html_node/Configure-and-compiling.html
- https://kazoo.ga/a-simple-tool-to-test-malloc-performance/
- https://github.com/f18m/malloc-benchmarks/blob/master/Makefile#L122-L129：このmakefileターゲットを研究することで、これについて多くを学びました。
$(glibc_install_dir)/lib/libc.so.6: @echo "Building GNU libc... go get a cup of coffee... this will take time!" mkdir -p $(glibc_build_dir) cd $(glibc_build_dir) && \ ../glibc/configure --prefix=$(glibc_install_dir) && \ make $(parallel_flags) && \ make install [ -x $(glibc_build_dir)/benchtests/bench-malloc-thread ] && echo "GNU libc benchmarking utility is ready!" || echo "Cannot find GNU libc benchmarking utility! Cannot collect benchmark results" - ソースから自分のglibcC標準ライブラリをコンパイルして使用するにはどうすればよいですか？
キーワード：glibcとそのベンチテストを構築して実行する方法。ソースからのmallocベンチテスト。Linuxubuntuのソースからglibcをビルドする
于 2021-06-27T17:44:23.767 に答える