5

I'm trying to compile AODV for ARM linux. I use a SabreLite as a board with kernel version 3.0.35_4.1.0. It's worth mention that i'm using openembedded to create my Linux Distribution for my board. The AODV source code (http://sourceforge.net/projects/aodvuu/) has a README file which give some indications on how to install it on ARM as stated a bit here. (http://w3.antd.nist.gov/wctg/aodv_kernel/kaodv_arm.html).

I was able to upgrade the makefile in order to be used with post 2.6 kernel version ( as stated above, i have the 3.0.35_4.1.0 kernel version). So, basically, what i am trying to do is that i have to create a module (let's say file.ko) and then load it into the ARM (with insmod file.ko command).

To do that, i am using a cross compiler which some values are stated below:

  • echo $CC : arm-oe-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-vfp-neon-oe-linux-gnueabi

  • echo $ARCH=arm

  • echo $CFLAGS: O2 -pipe -g -feliminate-unused-debug-types

  • echo $LD : arm-oe-linux-gnueabi-ld --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-vfp-neon-oe-linux-gnueabi

  • echo $LDFLAGS : -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,--as-needed

when i launch "make command", i get the following errors:

LD [M] /home/scof/script_emulation/AODV/aodv-uu/lnx/kaodv.o

arm-oe-linux-gnueabi-ld: unrecognized option '-Wl,-O1'

arm-oe-linux-gnueabi-ld: use the --help option for usage information

It states that there is something wrong with the linker. This linker comes from the cross compilation tools and i normally shouldn't touch it.

Anyway, to get this above errors fixed, i try to withdraw the LDFLAGS like this: export LDFLAGS='', and after this, the make command works and i get the module kaodv.ko. But when i insert it into my ARM to check, it does not work. It actually freeze my terminal

So my question is, do i have to specify the LDFLAGS when compiling ? Does withdrawing LDFLAGS can have impact on the generated kernel module. Actually, i try to understand where might be the problem and the only thing that come to me is that may be i should not change manually the LDFLAGS. But if i don't change de LDFLAGS, i get the unrecognized option error.

My second question related to that is, what are the possibly value of LDFLAGS in ARM compilation

Thanks !!

scof007
  • 415
  • 2
  • 9
  • 15
  • Does removing just that one (`-Wl,-O1`) flag let things work correctly? – Etan Reisner Aug 20 '14 at 14:32
  • @EtanReisner I've tried to remove (-WL, -01), and i get this error: arm-oe-linux-gnueabi-ld: unrecognized option '-Wl,--hash-style=gnu' that's why i withdraw all of them to get the module who apparently does not working – scof007 Aug 20 '14 at 15:19
  • You can run make with **V=1**. See the [Kbuild wiki](http://stackoverflow.com/tags/kbuild/info) and references there for more information. There are references to `LDFLAGS`, etc. Also, you should not be touching these options. The kernel often assumes that certain options are used to generate code. Generally, you change options via *menuconfig*. Otherwise, your question is answered by `man ld`. – artless noise Aug 20 '14 at 15:42
  • For instance, the *kbuild* system should determine your CPU type via *menuconfig* and *.config* variables and use appropriate `-march` and `-mfpu` options. In cases where multiple machines are being supported, the lowest base machine is used with machine/arch specific files using other options. – artless noise Aug 20 '14 at 15:56
  • Is this question arm specific? Accepted answer isn't. Can we remove the tag? – auselen Aug 21 '14 at 06:52

2 Answers2

17

echo $LDFLAGS : -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,--as-needed

There are two common methods of invoking the linker in a GCC-based toolchain. One is to do it directly, but another is to use GCC as a front end to invoke the linker, rather than invoke it directly. When doing this, options intended for the linker are prefixed with -Wl, so that GCC knows to pass them through rather than interpret them itself.

In your case the error message from LD itself

arm-oe-linux-gnueabi-ld: unrecognized option '-Wl,-O1'

Indicates that your build system is passing LDFLAGS directly to the linker, and not by way of GCC.

Therefore, you should remove the -Wl, prefix and your LDFLAGS would instead be

-O1 --hash-style=gnu --as-needed --as-needed

(the duplication of the last argument is probably pointless but benign)

Chris Stratton
  • 39,853
  • 6
  • 84
  • 117
  • While this answer is technically correct for the tool, I am not sure that getting this to work is a good idea. [Kbuild.txt](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/kbuild/kbuild.txt) documents environment variable to pass to a Linux kernel build and I don't see `LDFLAGS` there. It is certainly possible to do bad things if you don't understand the implication of options to the tools have on the kernel. – artless noise Aug 20 '14 at 15:52
  • @artlessnoise Indeed, the response fixed the error (thanks chris). Otherwise, about the LDFLAGS, i think it is an openembedded thing. The point of openembedded is to create a linux distribution for ARM. Actually, LDFLAGS is generated by a SDK I use. while using the SDK to generate a configured environment for the cross compilation with this command: source /usr/local/oecore-x86_64/environment-setup-xyz, i get all of the cross compilation environment in my current shell such as: $CC, $CFLAGS, $LD, $LDFLAGS, and so on and so on. Now, i still have to install the module generated on the ARM ... – scof007 Aug 20 '14 at 16:38
  • I am familiar with OpenEmbedded. My point is that the Linux kernel involves lots of assembler and system dependent things. Tool options can be extremely important. While most code will work with either `-Os` or `-O3`, the kernel code may break in [mysterious ways](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854). At the very least using standard options are well tested. Be sure that OE recommends these options for the kernel and not general user code. Linux cross builds fine with `make CROSS_COMPILE=tool-prefix ARCH=arm` for me. – artless noise Aug 20 '14 at 17:15
  • The real cause of this problem is the OpenEmbedded SDK. The script to setup the environment sets LDFLAGS, CFLAGS, and so on. It shouldn't do that. These settings may work with some package's build systems, but they are far from universal. Some build systems, like the ones used by the Linux kernel, U-Boot, Barebox, are *broken* by the these settings. You should `unset` LDCONFIG, LD, CC, CFLAGS, and so on. Don't set them to a blank value, they need to be unset. – TrentP Feb 06 '20 at 21:14
1

-O1 is an option that tells the linker to optimize. I believe it something new, and your linker may be slightly out of date. Try removing -Wl,-O1, it should still work.

tohava
  • 5,344
  • 1
  • 25
  • 47
  • According to `man ld`, it accepts a level parameter, `-O level`. – tohava Aug 20 '14 at 14:53
  • Thanks for the response, so, i remove -Wl,-O1 and it goes like this: arm-oe-linux-gnueabi-ld: unrecognized option '-Wl,--hash-style=gnu'....... What is the meaning of the -Wl option anyway, i did not see it anywhere, not even with man ld – scof007 Aug 20 '14 at 15:28
  • Wl is a compiler option which says "pass the next option to the linker" – tohava Aug 20 '14 at 15:39
  • I think the other answer is the correct one, not mine. – tohava Aug 20 '14 at 15:39
  • `-Wl` is the way to pass linker options through the compiler. It shouldn't be necessary when passed to the linker directly I believe. – Etan Reisner Aug 20 '14 at 15:39