Build failure

[Fat-Zer]

There is a build failure for me in both RC and RCBugFix branches:

  CXX   Marlin_main.cpp
In file included from SdFile.h:27:0,
                 from cardreader.h:8,
                 from Marlin_main.cpp:47:
SdBaseFile.h:38:8: error: using typedef-name 'fpos_t' after 'struct'
 struct fpos_t {
        ^
In file included from Marlin.h:14:0,
                 from Marlin_main.cpp:30:
/usr/avr/include/stdio.h:947:19: note: 'fpos_t' has a previous declaration here
 typedef long long fpos_t;
                   ^
Makefile:493: recipe for target '/tmp/marlin-build/Marlin_main.o' failed

The problem seems to be the same as described in issue #1083

PS: The fix from the issue works as well...

[KiteLab]

What's the version of Arduino IDE you are using? Searched for 'fpos_t' in the sources of 0023 1.03, 1.05, 1.6.7 with no luck.

[Fat-Zer]

My arduino IDE is 1.0.5, but it doesn't matter: the declaration of fpos_t is in stdio.h in avr-libc starting version 1.8.1 (the current latest release)

[KiteLab]

You are building with make?

[Fat-Zer]

yes, but it shouldn't make any difference too: arduino uses "system" avr-libc as well

[Wackerbarth]

@Fat-Zer - Actually, the supported versions of the Arduino IDE use their own version of the toolchain. I'm closing this since you are using an unsupported build configuration.

However, I will add a "Feature Request" to MarlinDev requesting the use of a more recent version of the SDFat library.

[Fat-Zer]

@Wackerbarth I believe you are wrong: arduino-1.0.x doesn't bundle it's own libc neither avr-gcc, at least on linux, so IMHO as far as you support the 1.0.5, you should suppport the modern avr-libc versions as well.

After all it's just a rename of an internal type with a one-line sed fix... And on the other hand it would be sad to see a build failure in the recent release just because it hasn't been done...

Also I agree that updating of the SDFat is a big deal that should be done in Dev, notice that I don't propose it here...

PS: is reopening bugs forbidden here?

[Wackerbarth]

@Fat-Zer -- We no longer support building with the (ancient) Arduino IDE 1.0.x. Rather, we have moved to more recent versions of the IDE. (Although we still use parts of the Arduino core from that older era).

[Fat-Zer]

@Wackerbarth, ok, thanks for response, I will no longer insist on this, but I still think it's generally a good idea to fix this now, before the release, because of several reasons:

• in general I believe it's a week argument that arduino bundles only old version of libc with itself.
• on the other hand one of further versions of arduino may start to bundle the new libc.
• generally due to fpos_t is an internal c++ type it's not very good idea to use it on the "application" level code.
• I don't think I will be the only one facing this problem: e.g. out of the box gentoo provides only old arduino and by default new libc.

[Wackerbarth]

Fortunately, Linux users can readily download the modern Arduino IDE from arduino.cc. We cannot afford to expend our effort modifying our firmware to address an issue with the packager of your desktop OS.

[Fat-Zer]

We cannot afford to expend our effort modifying our firmware to address an issue with the packager of your desktop OS.

What efforts? The issue has a ready to use fix... It's absolutely trivial, so no risk of regressions or whatever. What do you need more to reduce efforts? A patch? A pull-request? Or it's just a general position, «we don't support anything beyond the versions upstream bundled with it's binary package»? IMHO the conversation here took more "efforts" than to fix the bug required...

PS: sorry about the tone of the message, I really appreciate the work you guys do and that personally you still keep this discussion. But this one pissed me off a bit, it's IMHO so away from the spirit of open software development...

[thinkyhead]

Since the SdBaseFile bundled with Marlin is just a slice of the library, and since no other code references it, it's quite okay to rename fpos_t to something else. Unfortunately, it's not trivial to upgrade to a newer version of SdFat, and there are historical reasons why we had to use a customized slice of it. (Long filename support being one.)

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.