Linking .pio/build/d1_mini/firmware.elf
/Users/marcelstoer/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld: .pio/build/d1_mini/libFrameworkArduino.a(core_esp8266_main.cpp.o):(.text._ZL12loop_wrapperv+0x4): undefined reference to `setup'
/Users/marcelstoer/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld: .pio/build/d1_mini/libFrameworkArduino.a(core_esp8266_main.cpp.o):(.text._ZL12loop_wrapperv+0x8): undefined reference to `loop'
/Users/marcelstoer/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld: .pio/build/d1_mini/libFrameworkArduino.a(core_esp8266_main.cpp.o): in function `loop_wrapper()':
core_esp8266_main.cpp:(.text._ZL12loop_wrapperv+0x21): undefined reference to `setup'
/Users/marcelstoer/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld: core_esp8266_main.cpp:(.text._ZL12loop_wrapperv+0x2d): undefined reference to `loop'
collect2: error: ld returned 1 exit status
*** [.pio/build/d1_mini/firmware.elf] Error 1
It looks as if it didn’t understand that this is actually Arduino code. Already deleted the .pio, .platformio and ~/.platformio/packages folders but that doesn’t help.
Since you didn’t mention what you’re trying to compile, I’m assume you mean one of the examples. I had a skim of most of them, and there’s no #include <Arduino.h> in a couple… which is most likely why you have the undefined reference to 'setup'/'loop' errors.
I get your point, thanks. As this project is an Arduino library (for ESP8266) that includes examples the Travis file includes all the
env:
- PLATFORMIO_CI_SRC
definitions for each example. That works - with or without the #include <Arduino.h>.
I guess I was hoping I could build all at once locally with the minimal platformio.ini included in the project. That doesn’t seem to be case even if I add #include <Arduino.h> to all the examples it was missing (thanks for the hint).
Hm… I’ll counter with another question, but for @ivankravets… which could answer this for both of us… as I had tried to get this configuration working before but it wouldn’t play ball, and I am so close now it’s not funny.
Ivan, I managed to get my pet library to compiles examples in different envs using the following, but only if I rename the *.ino files to *.cpp. Is there anything I’m missing there? Is it possible to persuade PIO to accept *.ino files as well? .ino files are accepted if I point the [platformio] src_dir to a folder like $PROJECT_DIR/examples/timeouts, but that doesn’t help as that’s the global setting.
Edit: Just linking this topic, as it looks to be another approach to the problem, but if the OP can get it working again, looks to be neater / more automated.
with the elapsedMillis library (once I move the header file into /src) works just fine… I can compile all of the examples at once, or compile any individual one at will.
However, when I try to do the same for the esp8266-weather-station library, with this platformio.ini it spits the dummy … dependency graph is all wonky (although it is a bit wonky for the elapsedMillis examples also), and it can’t find the libraries, even though they were installed
Don’t worry about issues with MetOfficeDemo and oneDayForecaster. They’re excluded from the Travis build as well for some reason
However, I too am seeing the same behavior with other examples e.g. WeatherStationDemo. Platform IO doesn’t find the lib dependencies it had just installed seconds ago.
@ivankravets If you’re replying to me, I’m doing two things out of the ‘ordinary’ … By using the adjust_src_dir.py, PROJECT_SRC_DIR is changed to a directory with a *.ino file, so that condition is satisfied. Also, since the project revolves around the library examples, and the library is located in the \src directory, I set lib_dir = $PROJECT_DIR so that the library is found. It’s just that doing it this way seems to completely mess of the LDF and also means PIO doesn’t find libraries that have been downloaded. It would be nice if this could be made to work, or some variation of it… otherwise reverting to pio ci in a script looks to be the only viable option, just not so user friendly.
@marcelstoer Now you tell me I picked one of the ones that didn’t work?
Yeah, I noticed when compiling them for some reason they use ESPWiFi.h, not ESP8266WiFi.h … so that’s the first clue something ain’t quite right there! More importantly, is it getting anywhere with the other examples? Or falling flat on it’s face still? I mainly stuck to the WeatherStationDemo, and it didn’t seem to get past finding the libraries, so more poking around there is needed.
Compilation is fine but the linker fails with the errors reported in my first comment (undefined reference tosetup’`). Why would this work with CI but not if run locally.
Because you’re ignoring the warning at the top of the build log
Warning! Ignore unknown configuration option src_dir in section [env:WeatherStationDemo]
src_dir is only valid for the global [platformio] block, as it’s meant to specify the src_dir for the entire project.
The ci command works completely differently to a normal run… where you pass the directory path to the source files, specify a board and optionally directory with library files or install the library if needed… and it goes out and runs completely independent.
The nearest I can get to that locally so far is to… reprodice the ci run locally… ie.
pio ci -b d1_mini -l . --project-option="lib_deps=JsonStreamingParser, ESP8266_SSD1306, simpleDSTadjust, DHT sensor library, Adafruit Unified Sensor" examples/WeatherStationDemo
It has the downside of installing the libraries every time, (the alternative of installing the libraries globally has too many other project breaking implications that it’s not worth doing), although at the same time, the upside being it’s a 100% clean build every time, since it’s in a temp folder.
Thank you for the great feedback, much appreciated.
I could certainly put this into a script; loop over all examples and run the CI build locally. However, it’s hard to accept that this is really the best solution. I thought that building an Arduino library with examples must be a pretty standard use case.
@ivankravets can you confirm that we are not missing something obvious?