Particle Dev: Build didn't produce binary Error

look here:

you’ll want to use a C string


Just as a side note about String and Particle.variable()

Even if it works at some point it might stop working under some circumstances and errors like that are a hell of a job to find.

1 Like

Thank you @BulldogLowell and @ScruffR. I will do the switch to C string.

I’m trying to run from Particle Dev, a software on the Photon, but I’m getting the “Build didn’t produce binary error”. How Can I fix it? The software is .ino extension.

There are a few things that can cause this error.

One that we keep bumping into is the size of our binary. How many kb was the last binary you were able to compile? If your new binary is greater than 128kb you would get this error.

Another cause of “Build didn’t produce binary” with no error listed is that the directory containing the .ino file contains more than one .ino file. It doesn’t just build the file you have open, it builds all of the .cpp and .ino files in that directory so you can use libraries.

And a number of other reasons discussed in the forum.

Usual response:
Provide more background, code, screenshot, … to save us from needing to guess around :crystal_ball:

Just a few
Particle Dev won't build, particle-cli will
Particle Dev: "build didn't produce binary"
Particle Dev with multiple projects - what?
Particle dev will not compile
Particle Dev objbase.h no such file Cannot compile

Mostly the same reasons :wink:

1 Like

Thank you for your reply. In my project there a some different library, so I have multiple cpp and h file, with just one .ino file. I always get that problem…

I had this same problem today and after I chose a device, the error went away. For those with no compile problems perhaps this would help with your issue.

I had this problem and the actual issue was a particle.function with too long of a name (12 character max). Hope this helps someone.

What version were you targeting?
AFAIK with more recent versions you should get an explicit warning/error when providing too long names.
If this wasn’t the case with the most recent version, we might have found a regression.

But I do get

In file included from ../wiring/inc/spark_wiring.h:48:0,
                 from ./inc/application.h:36,
                 from _inttest.cpp:2:
../wiring/inc/spark_wiring_cloud.h: In instantiation of 'static bool CloudClass::function(const T&, Types ...) [with T = char [14]; Types = {int (*)(String)}]':
_inttest.cpp:25:41:   required from here
../wiring/inc/spark_wiring_cloud.h:188:9: error: static assertion failed: 

In Particle.function, name must be less than 12 characters

Although it should actually be In Particle.function, name length must be equal or less than 12 characters

I was targeting 0.5.3

I’m also getting this error, using an brand new Electron 2G. When I click on the message, Particle-dev tells me “There were no compile errors.” My project has a .cpp and .h file in the project directory alongside my .ino file, which has a #include “mylib.h” at the top of it.

Using Particle-dev to comipe and generate a binary seems to work fine on a trivial stand alone .ino file in its own directory (i.e. with an empty setup and loop).

Are multi-file projects just not yet supported in Particle-dev? This documentation would lead me to believe it was…

Yes, they are supported.
Can you post a screenshot of the full Dev window?

@ScruffR yea sure, mildly santized…

It must be something about the actual contents of my project but when I click on the red text in the bottom bar of the screen shot above, this pops up, which makes it seem like there’s no problem.

I can, nevertheless download the binary from the Cloud IDE without issue.

Have you got the latest CLI installed?
If so, execute this from within your project folder

particle compile electron .

Maybe this reveals more about the problem.

@ScruffR cool, didn’t know you could do that. I get the following:

Compiling code for electron

attempting to compile firmware 
Compile failed. Exiting.
../../../build/target/user/platform-10/libuser.a(MyProj.o): In function `loop':
MyProj.cpp:17: multiple definition of `setup'
../../../build/target/user/platform-10/libuser.a(MyLib.o):MyLib.cpp:16: first defined here
../../../build/target/user/platform-10/libuser.a(MyProj.o): In function `loop':
MyProj.cpp:31: multiple definition of `loop'
../../../build/target/user/platform-10/libuser.a(MyLib.o):MyLib.cpp:30: first defined here
../../../build/target/user/platform-10/libuser.a(MyProj.o): In function `loop':
MyProj.cpp:17: multiple definition of `scale'
../../../build/target/user/platform-10/libuser.a(MyLib.o):MyLib.cpp:16: first defined here
../../../build/target/user/platform-10/libuser.a(MyLib.o): In function `setup':
MyLib.cpp:(.text.setup+0x46): undefined reference to `MyLib::begin(unsigned char, unsigned char, unsigned char)'
MyLib.cpp:(.text.setup+0x54): undefined reference to `MyLib::set_scale(float)'
../../../build/target/user/platform-10/libuser.a(MyLib.o): In function `_GLOBAL__sub_I_scale':
MyLib.cpp:(.text.startup._GLOBAL__sub_I_scale+0x28): undefined reference to `MyLib::MyLib()'
MyLib.cpp:(.text.startup._GLOBAL__sub_I_scale+0x58): undefined reference to `MyLib::~MyLib()'
../../../build/target/user/platform-10/libuser.a(MyProj.o): In function `_GLOBAL__sub_I_scale':
MyProj.cpp:(.text.startup._GLOBAL__sub_I_scale+0x30): undefined reference to `MyLib::MyLib()'
MyProj.cpp:(.text.startup._GLOBAL__sub_I_scale+0x60): undefined reference to `MyLib::~MyLib()'
collect2: error: ld returned 1 exit status
make: *** [642e5dc4fdf0bfa7fc7c1004f6b26b3b4bf20ab0f275f8c28b90828fa312.elf] Error 1

It seems you’ve got a setup() and loop() in both your MyProj.ino and MyLib.cpp.
And/or you haven’t ensured against multiple inclusion of your MyLib.h.

You should always use something like

#ifndef _MYLIB_H_
#define _MYLIB_H_
// put your header code here


#pragma once
// put your header code here

to avoid multiple #include "MyLib.h" statements to cause such trouble

@ScruffR sure that makes sense, the #ifndef approach my standard approach, and it is indeed the case here. But you got me thinking… could it be a problem that I’m doing the following inside MyLib.h:

#include "application.h"

I thought that was “the way” you get access to things like byte and String inside the class (h/cpp) files, and the Cloud IDE seems happy with it, but perhaps not the CLI?

----- Revised -----
I accidentally had copied the ino contents into the cpp file. Applies face to palm. And by the way it compiles fine when I do that. Thanks for being patient with me @ScruffR!

1 Like

As you found out application.h and its successor Particle.h (preferably used) has the multi-inclusion-protection in place, so no risk from that.

1 Like