Jornada de compilação cruzada TBB

Ambiente e ferramentas

• Ambiente de compilação TBB:Ubuntu18.04
• Versão TBB: oneTBB-2019_U8
• Cadeia de ferramentas de compilação cruzada: gcc-linaro-6.2.1-2016.11-x86_64_aarch64-linux-gnu
• Ambiente de construção do projeto de teste: Windows7+ 交叉编译工具链+Qt5.9.3
• Ambiente operacional: Xilinx Zynq UltraScale+ MPSoC+Ubuntu

Compilar

Para a cadeia de ferramentas de compilação cruzada, faça o download da configuração você mesmo.

Antes de realizar as etapas a seguir, certifique-se de que os comandos a seguir possam visualizar a versão da cadeia de compilação, o que significa que a configuração da cadeia de compilação foi bem-sucedida:

aarch64-linux-gnu-gcc -v

aarch64-linux-gnu-g++ -v

TBBFornecido a nós makefile, se for compilado no ambiente de destino, ele detectará o ambiente com base na interação do script, e então configurará automaticamente as regras dos parâmetros de compilação de acordo com o ambiente, que é muito Reassuring.

Se for uma compilação cruzada, não há realmente nenhum problema como se imaginava ...

Nota : não precisa entender completamente tbbos parâmetros e regras do compilador, e como automaticamente dependendo do ambiente o compilador certo, e então reescrevê-lo makefile, será uma coisa difícil não agradar, especialmente por makefile初学者ele.

Podemos obter compilação cruzada por meio das seguintes instruções:

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

Q&A

parâmetro -m64

O primeiro encontro é uma cadeia de ferramentas de compilador cruzado aarch64-linux-gnu-g++sem -m64parâmetros

No meu ambiente, que é em parte oneTBB-2019_U8/build/linux.gcc.inc, basta fazer as seguintes alterações; claro, e eu relacionado ao ambiente, aqui são apenas para referência:

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 não encontrado

Por meio da sudo find / -name xxxx.so*pesquisa, encontramos xxxx.sopresentes na cadeia de ferramentas do compilador cruzado, então "copiamos" um caminho para o destino pode ser renomeado.

É importante notar que se uma cópia direta e renomear:

cp xxxxx.so xxxxx.so.x

Então, só haverá problemas no processo de compilação Too many open files

A abordagem correta deve ser estabelecer um link simbólico:

ln -s  xxxxx.so xxxxx.so.x

ld-linux-aarch64.so.1 não encontrado

Não encontrado na cadeia de compilação cruzada ld-linux-aarch64.so

Mas na verdade está na cadeia de ferramentas de compilação cruzada ld.so

O caminho específico é:
gcc-linaro-6.2.1-2016.11-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/libc/lib/ld-2.23.so

Da mesma forma, basta criar um link simbólico.

Em seguida, compilar com sucesso ~~

Mas ainda é muito cedo ...

referência indefinida a “__dlsym”

Ao escrever a demonstração de teste, verificou-se que a compilação falhou devido a:

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

Use nm -D libtbb.so.2para visualizar o libtbb.so.2conteúdo da biblioteca, a existência de um definido externamente ou indefinido __dlsym, como:

Então, onde essas funções são definidas?

Nem encontrado na __dlsymdefinição do arquivo de cabeçalho associado , apenas para localizar dlsyme assim por diante.

No final, não consegui encontrar ... Então, fui comparar os lbbtbb.so.2que podem ser usados ​​normalmente e descobri que eles não têm nada disso!

Então o problema está em compilar a biblioteca dinâmica, vou fazer de novo?

Usar 'dlopen' em aplicativos vinculados estaticamente requer em tempo de execução as bibliotecas compartilhadas da versão glibc usada para vinculação

Então percebi o aviso visto no título, então linux.gcc.incfaço as seguintes alterações em

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

Novamente usando compilado nm -D libtbb.so.2para visualizar o conteúdo de uma biblioteca dinâmica

teste

Demo Qt

Consulte o ambiente de desenvolvimento Daheng Zhixing Pallas_Qt_mingw32_SDK para construir

pró

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

a Principal

Conforme usado aqui, parallel_forverificar se a biblioteca dinâmica está disponível é um exemplo muito simples.

#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();
}

Teste de ambiente de destino

Conceder permissões

chmod 777 daheng_tbb_test

realizado

./daheng_tbb_test

Q&A

Os seguintes problemas ocorreram durante a execução:

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

O motivo do problema acima é que não podemos ser encontrados no ambiente de destino. tbb库O método que uso é:

• Coloque nossa biblioteca em um determinado caminho, por exemplo /usr/loca/lib

• E então modificar ld.so.confque a implementação vi /etc/ld.so.confserá incluída em nosso caminho

• Atualizar, executar ldconfig

Em seguida, execute-o novamente:

Fim

Finalmente acabou!