how create compiler makefile linker

create - makefile structure



Falta el archivo crti.o (7)

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

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

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

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


De acuerdo, tuve que volver a instalar la cadena de herramientas, para que los archivos faltados se incluyeran. Parece extraño, ya que debería haberlo encontrado en la ruta gcc. El problema principal, supongo, es que tenía 15 o más archivos crti.o diferentes en mi computadora y no apuntaba a la correcta. Todavía no funciona, pero funciona ahora :-) Gracias por su ayuda :-)


En mi caso Linux Mint 18.0/Ubuntu 16.04 , no tengo ningún crti.o :

$ find /usr/ -name crti*

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

sudo apt-get install libc6-dev

Si encuentras algunas libs, lee aquí


Esto resuelto para mí (compilación cruzada de pjsip para ARM):

export LDFLAGS=''--sysroot=/home/me/<path-to-my-sysroot-parent>/sysroot''


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


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

Resulta que la creación de un directorio vacío <sysroot> / usr / lib solucionó el problema. Parece que el enlazador buscaría una ruta <sysroot> / usr / lib primero, y solo si existe consideraría <sysroot> / usr / lib64 .

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


Tuve un problema similar con un compilador cruzado mal configurado. Lo hice de esta manera:

/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 apuntada por la opción sysroot. Probablemente no sea así como se supone que deben hacerse las cosas, pero me sacó de problemas cuando necesité compilar un simple archivo C.


crti.o es la biblioteca de bootstrap, generalmente bastante pequeña. Por lo general, está vinculado de forma estática con tu binario. Se debe encontrar en /usr/lib .

Si está ejecutando una distribución binaria, tienden a poner todo el material de desarrollo en paquetes -dev (por ejemplo, libc6-dev) ya que no es necesario para ejecutar programas compilados, solo para compilarlos.

No estás compilando de forma cruzada, ¿verdad?

Si compilas de forma cruzada, suele ser un problema con la ruta de búsqueda de gcc que no coincida con tu crti.o. Debería haberse construido cuando la cadena de herramientas estaba. Lo primero que debes comprobar es gcc -print-search-dirs y ver si crti.o está en alguna de esas rutas.

La vinculación se realiza realmente por ld, pero tiene sus rutas transmitidas por gcc. Probablemente la manera más rápida de descubrir qué está pasando es compilar un programa helloworld.c y buscarlo para ver qué 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 confunde y quiere ver de dónde viene la ruta de acceso que está abriendo ...