Viaje de compilación cruzada de TBB

Entorno y herramientas

• Entorno de compilación TBB:Ubuntu18.04
• Versión TBB: oneTBB-2019_U8
• Cadena de herramientas de compilación cruzada: gcc-linaro-6.2.1-2016.11-x86_64_aarch64-linux-gnu
• Entorno de construcción del proyecto de prueba: Windows7+ 交叉编译工具链+Qt5.9.3
• Entorno operativo: Xilinx Zynq UltraScale+ MPSoC+Ubuntu

Compilar

Para la cadena de herramientas de compilación cruzada, descargue la configuración usted mismo.

Antes de realizar los siguientes pasos, asegúrese de que los siguientes comandos puedan ver la versión de la cadena de compilación, lo que significa que la configuración de la cadena de compilación es correcta:

aarch64-linux-gnu-gcc -v

aarch64-linux-gnu-g++ -v

TBBSiempre makefileque se compile en el entorno de destino, detectará el entorno en función de la interacción del script y luego configurará automáticamente las reglas de los parámetros de compilación de acuerdo con el entorno, que es muy Reassuring.

Si se compila en forma cruzada, en realidad no hay ningún problema como se imagina ...

Nota : no es necesario comprender completamente tbblos parámetros y las reglas del compilador, y cómo automáticamente, dependiendo del entorno, el compilador correcto y luego reescribirlo makefile, será difícil no complacerlo, especialmente para makefile初学者él.

Podemos lograr la compilación cruzada mediante las siguientes instrucciones:

make CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++

Preguntas y respuestas

-m64 parámetro

El primer encuentro es una cadena de herramientas de compilador cruzado aarch64-linux-gnu-g++sin -m64parámetros

En mi entorno, que es en parte oneTBB-2019_U8/build/linux.gcc.inc, simplemente haga los siguientes cambios; por supuesto, y me relaciono con el entorno, aquí son solo para referencia:

ifeq (intel64,$(arch))
#    ITT_NOTIFY = -DDO_ITT_NOTIFY
#    CPLUS_FLAGS += -m64 $(RTM_KEY)
    CPLUS_FLAGS += $(RTM_KEY)
#    LIB_LINK_FLAGS += -m64
endif

xxxx.so.x no encontrado

A través de la sudo find / -name xxxx.so*búsqueda, encontramos xxxx.sopresente en la cadena de herramientas del compilador cruzado, luego "copiamos" una ruta al destino que se puede renombrar.

Vale la pena señalar que si una copia directa y cambia el nombre:

cp xxxxx.so xxxxx.so.x

Entonces solo habrá problemas en el proceso de compilación Too many open files

El enfoque correcto debería ser establecer un enlace flexible:

ln -s  xxxxx.so xxxxx.so.x

ld-linux-aarch64.so.1 no encontrado

No se encuentra en la cadena de compilación cruzada ld-linux-aarch64.so

Pero en realidad está en la cadena de herramientas de compilación cruzada ld.so

El camino específico es:
gcc-linaro-6.2.1-2016.11-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/libc/lib/ld-2.23.so

De la misma manera, simplemente cree un enlace suave.

Luego compila con éxito ~~

Pero todavía es demasiado pronto ...

referencia indefinida a "__dlsym"

Al escribir la demostración de prueba, se encontró que la compilación falló debido a:

undefined reference to "__dlsym"
undefined reference to "__dlopen"

Úselo nm -D libtbb.so.2para ver el libtbb.so.2contenido de la biblioteca, la existencia de un definido o indefinido externamente __dlsymcomo:

Entonces, ¿dónde se definen estas funciones?

Tampoco se encuentra en la __dlsymdefinición del archivo de encabezado asociado , solo para buscar dlsymy así sucesivamente.

Al final, no pude encontrarlo ... Así que fui a comparar los lbbtbb.so.2que se pueden usar normalmente, ¡ y descubrí que no tienen este material en absoluto!

Entonces el problema está en compilar la librería dinámica, ¿lo voy a hacer de nuevo?

El uso de 'dlopen' en aplicaciones vinculadas estáticamente requiere en tiempo de ejecución las bibliotecas compartidas de la versión glibc utilizada para vincular

Luego noté la advertencia que se ve en el título, por lo linux.gcc.incque realizo los siguientes cambios en

# PIC_KEY选项加上-ldl
PIC_KEY = -fPIC -ldl
# LIBDL不需要了，注释掉
# LIBDL = -ldl

Nuevamente usando compilado nm -D libtbb.so.2para ver el contenido de una biblioteca dinámica

prueba

Demostración de Qt

Consulte el entorno de desarrollo Daheng Zhixing Pallas_Qt_mingw32_SDK para construir

Pro

INCLUDEPATH += xxx\tbb\include
DEPENDPATH += xxx\tbb/lib
LIBS += -Lxxx\tbb/lib \
        -ltbb -ltbbmalloc -ltbbmalloc_proxy -ldl

principal

Como se usa en este documento, parallel_forverificar que la biblioteca dinámica está disponible, es un ejemplo muy simple.

#include <QCoreApplication>
#include <iostream>
#include <tbb/tbb.h>

using namespace tbb;
using namespace std;

int main(int argc, char *argv[])
{
    
    
    QCoreApplication a(argc, argv);

    tbb::parallel_for(1, 10, [](int i){
    
    std::cout << i << std::endl; });

    return a.exec();
}

Prueba de entorno objetivo

Otorgar permisos

chmod 777 daheng_tbb_test

llevado a cabo

./daheng_tbb_test

Preguntas y respuestas

Los siguientes problemas ocurrieron durante la ejecución:

error while loading shared libraries: libXXX.so.X: cannot open shared object file: No such file

La razón del problema anterior es que no podemos encontrarnos en el entorno de destino. tbb库El método que utilizo es:

• Ponga nuestra biblioteca en una ruta determinada, por ejemplo /usr/loca/lib

• Y luego modifique ld.so.confque la implementación vi /etc/ld.so.confse incluirá en nuestra ruta

• Actualizar, ejecutar ldconfig

Luego ejecútalo de nuevo:

Fin

¡Finalmente se acabó!