gcc - una - Error de compilación ARM, VFP registrado utilizado por archivo ejecutable, no objeto

el archivo de objeto se ha compilado en una version diferente de foxpro (10)

He tenido este problema en los últimos días y no entiendo qué está pasando realmente aquí o cuál es el problema.

Tengo un archivo MAKE con estas banderas:

CC = arm-linux-gnueabihf-gcc-4.6 FLAGS = -O3 -march=armv7-a -mtune=cortex-a9 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -std=gnu99

Tengo una biblioteca en un archivo .a, que tiene algunos archivos de objetos, todo lo que tengo que hacer es vincularlos con mi ejecutable. Conozco los prototipos y todo eso, lo único que se queja es lo siguiente:

/usr/bin/ld: error: *EXECUTABLE* uses VFP register arguments, *OBJECTFILE* does not /usr/bin/ld: failed to merge target specific data of file *OBJECTFILE*

Cuando no uso el -flop-abi = softfp, aparece otro error relacionado con los registros de coma flotante.

¿Alguien tiene alguna idea de lo que está causando esto, y qué puedo hacer para solucionarlo, como hacerlo para que mi ejecutable no use argumentos de Registro de coma flotante virtual?

x@x:~/Desktop/perf_test$ make arm-linux-gnueabihf-gcc-4.6 -c -O3 -march=armv7-a -mtune=cortex-a9 -mfpu=neon -ftree-vectorize -std=gnu99 -mfloat-abi=softfp perf_test.c ../baseline/util.c arm-linux-gnueabihf-gcc-4.6 -o perf_test perf_test.o util.o ../baseline/lib.a /usr/bin/ld: error: perf_test uses VFP register arguments, perf_test.o does not /usr/bin/ld: failed to merge target specific data of file perf_test.o /usr/bin/ld: error: perf_test uses VFP register arguments, util.o does not /usr/bin/ld: failed to merge target specific data of file util.o /usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(a.o) does not /usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(a.o) /usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(b.o) does not /usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(b.o) /usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(c.o) does not /usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(c.o) /usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(d.o) does not /usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(d.o) /usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(e.o) does not /usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(e.o) /usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(f.o) does not /usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(f.o) collect2: ld returned 1 exit status make: *** [perf_test] Error 1

En mi caso particular -g -march=armv7-a -mfloat-abi=hard -mfpu=neon -marm -mthumb-interwork funcionó.

En mi caso, CFLAGS = -O0 -g -Wall -I. -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=soft CFLAGS = -O0 -g -Wall -I. -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=soft ha ayudado. Como puede ver, lo usé para mi stm32f407.

Encontré el problema con Atollic para ARM en STM32F4 (supongo que se aplica a todos los STM32 con FPU).

Usar el punto flotante SW no funcionó bien para mí (compilando así correctamente).

Cuando STM32cubeMX genera código para TrueStudio (Atollic), no establece una unidad FPU en configuraciones de compilación C / C ++ (no está seguro sobre el código generado para otros IDEs).

Establezca una FPU en "Destino" para (bajo las configuraciones de construcción de Propiedades del proyecto):

Ensamblador
C compilador
C Linker

Entonces usted tiene la opción de mezclar HW / SW fp o usar HW.

Las líneas de comando generadas se agregan con esto para el objetivo deseado:

-mfloat-abi=hard -mfpu=fpv4-sp-d16

arm atollic

Esta respuesta puede aparecer en la superficie sin relación, pero hay una causa indirecta de este mensaje de error.

En primer lugar, el mensaje de error "Utiliza el registro de VFP ..." se debe directamente a la mezcla de mfloat-abi = soft y mfloat-abi = hard options dentro de su compilación. Esta configuración debe ser coherente para todos los objetos que se van a vincular. Este hecho está bien cubierto en las otras respuestas a esta pregunta.

La causa indirecta de este error puede deberse a que el editor de Eclipse se confunde por un error autoinfligido en el archivo ".cproject" del proyecto. El editor de Eclipse resconvierte con frecuencia los enlaces de archivos y, a veces se rompe cuando realiza cambios en las estructuras de directorios o ubicaciones de archivos. Esto también puede afectar la configuración de ruta a su compilador gcc, y solo para un subconjunto de los archivos de su proyecto. Aunque todavía no estoy seguro de qué causa exactamente esta falla, al reemplazar el archivo .cproject con una copia de respaldo corrigí este problema. En mi caso noté errores de .java.null.pointer después de agregar una ruta de directorio de inclusión y empecé a recibir los mensajes de "error de registro de VFP" de la nada. En el registro de compilación noté que se estaba utilizando una ruta diferente al compilador gcc para algunas de mis fuentes que eran locales para el espacio de trabajo, pero no todas? Los dos compiladores de gcc usaban diferentes configuraciones de flotación por razones desconocidas, de ahí el error de registro de VFP.

Comparé la configuración del proyecto .c con una copia anterior y observé las diferencias en las entradas de las fuentes que causaban el problema, incluso aunque la anulación de la configuración del proyecto estuviera deshabilitada. Al reemplazar el archivo .cproject con la versión anterior, el problema desapareció, y dejo esta respuesta como un recordatorio de lo que sucedió.

Estaba enfrentando el mismo problema. Estaba intentando construir la aplicación de Linux para Cyclone V FPGA-SoC. Enfrenté el problema de la siguiente manera:

Error: <application_name> uses VFP register arguments, main.o does not

Estaba usando el toolchain arm-linux-gnueabihf-g++ provisto por la herramienta de diseño de software integrada de altera.

Se resuelve exportando: mfloat-abi=hard to flags, luego arm-linux-gnueabihf-g++ compila sin errores. También incluya las banderas en CC y LD .

Esto es una suposición, pero es posible que también deba suministrar algunos o todos los conmutadores relacionados con coma flotante para la etapa de enlace.

He encontrado en un brazo un sistema de hardfloat donde se mezclaron glubc binutils y gcc, usando gcc da el mismo error.

Se resuelve exportando -mfloat-abi=hard a flags, luego gcc compila sin errores.

Su triplete objetivo indica que su compilador está configurado para el ABI de flotación rígida . Esto significa que la biblioteca libgcc también será hardfp. El mensaje de error indica que al menos parte de su sistema está utilizando ABI de flotación blanda .

Si el compilador tiene habilitado multilib (puede ver con -print-multi-lib ) entonces puede usar -mfloat-abi=softfp , pero si no, esa opción no le ayudará mucho: gcc generará felizmente el código softfp, pero entonces no habrá una libgcc compatible para enlazar.

Básicamente, hardfp y softfp simplemente no son compatibles. Necesita configurar todo su sistema configurado de una forma u otra.

EDITAR: algunas distribuciones son, o serán, "multiarcas". Si tiene uno de esos, entonces es posible instalar ambos ABI a la vez, pero eso se hace duplicando todo: los problemas de compatibilidad aún existen.

También el error se puede resolver agregando varios indicadores, como -marm -mthumb-interwork . Fue útil para mí evitar este mismo error.

Utilice las mismas opciones de compilación para vincular también.

Ejemplo:

gcc -mfloat-abi=hard fpu=neon -c -o test.cpp test.o gcc -mfloat-abi=hard fpu=neon -c test1.cpp test1.o gcc test.o test1.o mfloat-abi=hard fpu=neon HardTest