ldd: FATAL: Símbolo não resolvido “getopt_long” chamado de Executável - usando binários compilados para QNX no braço. Por quê?

Question

O Blackberry Playbook alcançou formalmente EOL (abril de 2014), mas eu instalei BGShell , BGSSH-SCP-SFTP e Term48 . Então eu tenho alguns shell parecidos com o ksh que parece com o GNU awk 3.1.5, sed 4.1.5, grep e python , com alguns outros elementos coreutils (mas não tr ) etc. Eu sou não raiz . Basicamente eu posso escrever no diretório Downloads ou no diretório $ HOME criado pelos aplicativos shell ( /accounts/1000/appdata/com.BGShell..blabla/data por exemplo) e não consigo executar tudo, mas geralmente consigo executar um script dentro as restrições acima mencionadas. A razão pela qual estou interessado é porque isso é QNX em córtex-A9 .:

QNX localhost 6.6.0 2014/03/19-01:28:41EDT OMAP4430_ES2.2_HS_Winchester_Rev:07 armle

Então eu compilei alguns binários tentando alavancar um projeto antigo ¹ . Muitas coisas precisam ser alteradas para que isso funcione, mas está configurado e é capaz de compilar a maioria dos destinos (incluindo gcc e coreutils-8.13 ) ² . Para resumir , eu compilei usando muitas variações diferentes de flags de configuração e versões mais antigas de algumas ferramentas de desenvolvimento para evitar alguns erros. Eu me decidi por algo como:

CFLAGS="-march=armv7-a -marm -fno-strict-aliasing -mtune=cortex-a9 -O2 -pipe -fomit-frame-pointer -mlittle-endian"
AUTOMAKE=automake-1.11: AUTOCONF=: AUTOHEADER=: AUTORECONF=: ACLOCAL=aclocal-1.11: MAKEINFO=makeinfo-4.13a

com o compilador cruzado arm-unknown-nto-qnx8.0.0eabi-gcc vinculado do 10.3 SDK que fica dentro do IDE momentics . Os binários resultantes são assim:

ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), BuildID[md5/uuid]=41442b23fecda2d1d7cc5d2c68432a33, not stripped

Mas todos eles são erros no tablet com esta mensagem:

ldd:FATAL: Unresolved symbol "getopt_long" called from Executable

Como eu recompilei muitas vezes usando diferentes sinalizadores e sempre recebo essa mensagem, estou pensando que talvez tenha desviado algumas outras coisas que o compilador nos scripts de compilação, pois ele foi orientado para um SDK anterior ... (isso está além do meu experiência, mas talvez algo sobre coleta de lixo ou seja, collect ?). Ou é a configuração exótica na plataforma de destino?

Um milhão de coisas poderiam ter dado errado aqui por causa da configuração (e inexperiência), mas estou procurando algumas pistas, então, há alguma coisa específica que eu deva entender de tal erro e como posso voltar atrás no problema em geral? / p>

^{1. Em suma, é um conjunto de scripts para buscar , patch , compilar , instalar para algum diretório, em seguida pacote que dir para um arquivo zip, em seguida, gerar um servidor ruby webrick bonito e você usará o tablet para baixar o script e o arquivo a partir dele (eu não o uso para o arquivo em 250mb, eu uso apenas algum host de arquivos da web e o navegador).}

^{2. Eu removi o ruby , o arquivo e o ruby para a configuração de nível superior.}

    

Answer 1

Trata-se de confundir dois SDK ¹ diferentes. getopt_long existe em QNX6.6 . Mas a versão libc no Playbook não tem isso , pois tem uma versão anterior de / proc . O erro nunca teria acontecido se eu tivesse instalado o SDK nativo do SO do Playbook v2.1.0 em vez de seguir cegamente o link no projeto, que instalará o Native SDK v10.3 com o IDE para BB10 . As informações do projeto são claras, mas o link não está vinculado ao SDK correto. Então, o que acabei fazendo foram os binários mais prováveis feitos para rodar no BB10, mas em um dispositivo que não tem exatamente a mesma infraestrutura. Curiosamente, algo como grep funcionaria, mas se recusou a responder a --version , ou seja, uma opção longa quando compilado com o BB SDK ...

Mas com o SDK adequado, não há problema. A maioria dos alvos foi recompilada ² . Isso tudo está acontecendo em Arch Linux x84_64 onde multilib repositórios foram habilitados (e muitos pacotes lib32 - foram extraídos). Este é o bloco de configuração build.sh que usei para gcc ³ :

CONFIGURE_CMD="$EXECDIR/gcc/configure
           --host=$PBHOSTARCH 
           --build=$PBBUILDARCH 
           --target=$PBTARGETARCH 
           --srcdir=$EXECDIR/gcc 
           --with-as=ntoarm-as 
           --with-ld=ntoarm-ld 
           --with-sysroot=$BBTOOLS/target/qnx6/ 
           --disable-werror 
           --prefix=$DESTDIR 
           --exec-prefix=$DESTDIR 
           --enable-cheaders=c 
           --enable-languages=c 
           --enable-threads=posix 
           --disable-nls
           --disable-libssp 
           --disable-tls 
           --disable-libstdcxx-pch
           --disable-newlib-supplied-syscalls
           --enable-libmudflap 
           --enable-__cxa_atexit 
           --with-gxx-include-dir=$BBTOOLS/target/qnx6/usr/include 
           --enable-shared
           --disable-subdir-texinfo
           --enable-cross-compile
           --enable-shared
           CC=$PBTARGETARCH-gcc
           CFLAGS='-march=armv7-a -marm -fno-strict-aliasing -mtune=cortex-a9 -O2 -pipe -fomit-frame-pointer -mlittle-endian'
           LDFLAGS='-Wl,-s '
           MAKEOPTS="-j5"
           AUTOMAKE=automake-1.11: AUTOCONF=: AUTOHEADER=: AUTORECONF=: ACLOCAL=aclocal-1.11: MAKEINFO=makeinfo-4.13a

Tanto o coreutils como o gcc trabalham e aliasse ls e grep com a opção --color :

Porfim,umshellfuncionalcomtrnomeuPlaybook,queofereceumavisãorarasobre < em> QNX !

^{1. Obrigado a Ryan Mansfield @ Foundry27 pelo heads up e @Emmanuel pela info!}

^{2. Destinos excluídos: file , man , ruby , findutils . O arquivo resultante era 80Mib e o servidor ruby webrick foi usado para implantar como pretendido.}

^{3. ... para ambos gcc e coreutils (adicionando aos padrões no último caso). Não está claro se todas as opções são necessárias ou mesmo recomendadas. Cada destino pode ser criado individualmente, iniciando o script build.sh no diretório bootstrap/target apropriado, por exemplo, bootstrap/gcc/build.sh . O ambiente de criação ( bbndk-env.sh ) deve ter sido originado uma vez pelo script top build.sh global usando a opção -b , ou seja, build.sh -b /path/to/bbndk-2.10 . As origens são buscadas nos diretórios work/target onde elas são construídas. Se uma compilação for bem-sucedida e nenhuma opção for fornecida (consulte lib.sh no diretório raiz do projeto), ela será incluída na estrutura de diretório pbhome que será compactada em um archive (que será implementado em seu diretório $ HOME no dispositivo rodando BGShell ). Observe também a referência a Darwin em lib.sh , que mudei para x86_64 no meu caso. Caso contrário, nada foi alterado a partir da configuração original do projeto, por exemplo, arm-unknown-nto-qnx6.5.0eabi (em oposição a usar a versão 8.0.0 com o SDK BB10.3, como no Q.). Por isso, é muito fácil compilar uma vez que eliminamos os poucos alvos problemáticos.}