I'm trying to build the Contiki OS for a custom platform (based on the EZR32LG MCU) with GCC compiler.
When I make the project it runs with a few warnings about '#pragma GCC diagnostic'. (I don't know if this is relevant, but I'm just providing the information to be complete)
After a few warnings, the compilation stops and returns:
/tmp/ccY4OiVd.s: Assembler messages:
/tmp/ccY4OiVd.s:37: Error: garbage following instruction -- `dsb 0xF'
/tmp/ccY4OiVd.s:51: Error: garbage following instruction -- `dsb 0xF'
make: *** [obj_slwstk6201a/watchdog.o] Error 1
I looked at the dsb instruction, but I'm not finding much except that this ensures that all explicit data memory transfer before the DSB are complete before any instruction after the DSB is executed.
Googling the error did not return many results, the only thing I found was that maybe my binutils version is outdated. I checked with ld --version, which returns 2.24. The latest release is 2.28, but I can't find a way to update the GCC version to use binutils 2.28.
So I downloaded GCC -v6, but the ld -v command still returns 2.24.
I'm not sure if this would resolve the error, or I'm completely wrong about the origin of the error..
Related
I am trying to compile a bare-metal ARM Cortex-M3 program with clang. (Code and linker script work fine with gcc.)
My issue is that clang seems to emit a section .ARM.exidx whether it is needed or not.
Since for my code, gcc did not emit a .ARM.exidx section, my linker script thus does not specify a region for it. clang however seems to emit it as indicated by this error message:
ld.lld: error: no memory region specified for section '.ARM.exidx'
clang: error: ld.lld command failed with exit code 1 (use -v to see invocation)
Is there any way to avoid generating this section when it is not needed?
I tried the options -fno-unwind-tables and -fno-exceptions but it seems to be a known bug that they do not work as expected. See these pull requests: D31139 and D31140
I am currently working around this issue with the following section defition in the linker script:
/DISCARD/ :
{
*(.ARM.exidx)
}
That seems a bit fragile though since the section will be missing if due to any changes to the code, the section is required at a later point.
I am using dev c++ for practicing data structures in C. After compiling any program, it runs for the first time.In subsequent runs,
the compiler shows following error:
dev-cpp\collect2.exe [Error] ld returned 1 exit status
What error is the compiler pointing out??
There's unfortunately not much information to go on. One thing that's always helped me so much, when troubleshooting mysterious GNU LD errors, is using the --cref -Map=$#.map flags (where $# is the name of the output file). It'll save a report explaining every single decision the linker makes, in painstaking detail.
I have a problem when building chromium for ARM platform. Here are some details about my host server:
Linux version 4.2.0-42-generic (buildd#lgw01-55) (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) )
And I use Chromium version 53.0.2785.143. I tried to use gn to build the chromium, and here is my arguments in args.gn file:
target_cpu = "arm"
arm_tune = "generic-armv7-a"
arm_float_abi = "softfp"
Basically, I used these specific arguments above because of my ARM platform. And the gn command ran without errors. However, when building project with ninja, the following errors popped out:
ninja: Entering directory `out/Default_arm64'
[1/1] Regenerating ninja files
[296/46119] LINK ./minidump-2-core
FAILED: minidump-2-core
../../third_party/llvm-build/Release+Asserts/bin/clang++ -Wl,--fatal-warnings -fPIC -Wl,-z,noexecstack -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -fuse-ld=gold -B../../third_party/binutils/Linux_x64/Release/bin -Wl,--icf=all -pthread --target=arm-linux-gnueabihf --sysroot=../../build/linux/debian_wheezy_arm-sysroot -L/home/miaozixiong/workspace/chromium/src/build/linux/debian_wheezy_arm-sysroot/lib/arm-linux-gnueabihf
-Wl,-rpath-link=/home/miaozixiong/workspace/chromium/src/build/linux/debian_wheezy_arm-sysroot/lib/arm-linux-gnueabihf
-L/home/miaozixiong/workspace/chromium/src/build/linux/debian_wheezy_arm-sysroot/usr/lib/arm-linux-gnueabihf
-Wl,-rpath-link=/home/miaozixiong/workspace/chromium/src/build/linux/debian_wheezy_arm-sysroot/usr/lib/arm-linux-gnueabihf
-Wl,-rpath-link=../Default_arm64 -Wl,--disable-new-dtags -o "./minidump-2-core" -Wl,--start-group #"./minidump-2-core.rsp"
-Wl,--end-group -ldl -lrt ld.gold: error: obj/breakpad/minidump-2-core/minidump-2-core.o uses VFP register
arguments, output does not
...
I am new to chromium and have no clue about what do those errors mean. So anybody knows how to work around? You are appreciated.
Note: I need my arm_float_abi attribute to be "softfp" according to my ARM platform. So please note I cannot change it to "hard". Also, when set float abi = "hard", there is no building errors.
ld.gold: error: obj/breakpad/minidump-2-core/minidump-2-core.o uses VFP register arguments, output does not
This a linking error to indicate that minidump-2-core cannot be linked, due to a mismatch in the floating point ABI: the object minidump-2-core.o is compiled for hard floats (the generated code takes advantage of the ARM VFP unit - "uses VFP register arguments"), but the target executable is requested to use soft floats (in which floating point support is emulated, rather than using specialized FP hardware instructions).
According to this bug report, Chromium should build fine with soft float.
My best guess is, try replacing softfp by just soft: arm_float_abi = "soft".
According to gcc documentation, softfp maintains the soft ABI but still 'allows the generation of code using hardware floating-point instructions', which could lead to the seen error.
If that won't work, you might want to check this tutorial on cross building Chromium for ARM:
https://unix.stackexchange.com/questions/176794/how-do-i-cross-compile-chromium-for-arm
I posted this question and finally solved it. I used my local tool chain on ARM platform and compiled it successfully with g++.
i'm trying to resurrect an old installation of Gentoo Linux that has kernel 2.6.32 and i could update #system with an exception: gcc 4.5.4 failed installation.
The last lines are here:
http://pastebin.com/8s4z0FJy
Ask me if you need more info, i'll post something more when i get home (Got that info through SSH).
Even GHC fails compiling but i'll handle that later. I need GCC in order to compile the other packages.
Thanks in advance
To respond to a link with another link from googling: https://forums.gentoo.org/viewtopic-t-896518-start-0.html. Let me summarize that thread:
{standard input}: Assembler messages:
{standard input}:87553: Warning: end of file not at end of a line; newline inserted
{standard input}:88534: Error: unknown pseudo-op: `.l38'
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive
xgcc: Internal error: Killed (program cc1)
Basically, the assembly errors come because gcc’s assembly output was interrupted when it was killed. The Gentoo forums thread suggests this may likely be because gcc used up too much memory. You can confirm this by checking near the end of dmesg’s output for OOM stuff. If memory is not the issue, then you might have a real bug and should follow the instructions in the text you pastebined for reporting the bug to https://bugs.gentoo.org/. But, please try seeing if memory is the issue first.
If memory is the issue, make sure that you have swap partitions on your machine and that they are enabled. You can view a summary of your enabled swap partitions by running swapon -s. If nothing shows up and you cannot repartition, you can always use a trick like # ( umask 0077 && dd if=/dev/zero of=/.swap.img bs=1M count=1024 && mkswap /.swap.img && swapon /.swap.img ) (the ‘#’ indicates a root shell prompt, so don’t actually type it). The forum thread also suggests that removing -pipe, which causes gcc to use more memory instead of writing out lots of temporary files, from CFLAGS and CXXFLAGS (by editing /etc/make.conf or /etc/portage/make.conf, whichever exists). We cannot tell what your CFLAGS are from what you posted.
I am trying to compile source of milcv7.7.8/ks_spectrum on a cluster with MPICC using version 11.1 20090511 when make the source in milcv7.7.8/ks_spectrum by 'make ks_spectrum_hisq' command then at last the error comes out as
com_mpi.o: In function initialize_machine':
../generic/com_mpi.c:(.text+0xb447): undefined reference to_mm_idivrem_epi32'
I know now that this function _mm_idivrem_epi32 is a part of ia32intrin.h file in intel compiler.
When I use the latest intel mpiicc on new cluster with 14.0.0 20130728 version of intel compiler then code compiles successfully.
So is there any way to tell linker to include function _mm_idivrem_epi32 location...
_mm_idivrem_epi32() is not a function but rather a compiler intrinsic. When properly handled, it is replaced with a call to __svml_idivrem4() from the Intel's Short Vector Math Library libsvml.
You are most likely being hit by a bug in ICC's auto-vectoriser. Try compiling the same source file with -no-vec and see it this has any effect. Or better use the newest ICC version that you have at your disposal.