问题标签 [codesourcery]

在命令窗口中，有一个错误！请看下文！

我正在使用 Sourcery_2011_09_ARM_EABI。但是在这个文件中没有头文件名 check.h

在文件 lwip_unittests.c 中：

我需要一个文件 check.h，我在哪里可以得到这个？

如果 check.h 将在文件 Sourcery_2011_09_ARM_EABI 中实现，它会工作吗？

或者我是否需要将 check.h 更改为 tree-check.h 或其他名称，即在 Sourcery_2011_09_ARM_EABI 中实现？

目前，我正在将我的业余项目升级为使用 ARM 而不是 Microchip 的 8 位微控制器。

但不幸的是我遇到了一些问题：

我不太了解编程方式的差异： - 编程到 ROM - 编程到 RAM（在我的情况下只有 32K）

我已经使用 IAR IDE 进行了一些“hello world”测试，其中编译/编程是使用我不担心的给定配置完成的。但我不喜欢 IAR IDE 和 IAR 编译器的 32K 限制，所以我决定建立一个新环境（参见下面的配置）。

设置好 Eclipse 环境后，使用 IAR 提供的示例，我设法将 ARM 编程到 RAM 中。但是当我想将 ARM 编程为 ROM 时，该程序似乎没有做任何事情。我使用了我相信对 ROM 或 RAM 做了某种映射的示例 makefile，我每次只需要定义其中一个。

我知道ROM是只读存储器，断电后不会为空，RAM速度更快，但每次都需要将程序下载到ARM。

我是否需要将我的程序分成 ROM 和 RAM 的一部分，或者我是否可以将所有内容编程到 ROM 中，以便 ARM 在通电时将代码重新映射到 RAM？

目前我正在使用以下配置：

• 代码源 GCC
• Eclipse C/C++
• Segger Jlink 程序员（GDB 服务器）
• CMSIS 或 LPCOpen 库（尚未完全工作）
• 恩智浦 LPC1766 Cortex M3
• Windows 8 64 位
• LPC1768 和 CMSIS 的 IAR 示例
• 来自 NXP 的示例：lpc17xx.cmsis.driver.library

有人可以帮助我了解 ROM 和 RAM 的不同用途，以及我应该如何设置我的编译器/makefile 以使用 ROM 和 RAM 内存。

最后，我希望能够将 ARM（我认为）编程到 ROM 中，这样我就可以关闭 ARM 而无需每次都重新编程。

我已经安装了 Motorola FX7500 Embedded SDK（带有 Sourcery CodeBench）并使用该 SDK（它是一个 Eclipse 版本）打开了一个示例项目。我导入了一个示例项目，没有错误，但是当我打开一个 .c 或 .h 文件时，我得到了很多错误，错误都是这样的：

• 无法解析符号“EOF”

• 符号“NULL”无法解析

• 类型“wchar_t”无法解析

它也给所有标准 C 库这样的错误：

未解决的包含：<stdio.h>

如何摆脱 Eclipse 中的这些错误？路径或类似的东西有问题吗？谢谢。

解决了。请参阅下面的解决方案部分。

我有一个问题，我的构建环境正在输出一个大的二进制文件，我希望有人可以帮助我再次移动。

我正在使用 STM32F105 处理器、Eclipse、FreeRTOS 和 CodeSourcery 编译器来尝试在此设备上运行一些 AHRS 评估代码。我有很多代码正在运行，但是在实现使用 malloc 分配内存的 eval 代码部分时遇到了问题。我必须为 _sbrk 添加一些代码才能编译它，现在我的二进制文件从 35K 增加到近 400MB。我认为这是一个链接器问题，因为 .out 文件（在 objcopy 之前）的大小大致相同。甚至从 objdump 输出的 .s 文件看起来也非常相似。

以下是一些（希望是）相关的点点滴滴：

生成文件：

添加此代码加上对 malloc 的调用导致二进制文件增长到近 400MB：

关于如何再次行动的任何想法？感谢您的任何帮助，您可以提供！

解决方案

通过 Notlikethat 的评论，我看到在构建过程中创建了另一段代码，但链接器脚本没有同名的段。链接器决定将此部分放入 RAM 中，而它本应将其放入 FLASH 中。由于它跨越 RAM 和 FLASH，bin 文件填充了它们之间的区域，导致二进制文件很大。将以下行添加到链接描述文件（在 FLASH 部分中），允许代码以正常大小再次构建。

新的完整链接描述文件如下所示：

谢谢您的帮助！

我一直在尝试用 xerces 3.1.1 专门编译 xalan-c 1.11。在 ubuntu 14.x 64 上使用来自 CodeSourcery 的 arm 交叉编译工具链 4.3.3。

xalan-c 有两个配置脚本。首先是通常的 ./configure 和第二个 ./runConfigure。

到目前为止，我一直在交叉编译其他库（例如 libusb-1.0/libusb-0.1/openssl）

但是这一次我相信我需要使用 ./runConfigure 否则我使用的一些环境变量没有设置（例如它如何处理消息）：

相反，我认为它等同于 ./configure 。./runConfigure 正在使用所有默认值（不幸的是，它无法识别的 c 和 c++ 编译器除外）

那我试试

它将无法执行

这是

Arm 拱门的二进制文件。我虽然 ./runConfigure 使用了 --host 选项并且知道这是一个交叉构建。或者这可能是 xalan-c 特有的东西？

我正在将 Xilinx Zynq 板从 CodeSourcery armel (gnueabi) 工具链（来自 Vivado 2015.2）迁移到 Linaro armhf，因此我们可以安装 Debian/Ubuntu armhf (gnueabihf)。

在尝试共享库时，我们从以下错误中得到下一个dlopen()错误：dlsym()dlerror()

如果在使用 CodeSourcery 工具链编译的软件正常工作时使用 Linaro 工具链，则会出现此问题。

我检查了两个库中报告的符号，它存在于两个库中：

似乎如果 controller.so 只包含 C 代码（没有 C++ 代码），它可以与 Linaro 一起正常工作。但差异可能与所使用的语言不同。

问候， Iztok Jeras

我在 Ubuntu 中使用 CodeSourcery Lite 4.7.3 环境进行交叉编译已经有一段时间了，并且正在过渡到基于 Windows 的环境。我正在使用相同版本的CodeSourcery构建，并使用“ GNU ARM Eclipse Build Tools ”。出于某种原因，当我在 Windows 系统中构建我在 Ubuntu 中拥有的项目时，当我将它们放在目标上时，它正在 ARM9/ 目录中搜索我构建的自定义共享库。

为了帮助理解运行时错误，我正在编译的是一个需要共享库的动态加载库。“targetapp”是预编译的，只有在windows环境中交叉编译“dynamic_module”时才会出现这个错误（是的，我在windows和linux中使用相同的编译命令，我只是更新了交叉- eclipse 项目中的编译器路径）。

目标是一个精简的、定制的带有busybox的vanilla linux系统。我只是不明白为什么这个相对路径被嵌入到我在 Windows 中编译的库中，而不是在 Ubuntu 中。

下面是 Ubuntu 交叉编译器和 Windows 交叉编译器的编译器版本输出。

Ubuntu G++ -v

视窗 G++ -v

编辑

我一直在为此苦苦挣扎。它最初是在 Windows 中使用 CMake 编译时出现的问题，CMake 脚本是由其他人构建的，但我拥有“动态模块”和“libSharedLibrary.so”。众所周知，“libSharedLibrary.so”适用于体系结构，并被加载到“/usr/lib”中以在目标上进行共享链接。我首先在 Ubuntu 下使用标准 makefile 编译了“dynamic_module”，然后在 Windows 中尝试使用 CMake，在 Windows 中使用标准 makefile，每个结果都相同。CMake 脚本最初引用了“ARM9”路径，我怀疑它弄乱了我的环境变量中的某些内容，或者可能是我的跨环境的其他组件。今天早上我将所有“ARM9”引用更改为“ARM7”，并且仍然有相同的相对路径被转储到“dynamic_module”中。我可以使用以下命令检查链接路径...

我还得到了详细的链接器命令，如下所示......

在修改后的环境（引用 ARM7 的 cmake 配置）中，我在任何地方都找不到这个指向“ARM9”的神秘链接。正如所评论的，问题可能是我的 libSharedLibrary.so 是在 linux 中交叉编译的。我现在要在 Windows 中交叉编译它，看看是否有任何变化。

所以，玩够了，ARM 引用来自我环境中的某个地方，即使它不在链接器命令中，它也会被拉入。给定命令，还有哪些其他信息可以告诉链接器执行此操作在上面的参考中发出？

更新

抱歉，更新这个问题花了这么长时间，如标记的答案中所述，在我下面的评论中，我能够确定一个解决方案。

在 stackoverflow 上发现的类似 SONAME 链接问题帮助我将问题与我在 CMAKE 文件中需要的问题隔离开来。在编译 libSharedLibrary.so 库时，我在 CMakeLists.txt 的最后一行添加了以下内容。

如果我没记错的话，这会阻止 SONAME 嵌入到库中（我相信其中包含我神秘的相对 ARM9 参考）。如果 libSharedLibrary.so 中没有 SONAME 引用，那么链接到 dynamic_module 的 libDynamicLibrary.so 将使用提供的名称，而不是它在其中编译的 SONAME。

再次感谢您的所有帮助，并再次感谢user1034749让我更接近解决方案。

为了为arm v9编译opencv 3.1.0，我在Ubuntu下使用交叉编译codesourcery arm-xilinx-linux-gnueabi-gcc的版本是“gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-50)”

参考，我尝试了两个不同的cmake文件来配置

cmake -DCMAKE_TOOLCHAIN_FILE=../opencv-3.1.0/platforms/linux/arm-gnueabi.toolchain.cmake ../opencv-3.1.0

cmake -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake ../opencv-3.1.0

这两个将导致以下错误：

有人可以帮我解决这个问题吗？非常感谢

编辑，

使用新版本（2013）的codesourcery后，我现在可以编译3.1.0了。谢谢

我的团队正在使用arm-none-eabi-gcc.exe (Sourcery CodeBench Lite 2012.09-63) 4.7.2从内部编译 C++ Visual Studio 2013。

我的同事最近升级了他们的机器。

旧电脑：

1. 视窗 7 x64
2. 16GB DDR3
3. 英特尔 3770K
4. 固态硬盘

新电脑：

1. 视窗 10 x64
2. 16GB DDR4
3. 英特尔 7700k
4. 固态硬盘

完全相同的 96 个文件集的编译时间是：

旧：60 secs
新：104 secs

尽管更快的 CPU 和更快的内存，编译变得更慢。

我在几位同事的计算机上观察到了这一点。

在这一点上，你会认为这是一个硬件问题，除了以下几点：我有了新的PC 配置Sep-2017，突然之间，没有任何硬件更改，我注意到Oct/Nov-2017我的编译速度急剧下降。

因此，我认为这是导致此问题的 Windows 更新。

问题

我如何才能明确推断出这种放缓的原因？

澄清 #1

我并不是说在 Windows 更新期间我的编译速度会变慢。我的意思是过去发生的某些 Windows 更新导致我的编译速度变慢。

更新#1

我正在使用一个空白.cpp文件并将其编译 100 次，但我仍然看到 Windows 7 PC 和 Windows 10 之间的时差完全相同。

我 99% 确定这是 Windows 的 gcc 中的一个“错误”。我从 ARM 网站安装了gcc ，我看到了同样的问题。

但是，当我cl.exe用来编译一个空白文件 100 次时，它只需要 5 秒，与 Windows 7 和旧版 Windows 10 上的 gcc 相同（Oct/Nov-ish）

我的测试脚本是：

我正在做一些关于 8086 实模式的工作。我习惯于在汇编中这样做，但想尝试一下 C 编译器。在我看来，编译器假定所有段寄存器都具有相同的值。我的情况并非如此。SS 为 0x4C0，而DS = ES = CS = 0x800。

因此，以下代码在编译时会生成代码，而不会考虑 SS <> DS 的事实。

[来源：这里]

编译后，作业产生：[完整来源：此处]

因为没有明确提到 SS，所以 DS 将由汇编程序假定。

如上所述，在我的情况下SS <> DS，因此 AL 现在具有来自错误地址的值。

移动铝，DS：[BX + SI - 0x11] <>移动铝，SS：[BX + SI - 0x11]

我尝试过的编译器：

1. GCC 版本 6.2.0 (Sourcery CodeBench Lite 2016.11-64)

链接器文件如下：

2. Bruce 的 C 编译器[此处使用 BCC 的完整源代码]

更新： 尝试了 SmallerC。这里再次编译器假设 SS = DS。

3. 较小的 C [来源]

结果在两个编译器中或多或少相同。从 stack 读取时，没有编译器明确指定 SS。问题是有一种方法可以通知编译器有关约束的信息，我是不是做错了什么。