Configuración 1: compile su propio glibc sin GCC dedicado y úselo
Dado que parece imposible hacerlo solo con trucos de control de versiones de símbolos, vayamos un paso más allá y compilemos glibc nosotros mismos.
Esta configuración podría funcionar y es rápida, ya que no recompila toda la cadena de herramientas de GCC, solo glibc.
Pero no es fiable, ya que utiliza anfitrión tiempo de ejecución C objetos tales como crt1.o, crti.oy crtn.oproporcionado por glibc. Esto se menciona en: https://sourceware.org/glibc/wiki/Testing/Builds?action=recall&rev=21#Compile_against_glibc_in_an_installed_location Esos objetos realizan una configuración temprana en la que se basa glibc, por lo que no me sorprendería si las cosas fallaran de manera maravillosa y formas asombrosamente sutiles.
Para una configuración más confiable, consulte Configuración 2 a continuación.
Compile glibc e instálelo localmente:
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`
Configuración 1: verificar la compilación
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.
* /programming/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);
}
Compilar y ejecutar con 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
El programa produce lo esperado:
gnu_get_libc_version() = 2.28
The atomic counter is 10000
The non-atomic counter is 8674
Comando adaptado de https://sourceware.org/glibc/wiki/Testing/Builds?action=recall&rev=21#Compile_against_glibc_in_an_installed_location pero --sysroothizo que fallara con:
cannot find /home/ciro/glibc/build/install/lib/libc.so.6 inside /home/ciro/glibc/build/install
así que lo quité.
lddLa salida confirma que las lddbibliotecas y que acabamos de crear se están utilizando como se esperaba:
+ 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)
La gccsalida de depuración de la compilación muestra que se usaron los objetos de tiempo de ejecución de mi host, lo cual es malo como se mencionó anteriormente, pero no sé cómo solucionarlo, por ejemplo, contiene:
COLLECT_GCC_OPTIONS=/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crt1.o
Configuración 1: modificar glibc
Ahora modifiquemos glibc con:
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)");
Luego recompile y reinstale glibc, y recompile y vuelva a ejecutar nuestro programa:
cd glibc/build
make -j `nproc`
make -j `nproc` install
./test_glibc.sh
y lo vemos hackedimpreso unas cuantas veces como se esperaba.
Esto confirma además que en realidad usamos el glibc que compilamos y no el host.
Probado en Ubuntu 18.04.
Configuración 2: configuración prístina de crosstool-NG
Esta es una alternativa a la configuración 1, y es la configuración más correcta que he logrado mucho: todo es correcto por lo que yo puedo observar, incluyendo el tiempo de ejecución C objetos tales como crt1.o, crti.o, y crtn.o.
En esta configuración, compilaremos una cadena de herramientas GCC dedicada que usa el glibc que queremos.
El único inconveniente de este método es que la construcción llevará más tiempo. Pero no arriesgaría una configuración de producción con nada menos.
crosstool-NG es un conjunto de scripts que descarga y compila todo desde la fuente para nosotros, incluidos GCC, glibc y binutils.
Sí, el sistema de compilación de GCC es tan malo que necesitamos un proyecto separado para eso.
Esta configuración solo no es perfecta porque crosstool-NG no admite la construcción de ejecutables sin -Wlindicadores adicionales , lo que se siente extraño ya que hemos construido GCC. Pero todo parece funcionar, así que esto es solo un inconveniente.
Obtenga crosstool-NG y configúrelo:
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
La única opción obligatoria que puedo ver es hacer que coincida con la versión del kernel de su host para usar los encabezados correctos del kernel. Encuentre la versión del kernel de su host con:
uname -a
que me muestra:
4.15.0-34-generic
así que menuconfigyo hago:
entonces selecciono:
4.14.71
que es la primera versión igual o anterior. Tiene que ser más antiguo ya que el kernel es compatible con versiones anteriores.
Ahora puedes construir con:
env -u LD_LIBRARY_PATH time ./ct-ng build CT_JOBS=`nproc`
y ahora espere entre treinta minutos y dos horas para la compilación.
Configuración 2: configuraciones opcionales
El .configque generamos con ./ct-ng x86_64-unknown-linux-gnutiene:
CT_GLIBC_V_2_27=y
Para cambiar eso, menuconfighaz lo siguiente:
C-libraryVersion of glibc
guarde el .configy continúe con la compilación.
O, si desea usar su propia fuente glibc, por ejemplo, para usar glibc desde el último git, proceda así :
Paths and misc options
Try features marked as EXPERIMENTAL: establecido en verdadero
C-library
Source of glibc
Custom location: decir que síCustom location
Custom source location: apunte a un directorio que contenga su fuente glibc
donde glibc se clonó como:
git clone git://sourceware.org/git/glibc.git
cd glibc
git checkout glibc-2.28
Configuración 2: pruébelo
Una vez que haya construido la cadena de herramientas que desea, pruébela con:
#!/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
Todo parece funcionar como en la Configuración 1, excepto que ahora se usaron los objetos de tiempo de ejecución correctos:
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
Configuración 2: intento fallido de recompilación de glibc eficiente
No parece posible con crosstool-NG, como se explica a continuación.
Si solo reconstruye;
env -u LD_LIBRARY_PATH time ./ct-ng build CT_JOBS=`nproc`
luego, se tienen en cuenta los cambios realizados en la ubicación de la fuente glibc personalizada, pero se construye todo desde cero, lo que lo hace inutilizable para el desarrollo iterativo.
Si lo hacemos:
./ct-ng list-steps
ofrece una buena descripción general de los pasos de compilación:
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.
por lo tanto, vemos que hay pasos de glibc entrelazados con varios pasos de GCC, el más notable libc_start_filesviene antes cc_core_pass_2, que es probablemente el paso más caro junto con cc_core_pass_1.
Para construir un solo paso, primero debe configurar la .configopción "Guardar pasos intermedios" en la compilación inicial:
y luego puedes probar:
env -u LD_LIBRARY_PATH time ./ct-ng libc+ -j`nproc`
pero desafortunadamente, el +requerido como se menciona en: https://github.com/crosstool-ng/crosstool-ng/issues/1033#issuecomment-424877536
Sin embargo, tenga en cuenta que reiniciar en un paso intermedio restablece el directorio de instalación al estado que tenía durante ese paso. Es decir, tendrá una libc reconstruida, pero ningún compilador final construido con esta libc (y, por lo tanto, tampoco bibliotecas de compilación como libstdc ++).
y básicamente todavía hace que la reconstrucción sea demasiado lenta para que sea factible para el desarrollo, y no veo cómo superar esto sin parchear crosstool-NG.
Además, a partir del libcpaso no parecía volver a copiar la fuente Custom source location, lo que hacía que este método fuera inutilizable.
Bono: stdlibc ++
Una ventaja si también está interesado en la biblioteca estándar de C ++: ¿Cómo editar y reconstruir la fuente de la biblioteca estándar de GCC libstdc ++ C ++?