[英]How to compile my own glibc C standard library from source and use it?
我正在尝试编译我自己的 glibc。 我有一个目录glibc
,其中包含我从 Internet 下载的glibc
源代码。 我从那个目录输入mkdir ../build-glibc
。 现在从build-glibc
目录输入../glibc/configure
,它执行配置。 现在我不确定如何调用make
。 我不能从glibc
目录调用它,因为它没有配置集,我也不能从build-glibc
调用它,因为 makefile 不在该目录中。 我该如何解决这个问题?
此设置可能有效并且很快,因为它不会重新编译整个 GCC 工具链,而只是重新编译 glibc。
我在这个设置中遇到的唯一问题是我还没有找到一种很好的方法来使用我们的 glibc 提供的运行时对象,例如crt1.o
、 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`
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.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
现在让我们修改 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 而不是主机的 glibc。
在 Ubuntu 20.10 上测试。
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
大概是因为sysroot
被用于这个 GCC 提供的对象,我们在那个 sysroot 中没有,因为我们只构建了 glibc在https://stackoverflow.com/a/66634184/895245 ZeZNiQ 提供了一个可能正确的解决方法,通过传递:
-nostartfiles
其次是所有对象。 您只需要使用-nostartfiles
从完整命令中提取正确的对象并手动传递它们。
例如,在我的 amd64 机器上,使用的对象与他的 32 位命令不同,因此这有点繁琐。
参考书目:
这是设置 1 的替代方案,也是我迄今为止实现的最正确的设置:就我观察到的一切都是正确的,包括 C 运行时对象,例如crt1.o
、 crti.o
和crtn.o
.
在这个设置中,我们将编译一个完整的专用 GCC 工具链,它使用我们想要的 glibc。
这种方法的唯一缺点是构建需要更长的时间。 但我不会冒险用更少的东西进行生产设置。
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`
构建大约需要三十分钟到两个小时。
我能看到的唯一强制性配置选项是使其匹配您的主机内核版本以使用正确的内核头文件。 使用以下命令查找您的主机内核版本:
uname -a
这向我展示了:
4.15.0-34-generic
所以在menuconfig
我做:
Operating System
Version of linux
所以我选择:
4.14.71
这是第一个相同或更旧的版本。 它必须更旧,因为内核向后兼容。
我们使用./ct-ng x86_64-unknown-linux-gnu
生成的.config
有:
CT_GLIBC_V_2_27=y
要更改它,请在menuconfig
执行以下操作:
C-library
Version of glibc
保存.config
,然后继续构建。
或者,如果你想使用自己的glibc的来源,例如使用的glibc从最新的git,继续像这样:
Paths and misc options
Try features marked as EXPERIMENTAL
:设置为 trueC-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.
因此,我们看到 glibc 步骤与几个 GCC 步骤交织在一起,最显着的是libc_start_files
在cc_core_pass_2
之前,这可能是与cc_core_pass_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
复制Custom source location
,进一步使此方法无法使用。
如果您也对 C++ 标准库感兴趣,还有一个好处: 如何编辑和重新构建 GCC libstdc++ C++ 标准库源代码?
如果configure
脚本成功完成, Makefile
将存在于您的build-glibc
目录中。
如果在configure
过程中一切似乎都很顺利,但仍然没有Makefile
,那么您可能错过了一个特质:
在为 glibc 进行configure
,通常需要提供一个替代--prefix
,因为安装到默认位置 ( /usr/local
) 可能会削弱系统。 如果您不提供,则需要打开--disable-sanity-checks
。
如果也不是这种情况,请查找config.log
文件并阅读其内容。
添加到 Ciro 的早期答案/解决方案https://stackoverflow.com/a/52454710/4726668 :
@CiroSantilli 编辑您的答案会返回“建议的编辑队列已满”。 您在test_glibc.sh
脚本中调用的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 年 6 月 27 日使用 glibc 开发版本 2.33.9000(请参阅glibc/version.h
)在 Ubuntu 20.04 上进行测试。
您可以在此处手动获取 glibc 源代码: https : //www.gnu.org/software/libc/sources.html :
git clone https://sourceware.org/git/glibc.git
cd glibc
git checkout master
GitHub 上的第 3 方镜像: https : //github.com/bminor/glibc/tree/master/benchtests
也可以看看:
# 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
$(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"
关键词:如何构建和运行 glibc 及其基准测试,包括。 malloc 基准测试,来自源代码; 在 linux ubuntu 上从源代码构建 glibc
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.