编译时的错误.doc

cc1: error: invalid option `short-load-bytes'
内 核编译 2007-06-30 14:47:19 阅读63 评论0 字号：大中小
Q: 编译时提示错误 cc1: error: invalid option `short-load-bytes'
编译器：arm-linux- 3.4.1
    出现以下错误
cc1: error: invalid option `short-load-bytes'
make: *** [entry.o] 错误 1
    如果改用2.95.3则不会出现该问题。
    原因是高版本的编译器不支持-mshort-load-bytes选项，改为-malignment-traps即可。

我 也遇到类似的问题,我用的U-boot 1.1.6版本,用arm-linux-gcc-3.4.1编译出错,我的方法是下了一个最新的binutils,版本是2.17,覆盖了原来的arm- linux-gcc-3.4.1下的对应文件就通过了.
我也是编译出现的错误.看了你上面的解决办法.看来真是程序的bug,不过要全部用 源码编译,在源码的对应的行加上这些语句.呵呵,我上次编译源码 toolchain的时候,长期出问题.我的机子上有arm-elf- 和arm-linux-这两个交叉编译工具.首先是将CROSS_COMPLIE 设置成arm-linux然后编译,但出现上次的错误后,在把CROSS_COMPLIE设置成arm-elf- ,然后make,就可以生成u- boot

本文提到解决的办法，但是不知怎么用。
TIP: If you receive an absolute mass of errors reading “cc1: error: invalid
option short-load-bytes”, it is safe to edit ‘cpu/arm926ejs/config.mk’ and remove
the ‘mshort-load-bytes’ option.
TIP: If you receive a collection of errors ending with “relocation truncated to
fit: R_ARM_PLT32 __div0”, it is due to a bug in your toolchain. If you have
compiled from source, I shall provide a patch for binutils that I received from
Richard Woodruff:
———————- from CodeSourcery ——————————
— bfd/elf32-arm.h.orig 2004-04-22 22:11:15.000000000 -0400
+++ bfd/elf32-arm.h 2004-04-22 22:28:37.000000000 -0400
@@ -2229,6 +2229,8 elf32_arm_relocate_section (output_bfd,
case R_ARM_PC24:
case R_ARM_ABS32:
case R_ARM_THM_PC22:
+ case R_ARM_PLT32:
+
if (info->shared
&& (
(!info->symbolic && h->dynindx != -1)
@@ -2262,11 +2264,6 elf32_arm_relocate_section (output_bfd,
relocation = 0;
break;
- case R_ARM_PLT32:
- if (h->plt.offset != (bfd_vma)-1)
- relocation = 0;
- break;
-
default:
if (unresolved_reloc)
_bfd_error_handler
————————————– end patch ———————-
This should solve that problem.
Q: 如何更改uclinux下的passwd,group的路径
用uClibc时在 uClibc/include/paths.h 文件里。
Q: 写flash以后，system_reboot不起来
为 了提高写Flash的性能，Flash驱动中通常在一次写入后并不恢复Flash到读状态。这样，一次正常的写操作完成后，Flash将处于 “写”状态。如对于 Intel Flash，此时如果不能果Linux Flash驱动直接读取，则读到的实际上是写操作的状态信息。整个 reboot 的过程中，这个状态不会改变。reboot调用的最后结果是Linux结束运行，跳至Flash某地址开始新的启动过程，读出来的数据显然不会正确。 确认是否这种情况，可以这样简单验证一下：
1. 按上面的代码完成操作，直到重启失败；
2. 关闭电源，稍候重启开机，
3. 应该正常启动(应该正常启动)，进入Loader或linux后，确认Flash写入数据是否正确(应该正确)。
如 果是这种情况，修改方法有几种： + 不太严格的改法是，在上面的代码中加入一次读Flash的操作。（不严格是因为不能假设系统中只有这一个应用会写Flash）; + 有效但不太可取的方法：修改flash驱动，每次写操作完成后或关闭设备时，恢复Flash状态（降性能，不可靠）。 + 还可以在 inittab 中shutdown/reboot时调用一个程序完成读Flash的操作。 + 合理的改法是在MTD或可能的地方注册一个 reboot回调（register_reboot_notifier，参考 drivers/mtd/maps/nettel.c），在其中完成Flash复位的操作。这样，不论哪个应用写flash后，直接关电重启肯定没有问 题，掉电Flash就复位到读状态了；软启动，则会调用这个复位Flash的操作(没有写的情况下调一下也无关痛痒)。
简单分析一下最后一 种方法，在kernel/sys.c中有一个用于在reboot时调用（Hook）的函数：register_reboot_notifier 。读写Flash是通过具体某种Flash的驱动(如intel/AMD)来完成的，Flash驱动的上层是MTD。在我们通过MTD Mapping drivers 设计MTD的Mapping时，可以同时通过register_reboot_notifier向系统注册一个在reboot时运行的函数，以便在 reboot时复位Flash。这个函数的基本功能很简单，通过特定的Flash命令让Flash的块复位到读状态。参考核心目录中 drivers/mtd/maps/nettel.c 文件。
static int nettel_reboot_notifier(struct notifier_block *nb, unsigned long val, void *v)
{
struct cfi_private *cfi = nettel_intel_map.fldrv_priv;
unsigned long b;

/* Make sure all FLASH chips are put back into read mode */
for (b = 0; (b < nettel_intel_partitions[3].size); b += 0x100000) {
cfi_send_gen_cmd(0xff, 0x55, b, &nettel_intel_map, cfi,
cfi->device_type, NULL);
}
return(NOTIFY_OK);
}

static struct notifier_block nettel_notifier_block = {
nettel_reboot_notifier, NULL, 0
};

如果是因为examples的错误，可以直接注释掉它
在顶层目录的Makefile里找到examples，直接注释这行即可！