Particle Dev: Build didn't produce binary Error

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

Including:
    ./MyLib.cpp
    ./MyLib.h
    ./MyProj.ino
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
#endif

or

#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