Failing to build example. #336
Comments
|
@rvlander What version of rust? Also, can you post the compilation error you are getting? |
|
@posborne, what method should I use? README based? Travis base? or cargo build in example directory? I tried with rust nightly (1.4.0) and rust 1.3.0beta. |
|
@rvlander, I apologize. It has been a little while since I have tried to build. I think there are a few things going on.
I probably won't be able to get to making changes today, but I was able to reproduce a problem. Does this look like what you get when trying to compile an example? |
|
Yes I have the same error. |
|
I have the following error now:
|
|
@rvlander That looks to be a problem upstream with the version of nightly rust that you're using, though I could be wrong. |
|
rust-libcore shouldn't fail to compile. can you please try with the next nightly and report back? |
|
I tested with rustc 1.4.0-nightly (e822a18ae 2015-08-16) |
|
@rvlander, what specific command are you using to build? I have seen similar errors when I forget to add on the target spec. |
|
cargo build in the example dir. |
|
@rvlander Until I fix the Makefile for the examples, you'll have to manually add the So for lpc17xx, you'd have cargo build --target=thumbv7-none-eabi --releaseA discussion of how to go about solving this inconvenience is going on in #333 |
|
I copied the target specification file in the example dir, then launched this command. Unfortunately, i still have the same error. |
|
It finally built with last zinc version and last rust nightly. Thanks all. However I have a linking error when trying to build in debug. |
|
What's the error with debug? I remember running in to something like that back when I was doing #285 |
|
This is the error I get: |
|
Ugh. I thought we were finally out of the woods with the debug index symbols but I guess not. @posborne you were playing around with this issue with me before too. Just tagging you so you get notifications here too. |
|
Hm, |
|
@mcoffin, I believe those are not debug symbols, but "index entries for section unwinding", i.e. they are used in |
|
I am using the gcc-arm-none-eabi-4_8-2014q2 toolchain. I will try with other toolchains and report back. |
|
@rvlander, FWIW, I have been using the 4.9 toolchain from https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded under 14.04. Looks like there is a newer ppa available here now: https://launchpad.net/gcc-arm-embedded (assuming you are on Ubuntu). |
|
Just tried with 4.9-2015q2. Same error. |
|
Curious. Can you add them into linker script and dump the resulting linker map? I have little idea why it's being pulled in for your toolchain. |
|
I was able to reproduce this on my mac (using arm-none-eabi-gcc 4.9) today when bringing my PWM stuff up to date. Here's the failing link command and error: Here's the generated map file with cross references: https://gist.github.com/posborne/1c68c70e5dfce94dafba As a quick fix, I was able to get things to link with the following change. Excluding this section seems fine, but maybe somebody else more familiar with the linker knows better. diff --git a/src/hal/layout_common.ld b/src/hal/layout_common.ld
index 7ce8590..4bf67b3 100644
--- a/src/hal/layout_common.ld
+++ b/src/hal/layout_common.ld
@@ -62,6 +62,6 @@ SECTIONS
*(.rel.*) /* dynamic relocations */
*(.ARM.exidx*) /* index entries for section unwinding */
*(.ARM.extab*) /* exception unwinding information */
- *(.debug_gdb_scripts)
+ /* *(.debug_gdb_scripts) */
}
} |
|
@farcaller: Sorry but I am not sure of what you mean. I don't have a deep knowledge/understanding of gcc linker. How do I do what you expect from me? |
|
@rvlander, I think I provided the info the @farcaller was asking for. To do that, I just copied the failing link command and added `"-Wl,-Map=failedlink.map,--cref". You can try the workaround in my above diff to see if that also works for you (I expect it will). The bigger question is probably why 44a291f claims that it made the binaries too big. It will certainly increase the size of the elf file, but does this matter? Won't this and other sections be removed before any code is loaded on a target? |
|
It's where in elf file it lands, if you don't discard it, it follows after Can I have the elf with rustc_debug_gdb_scripts_section link error? I wonder if it's somehow relevant to recent rust and I really wonder why I still can't reproduce it. |
|
@farcaller, the error prevents the elf from being generated. I can, however, provide an elf with the workaround which should have the information you need to determine if that workaround is ending up in ROM. Will probably have to wait until this evening. |
|
Yes, the latter one is what I want to see. |
|
It appears that things are fine with the section included. It adds 34 bytes to the executable which is a wash with all the other losses when doing a debug build. Here's the output for empty: Consisting of... The elf files (empty and and rgb_pwm_lpc17xx) can be found here: https://gist.github.com/posborne/01e937e4021c815466f7. The rgb_pwm_lpc17xx currently ends up pulling in quite a bit (.text is >32K; oddly, this wasn't the case yesterday on my mac but is the case on my Linux box). |
|
Is this a release build? |
|
Both are debug builds. |
|
After checking the release builds they look sane to me so I guess we can move on with defining the missing symbols, they don't matter much for release binaries. This is going to land as part of #311. |
|
Aren't they useful for gdb? |
|
Yes, having debug builds work (at least for small programs where things will fit) is quite useful for gdb debugging. I'll work in the change to #311 when I get around to taking care of the next set of updates. |
|
@posborne, I explained myself badly. Of course gdb need debug builds. What I understand is that the fix to the problem was to define dummy symbols so that the linker is happy. But will it affect the behaviour of gdb? Doesn't gdb need real symbols instead of dummy ones? |
|
Those symbols are used for unwinding, and if you got to unwinding things are horribly wrong anyway (i.e. you will trap in gdb no matter what). |
|
This can be closed now that the docs are updated. |
|
Right, missed this one. |
|
I'm now getting the aforementioned error. @posborne. It's probably my environment setup but it does seem odd. Tips?
If someone wants to debug / help, I'll be in #zinc on Mozilla IRC later tonight. |
|
try removing |
|
I think I've found it. The unzip directory for rust in Explanation for Archives
So, good news @rvlander, you're not nuts, and this was a valid issue. We just happened to be going from a clean environment often enough for it to not cause issues. |
I have tried different way to build examples but without success.
The README page seems to be outdated.
I tried to directly cargo build in an example dir, but there is a compilation error when compiling core.
I tried to look to travis log to find a way: I have have another compilation error.
The text was updated successfully, but these errors were encountered: