编译时的错误.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-bytesmake: * 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: invalidoption short-load-bytes”, it is safe to edit cpu/arm926ejs/config.mk and removethe mshort-load-bytes option.TIP: If you receive a collection of errors ending with “relocation truncated tofit: R_ARM_PLT32 _div0”, it is due to a bug in your toolchain. If you havecompiled from source, I shall provide a patch for binutils that I received fromRichard 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 device_type, NULL); retu