'-fcallgraph-info=su' breaking builds on some platforms

[rtrussell]

The introduction of the -fcallgraph-info=su compiler option (line 62 here) is breaking builds on some platforms, notably the Raspberry Pi with an older version of gcc. Is this option essential?

[geky]

Hi @rtrussell, yes, -fcallgraph-info=su is entirely optional.

We just use it to get the necessary callgraph info for stack analysis (make stack). In a perfect world this should probably be a separate build rule, but GCC doesn't like it when the only output is not the binary...

A quick solution is to override CFLAGS with the exact set of flags you need:

$ CFLAGS='-g3 -I. -std=c99 -Wall -Wextra -pedantic -Os' make

We could add some extra Makefile flags to opt-out of -fcallgraph-info=su, though it may be more useful to try to figure out how to get callgraph info from only the ELF files (Dwarf?).

[rtrussell]

We could add some extra Makefile flags to opt-out of -fcallgraph-info=su, though it may be more useful to try to figure out how to get callgraph info from only the ELF files (Dwarf?).

It would be great if you could make the default not to use this option, then littlefs can be included as a submodule (as it is for example in PicoBB) without breaking the build on older compilers.

[geky]

The primary purpose of littlefs's Makefile is littlefs development, integration with external build systems is coincidental/secondary (and a can of worms). In that sense, providing stack measurements by default is more valuable.

Otherwise what should we do if we want to adopt more -Wwarnings that may not be available throughout the entire history of GCC?

[rtrussell]

The primary purpose of littlefs's Makefile is littlefs development, integration with external build systems is coincidental/secondary (and a can of worms).

So what is the preferred way for another project (in this case PicoBB) to incorporate littlefs? I would be very happy to recommend to the owner of PicoBB that he changes the way it has been integrated.

[geky]

Hmmm, I'm probably missing something, it doesn't look like PicoBB is using littlefs's Makefile?

https://github.com/Memotech-Bill/PicoBB/blob/b4b70caee33a54ce39dbcab523d62ede008baa1f/src/pico/Makefile#L138

This looks pretty reasonable integration-wise to me.

Do you know where the littlefs Makefile is getting invoked?

---

The other option, if you want an intermediary liblfs.a, would be to copy littlefs's Makefile into the application's repo and modify as needed. It can be a template but I think the key point is that the build rules for your application should be owned by the application.

But this is uncommon in this space. Most projects here are statically linked and often rely on LTO, so compiling/linking everything together in one pass is usually the way to go.

[geky]

Oh, it looks like littlefs's Makefile is being pulled in to build the mklfsimage tool?

https://github.com/Memotech-Bill/PicoBB/blob/master/src/lfsutil/Makefile

It's interesting to note they are already defining their own CFLAGS. Maybe it just needs $(MAKE) or export CLFAGS=*?

[rtrussell]

It's interesting to note they are already defining their own CFLAGS. Maybe it just needs $(MAKE) or export CLFAGS=*?

Thanks, I'll pass that on.

[e107steved]

Does littleFS even need a makefile of its own in an application? I just include littlefs.c in the list of sources to compile (OK, within a makefile dealing with file system-related stuff) and it has been working fine.

[geky]

Does littleFS even need a makefile of its own in an application?

Not really. The benefit of C99 being a standard is that you shouldn't usually need other context in order to compile the code.

But sometimes things can get complicated. If you're mixing multiple languages for example.

It's interesting to note ChaN's FAT impl doesn't even include a makefile at all: https://github.com/Memotech-Bill/PicoBB/tree/master/fatfs