lwip make compile failure

[bebo-dot-dev]

Hi there, this is no big deal for me but I thought I'd mention it anyway. I was following along on an issue that was raised in the ESP8266 arduino core project here: esp8266/Arduino#3143 and I learnt something new when igrr mentioned that it's possible to compile lwip from source at project build time by selecting the "Core Development Module" as the board and selecting "Open Source (gcc) as the lwip variant.

The issue I'm seeing is that this does work fine when testing with a new empty skeleton sketch project in the Arduino IDE 1.8.1 but doesn't work and fails with this error when attempting the same thing in Eclipse Neon 4.6.2 with Sloeber 4.0.0.201701171403:

Starting combiner
"/home/joe/eclipse/cpp-neon/eclipse//arduinoPlugin/packages/esp8266/tools/xtensa-lx106-elf-gcc/1.20.0-26-gb404fb9-2/bin/xtensa-lx106-elf-gcc" -g -Wall -Wextra -Os -nostdlib -Wl,--no-check-sections -u call_user_start -Wl,-static "-L/home/joe/eclipse/cpp-neon/eclipse//arduinoPlugin/packages/esp8266/hardware/esp8266/2.3.0/tools/sdk/lib" "-L/home/joe/eclipse/cpp-neon/eclipse//arduinoPlugin/packages/esp8266/hardware/esp8266/2.3.0/tools/sdk/ld" "-Teagle.flash.4m.ld" -Wl,--gc-sections -Wl,-wrap,system_restart_local -Wl,-wrap,register_chipv6_phy -o "/home/joe/Dev/Workspaces/Eclipse_Neon/lwip_compile_test/Release/lwip_compile_test.elf" -Wl,--start-group    ./.ino.cpp.o   /home/joe/Dev/Workspaces/Eclipse_Neon/lwip_compile_test/Release/arduino.ar   "/home/joe/Dev/Workspaces/Eclipse_Neon/lwip_compile_test/Release/arduino.ar" -lm -lgcc -lhal -lphy -lpp -lnet80211 -lwpa -lcrypto -lmain -lwps -laxtls -lsmartconfig -lmesh -lwpa2 -llwip_src -lstdc++ -Wl,--end-group "-L/home/joe/Dev/Workspaces/Eclipse_Neon/lwip_compile_test/Release" /home/joe/Dev/Workspaces/Eclipse_Neon/lwip_compile_test/Release/arduino.ar
/home/joe/eclipse/cpp-neon/eclipse/arduinoPlugin/packages/esp8266/tools/xtensa-lx106-elf-gcc/1.20.0-26-gb404fb9-2/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld: cannot find -llwip_src
makefile:82: recipe for target 'lwip_compile_test.elf' failed
collect2: error: ld returned 1 exit status
make: *** [lwip_compile_test.elf] Error 1

So it would seem that -llwip_src is failing to be resolved somehow. Perhaps it's a path resolution failure problem somewhere..but it's hard to see what's going wrong because the above is all that gets output to the console. Any ideas at all?

[jantje]

no idea at all
The only thing I can do is compare the arduino IDE verbose compile commands with the Sloeber commands and find the differences

[jantje]

What do you want me to do with this issue?

[bebo-dot-dev]

Nothing really mate. It's no big issue for me so I'll let you decide if it's worth fixing. I guess that someone finding and needing to fix a bug in the lwip stack might consider this a show stopper, but for me it's not..for the moment at least 😉

[jantje]

I tried it on my system with arduino IDE and that one failed :-s
But this seems to be a duplicate of #927 (don't ask me how this can be a duplicate oif a issue with a index number that is 200 more) ;-)
The good news is.. I feel like fixing 927

[bebo-dot-dev]

That sounds great. I personally won't benefit from anything here. I do appreciate the effort that you guys have put into the Eclipse Arduino plugin over the years but I decided a while ago to admit defeat with Eclipse.

In the end I got tired of constantly battling with Eclipse being too cumbersome, monolithic and flaky and I made the switch to PlatformIO.

Good luck. Please feel free to keep this issue open or close it, I'll leave it to you. Thanks.

[jantje]

Does PlatformIO offer the indexer functionality?

[bebo-dot-dev]

My understanding of the Eclipse CDT indexer is that it enables two things:

1. project code navigation features having performed a parse of code files in a project AND
2. intellisense / code completion features

If the question you're asking is: "does PlatformIO provide any features to enable code to be navigated?" then the answer to that question would be "sort of".. PlatformIO offers two options to choose from when you install:

1. the Atom flavour of PlatformIO which runs in a modified version of the vanilla Atom editor OR
2. the Visual Studio Code flavour of PlatformIO which runs as a plugin in VSCode

When PlatformIO is running in the Atom editor "Goto Declaration" is pretty much all you get for semi-intelligent code navigation along with some generic "Find in project" search type features.

When PlatformIO is running in VSCode, there are more code navigation options available because VSCode has built in code navigation features i.e. "Goto Definition", "Goto Declaration", "Peek Definition", "Peek Declaration", "Goto Implementation" etc.

So the question of quality / availability of code navigation type features largely comes down to the editor that you choose to use PlatformIO with rather than what is provided by PlatformIO itself.

For the second part, PlatformIO does include a code completion indexer "engine" to enable code editing intellisense / code completion.

I guess VSCode could be considered better that Atom for code navigation type features when developing with PlatformIO. However the Atom editor however does have some features that VSCode doesn't have..so perhaps which one you prefer is a bit of a personal preference thing. Personally I prefer VSCode because VSCode is my general file editor of choice nowadays.

For me the "killer" feature of PlatformIO when working with ESP8266 / Arduino projects is the library dependency finder. This enables you to declare the project / board type and what libraries your project depends on in the platformio.ini file with a few lines of text and PlatformIO will then use this to pull library dependencies in and setup library paths automatically. This makes it really easy to get going quickly with PlatformIO enabled project code..library / dependency setup friction is reduced to zero.

[jantje]

Thanks for the input. It confirms my (old) knowledge from PlatformIO. It is a "closed", "compilation environment" with great "code editor" support.
I don't consider this a "less good solution" or "inferior quality" it just is a basically different approach.
In these terms I would describe Sloeber as "open","IDE" with eclipse quality editor.

Let me explain what I mean and please do correct me if I'm wrong.
With closed I mean "Only platformio can (or is supposed to) add boards/libraries to the environment". In other words PlatformIO takes quite a lot of control over "What is available in the environment" and in that way PlatformIO can guarantee/test whether things work together.

In the Arduino framework (implemented in the Arduino IDE and Sloeber) is open in the sense that anyone can create and add libraries/boards. This is open and allows for quick updates but also makes it impossible to guarantee "things will work"

With "compilation environment" I mean that PlatformIO makes sure everything is there to get the stuff compiled and does the compilation. It does not "share/integrate" the build commands with a "third party" (like a code editor).
Sloeber is a real IDE (thanks to CDT) because the editor view is real time influenced by the exact build commands. Defines/headers known by the compile command are known by the editor and as such available for code extension.

With "code editor" I mean that there is no real link between the actual build commands and the editor. In the previous section I explained this at the level of the build command querying but this also accounts for build output (showing errors in the editor).
Things I'm thinking about in Sloeber is a "problems view"(showing all warnings/errors in your project)
Don't get me wrong using visual studio as a "code editor" will offer a lot of features and a very nice user experience (on windows) but if platformIO does not share the actual build commands there is "only as much as visual studio" can do. That is still way more than Arduino IDE has to offer and way more than the most users will ever use.

For me the "killer" feature of PlatformIO when working with ESP8266 / Arduino projects is the library dependency finder. This enables you to declare the project / board type and what libraries your project depends on in the platformio.ini file with a few lines of text and PlatformIO will then use this to pull library dependencies in and setup library paths automatically. This makes it really easy to get going quickly with PlatformIO enabled project code..library / dependency setup friction ...

I can understand that.

is reduced to zero.

For the reasons explained above this will never be possible in a "open" Sloeber.

Looking forward to your input.