☰

ldd:FATAL: 从可执行文件调用未解析的符号“getopt_long” - 在arm上使用QNX的编译二进制文件。为什么？

tag-icon • tag-icon compiling arm qnx
ldd:FATAL: 从可执行文件调用未解析的符号“getopt_long” - 在arm上使用QNX的编译二进制文件。为什么？

这黑莓剧本已正式达到停产（2014 年 4 月），但我已经安装了BGShell,BGSSH-SCP-SFTP， 和术语48在上面。所以我有一些克什- 就像 GNU awk3.1.5、4.1.5sed和grep等shellpython一样一些其他核心工具元素（但没有tr）等。我是不是根。基本上我可以在Downloads目录中或$HOME由外壳应用程序创建的目录（/accounts/1000/appdata/com.BGShell..blabla/data例如），我无法执行所有内容，但我通常可以在上述限制内运行脚本。我感兴趣的原因是因为这是QNX在皮质-A9.:

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

所以我通过尝试利用旧项目1 .要使其工作，需要更改许多事情，但它已设置并且能够编译大多数目标（包括gcc和coreutils-8.13）2。到总结，我使用许多不同的配置标志变体和一些开发工具的旧版本进行编译，以避免一些错误。我已经解决了类似的事情：

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

与arm-unknown-nto-qnx8.0.0eabi-gcc交叉编译器链接10.3 软件开发工具包它位于里面动量IDE。生成的二进制文件如下所示：

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

但他们中的每一个都在平板电脑上出现错误，并显示以下消息：

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

由于我使用不同的标志多次重新编译并且总是收到该消息，我想我可能在构建脚本中错误链接了除编译器之外的其他一些东西，因为它是针对以前的 SDK 的......（这超出了我的专业知识，但也许关于垃圾收集的事情，即collect？）。或者是目标平台上的奇异配置？

由于设置（和缺乏经验），这里可能有一百万件事出了问题，但我正在寻找一些线索，那么我是否应该从这样的错误中理解任何具体的事情，以及我通常如何回溯问题？

1. 总而言之，它是一堆脚本拿来,修补,编译,安装然后到某个目录捆该目录到一个 zip 文件然后生成一个可爱的鲁比·韦伯里克服务器，您使用平板电脑下载脚本和存档（我不使用它来存档 250mb，我只使用一些 Web 文件主机和浏览器）。

2.我已经删除了红宝石,文件， 和红宝石来自顶级构建配置的目标。

答案1

这是关于混淆两个不同的 SDK 1 的问题。获取选择长 存在在QNX6.6。但libc上面的版本剧本 没有那个因为它有一个早期版本/进程。如果我安装了该错误就不会发生Playbook 操作系统本机 SDK v2.1.0而不是盲目跟风关联在项目中，这将安装原生 SDK v10.3与 2.1集成开发环境为了BB10。该项目的信息很清楚，但该链接未链接到正确的 SDK。因此，我最终得到的很可能是在 BB10 上运行的二进制文件，但其基础设施并不完全相同。有趣的是，当使用 BB SDK 编译时，类似的东西grep可以工作，但拒绝回答ie a long option...--version

但使用正确的 SDK 就没有问题。大多数目标已重新编译2。这一切都发生在Arch Linux x84_64在哪里多库存储库已启用（并且许多lib32-拉出的包裹）。这是build.sh我用于gcc3 的配置块：

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

coreutils和都gcc可以工作，我有别名ls和grep选项--color：

在此输入图像描述

最后一个功能性的tr外壳剧本，这提供了一个罕见的见解QNX！

1. 感谢瑞安·曼斯菲尔德@Foundry27 敬请注意@伊曼纽尔获取信息！

2. 排除目标：file、man、ruby、findutils。生成的存档大小为 80Mib，ruby 韦伯里克服务器用于按预期进行部署。

3. ...对于两者gcc和coreutils实际上（在后一种情况下添加默认值）。目前尚不清楚所有选项都是必需的还是推荐的。每个目标都可以通过build.sh在适当的目录中启动脚本来单独构建，bootstrap/target即bootstrap/gcc/build.sh。构建环境( bbndk-env.sh) 必须已由全局顶级 build.sh 脚本使用-b选项 ie获取一次build.sh -b /path/to/bbndk-2.10。源代码被提取到work/target构建它们的目录中。如果构建成功并且没有给出任何选项（请参阅lib.sh项目根目录），它将添加到pbhome目录结构中，该目录结构将被压缩到存档中（该存档将部署到运行设备上的 $HOME 目录）BGShell）。另请注意参考达尔文我在lib.sh其中更改为 x86_64就我而言。否则，原始项目配置没有任何改变arm-unknown-nto-qnx6.5.0eabi（与 Q 中使用 8.0.0 版本和 BB10.3 SDK 不同）。因此，一旦我们清除了少数有问题的目标，编译就非常容易了。

相关内容