http://forums.leaflabs.com/topic.php?id=9738 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:20:01 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=9738#post-21395 Sun, 02 Dec 2012 10:53:24 +0000 pico 21395@http://forums.leaflabs.com/ <p>What is the mechanism the IDE uses to decide whether to invoke the linker stage after the compier stage? This seems to be the problem: The IDE seems to be getting a false signal of a compiler error, when none occurs. I've run the compiler and linker stages manually, and they complete without error. I used the compiler options and flags as specified by the IDE (got them by pressing the build button with the shift key depressed.)</p> <p>I've almost definitely isolated the error down to the IDE. The g++ compiler is doing it's job correctly, producing good, linkable .o output, but the link stage isn't being called in some situations. When it is called, the link proceeds without error, and the .elf and .bin files are successfully built.</p> <p>I've managed to cajole the IDE into invoking the link stage by rearranging the position of a #include directive. The directive was brought up one level from another include file to being included directly from the sketch. The rearrangement should make no difference to the compilable source output by the preprocessor, however, and a check using the -save-temps option verfies this: In both arrangements the post processed source is identical, line for line. No omissions, no reordering -- I really mean line for line identical output that is being passed to the compiler. (Which is actually what one would expect given the normal behavior of the preprocessor.)</p> <p>I've tested the ERRORLEVEL of the compilation using both #include arrangements; in both cases, the ERRORLEVEL returns as 0. So I don't know what signal the IDE is using to detect a problem in the compilation stage. But whatever it is using, it would appear it is not 100% reliable. </p> <p>I've run out of time chasing this one down for now. The code compiles without complaint using the Arduino IDE (0023 and 1.0.1) and AVR g++. I was doing what I thought would be a straightforward port to the Maple when I struck this problem. Sort of side-tracked the project for a couple of days, unfortunately, but now I must really get on with it. The #include rearrangement is a clumsy work-around on the Maple for now, but it bothers me for two reasons a) the underlying problem is not completely characterised or understood, it's just an empirical thing, and the underlying problem may manifest itself in other situations unexpectedly, and b) the #include is really out of place, and really should be where it was originally and not in the main sketch. </p> <p>If anyone is familiar the details of how the IDE detects a failed compilation to suppress invoking the link stage, please chime in. </p> http://forums.leaflabs.com/topic.php?id=9738#post-21365 Fri, 30 Nov 2012 11:14:09 +0000 pico 21365@http://forums.leaflabs.com/ <p>This is an odd build problem I've spent some time with today in IDE v0.0.12 (Arduino 0018), Windows 7 (64 bit).</p> <p>The link stage seems to be failing, or possibly never starting, but there are no error messages or other clues I can see as to why at this stage. The compiler compiles all the files without any errors, but some fairly benign warnings (unused variables, variables my not be initialized, deprecated conversion from string constant to char, those sorts of things). </p> <p>Looking in the temp build directory, all the .o files are there, but there is no .elf, .bin or .hex -- no evidence the linker was ever invoked, in fact. There was no "linking...." msg in the IDE window. </p> <p>I'm inclined to try do a manual link step to see what happen, to see if there are any fatal error meesages from the linker I'm not seeing in the IDE. Can anyone advise as to what the equivalent linker command should be?</p> <p>And has anyone seen this kind of build faliure before? I've never seen it not proceed to the linker stage unless there were compiler errors reported (not just warnings.) </p>