•  01-07-2019
  •  | 
  •  

Pregunta

Estoy construyendo un proyecto usando una cadena de herramientas GNU y todo funciona bien hasta que llego a vincularlo, donde el vinculador se queja de que falta o no puede encontrarlo. crti.o.Este no es uno de mis archivos objeto, parece estar relacionado con libc pero no puedo entender por qué necesitaría esto. crti.o, ¿no usaría un archivo de biblioteca, por ejemplo? libc.a?

Estoy compilando cruzadamente para la plataforma del brazo.Tengo el archivo en la cadena de herramientas, pero ¿cómo consigo que el vinculador lo incluya?

crti.o está en una de las rutas de búsqueda de 'bibliotecas', pero ¿debería buscar .o archivo en la ruta de la biblioteca?

¿La ruta de búsqueda es la misma para gcc y ld?

¿Fue útil?

Solución

crti.o es la biblioteca bootstrap, generalmente bastante pequeña.Por lo general, está vinculado estáticamente a su binario.Se debe encontrar en /usr/lib.

Si estás ejecutando una distribución binaria, tienden a poner todo el material del desarrollador en paquetes -dev (p. ej.libc6-dev) ya que no es necesario para ejecutar programas compilados, sólo para compilarlos.

No estás haciendo una compilación cruzada, ¿verdad?

Si está realizando una compilación cruzada, generalmente es un problema con la ruta de búsqueda de gcc que no coincide con el lugar donde está su crti.o.Debería haberse construido cuando lo estaba la cadena de herramientas.Lo primero que hay que comprobar es gcc -print-search-dirs y vea si crti.o está en alguno de esos caminos.

En realidad, la vinculación la realiza ld, pero gcc le transmite sus rutas.Probablemente la forma más rápida de descubrir qué está pasando es compilar un programa helloworld.c y rastrearlo para ver qué se pasa a ld y ver qué está pasando.

strace -v -o log -f -e trace=open,fork,execve gcc hello.c -o test

Abra el archivo de registro y busque crti.o, como puede ver mi compilador no cruzado:

10616 execve("/usr/bin/ld", ["/usr/bin/ld", "--eh-frame-hdr", "-m", "elf_x86_64", "--hash-style=both", "-dynamic-linker", "/lib64/ld-linux-x86-64.so.2", "-o"
, "test", "/usr/lib/gcc/x86_64-linux-gnu/4."..., "/usr/lib/gcc/x86_64-linux-gnu/4."..., "/usr/lib/gcc/x86_64-linux-gnu/4."..., "-L/usr/lib/gcc/x86_64-linux-g
nu/"..., "-L/usr/lib/gcc/x86_64-linux-gnu/"..., "-L/usr/lib/gcc/x86_64-linux-gnu/"..., "-L/lib/../lib", "-L/usr/lib/../lib", "-L/usr/lib/gcc/x86_64-linux-gnu
/"..., "/tmp/cc4rFJWD.o", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed", "-lc", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed", "/usr/lib/gcc/x86_
64-linux-gnu/4."..., "/usr/lib/gcc/x86_64-linux-gnu/4."...],  "COLLECT_GCC=gcc", "COLLECT_GCC_OPTIONS=\'-o\' \'test\' "..., "COMPILER_PATH=/usr/lib/gcc/x86_6"..., "LIBRARY_PATH=/usr/lib/gcc/x86_64"..., "CO
LLECT_NO_DEMANGLE="]) = 0
10616 open("/etc/ld.so.cache", O_RDONLY) = 3
10616 open("/usr/lib/libbfd-2.18.0.20080103.so", O_RDONLY) = 3
10616 open("/lib/libc.so.6", O_RDONLY)  = 3
10616 open("test", O_RDWR|O_CREAT|O_TRUNC, 0666) = 3
10616 open("/usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../lib/crt1.o", O_RDONLY) = 4
10616 open("/usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../lib/crti.o", O_RDONLY) = 5
10616 open("/usr/lib/gcc/x86_64-linux-gnu/4.2.3/crtbegin.o", O_RDONLY) = 6
10616 open("/tmp/cc4rFJWD.o", O_RDONLY) = 7

Si ve un montón de intentos de open(...crti.o) = -1 ENOENT, ld se está confundiendo y quieres ver de dónde viene el camino que está abriendo...

Otros consejos

Tuve el mismo problema durante la compilación cruzada.crti.o estaba en <sysroot>/usr/lib64 pero el vinculador no lo encontró.

Resulta que crear un directorio vacío <sysroot>/usr/lib solucionó el problema.Parece que el enlazador buscaría un camino. <sysroot>/usr/lib En primer lugar, y sólo si existe, se consideraría siquiera <sysroot>/usr/lib64.

¿Es esto un error en el vinculador?¿O este comportamiento está documentado en alguna parte?

En mi caso Linux Mint 18.0/Ubuntu 16.04, No tengo crti.o en absoluto:

$ find /usr/ -name crti*

No encuentro nada, así que instalo el paquete de desarrollador:

sudo apt-get install libc6-dev

Si encuentras algunas librerías leer aquí

OK, tuve que reinstalar la cadena de herramientas para que se incluyeran los archivos que faltaban.Parece extraño ya que debería haberlo encontrado en la ruta gcc.Supongo que el principal problema era que tenía aproximadamente 15 archivos crti.o diferentes en mi computadora y no señalaba el correcto.Todavía no funciona desde entonces, pero funciona ahora :-) Gracias por tu ayuda :-)

Tuve un problema similar con un compilador cruzado mal configurado.Lo solucioné así:

/home/rob/compiler/usr/bin/arm-linux-gcc --sysroot=/home/rob/compiler hello.c

Esto supone que /lib, /usr/include y demás existen en la ubicación señalada por la opción sysroot.Probablemente no sea así como se supone que se deben hacer las cosas, pero me sacó de problemas cuando necesitaba compilar un archivo C simple.

Tengo el mismo tipo de problema en una instalación predeterminada de Ubuntu 8.04.Tuve que obtener los encabezados/archivos del desarrollador de libc manualmente para que funcionara.

Esto me resolvió (compilación cruzada de pjsip para ARM):

export LDFLAGS='--sysroot=/home/me/<path-to-my-sysroot-parent>/sysroot'
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top