Problem with out of the box

[riversedge]

I'm using Espressif-IDE (their prebuilt) 5.3. The LittleFS demo isn't working and it appears that it's because of the .c extension but trying to pull in the C++ string.h library from lfs_utils.h.

      clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -iwithsysroot/System/Library/Frameworks/System.framework/PrivateHeaders -iwithsysroot/Applications/Xcode.app/Conten
ts/Developer/Library/Frameworks/Python3.framework/Versions/3.9/Headers -arch arm64 -arch x86_64 -Werror=implicit-function-declaration -Wno-error=unreachable-code -DLFS_NO_DEBUG=1 -DLFS_NO_WARN=1 -DLFS_NO_ERROR=1 -DLFS_MULTIVERSION=1 -DLFS_NAME_MAX=1022 -Ilittlefs -I/Users/User/code/ESPIDE-Workspace/littlefs/build/littlefs_py_venv/include -I/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/Headers -c littlefs/lfs.c -o build/temp.macosx-10.9-universal2-cpython-39/littlefs/lfs.o -std=c99 -UNDEBUG
      In file included from littlefs/lfs.c:8:
      In file included from littlefs/lfs.h:11:
      littlefs/lfs_util.h:26:10: fatal error: 'string.h' file not found
      #include <string.h>
               ^~~~~~~~~~
      1 error generated.
      error: command '/Users/xxx/.espressif/tools/esp-clang/16.0.1-fe4f10a809/esp-clang/bin/clang' failed with exit code 1
      [end of output]

/*
 * lfs utility functions
 *
 * Copyright (c) 2022, The littlefs authors.
 * Copyright (c) 2017, Arm Limited. All rights reserved.
 * SPDX-License-Identifier: BSD-3-Clause
 */
#ifndef LFS_UTIL_H
#define LFS_UTIL_H

// Users can override lfs_util.h with their own configuration by defining
// LFS_CONFIG as a header file to include (-DLFS_CONFIG=lfs_config.h).
//
// If LFS_CONFIG is used, none of the default utils will be emitted and must be
// provided by the config file. To start, I would suggest copying lfs_util.h
// and modifying as needed.
#ifdef LFS_CONFIG
#define LFS_STRINGIZE(x) LFS_STRINGIZE2(x)
#define LFS_STRINGIZE2(x) #x
#include LFS_STRINGIZE(LFS_CONFIG)
#else

// System includes
#include <stdint.h>
#include <stdbool.h>
#include <string.h>
#include <inttypes.h>
...

[BrianPugh]

Seems like a not-esp_littlefs-specific environment issue, have you successfully compiled other projects using your environment? Just to be absolutely sure, I updated the CI in #198 to explicitly test building the example with esp-idf v5.3 (and it works fine).

[riversedge]

Yes, other projects will compile with their default Eclipse Esspressif-IDE solution. You're using the command line version of ESP-IDF then to build it?

The reason I reported it here is I'm unclear why the filename would be .c vs .cpp if it's intended to be a C++ compiled project. Seems that the environment is presuming .c file should be compiled a standard C which seems to be creating the issue.

[BrianPugh]

This port esp_littlefs and the main source littlefs are both pure C projects, that also work in c++ projects. I don't really work too much with c++, but AFAIK everything should work.

[riversedge]

It would appear that it's picking up the C++ string file instead. If I force the language mappings to use gnu C compiler instead then things compile. By default I think the .h files must get mapped to C++ header files based on the extension names.

https://en.cppreference.com/w/cpp/header/cstring

I think the right way to fix this to be both C and C++ compatible would be something like this:

#ifdef __cplusplus
#include <cstring>
#else
#include <string.h>
#endif

or

#ifdef __cplusplus
extern "C" {
#endif
#include <string.h>
#ifdef __cplusplus
}
#endif

Maybe wrapping an extended portion of the library that way.

[riversedge]

Another side that might be of interest to those stumbling on this thread, there might be an issue with the default MacOS python3 driving some of this. The default /usr/bin/python3 version is 3.9.6 but if you install the brew 3.12.4 version and force ESP-IDF to use that instead then it seems to compile out of the box.

I'm not sure why that makes a difference. The generated file is the same, but for some reason it seems to be impacting how the compiler/linker behave too. That might be why the CI test created earlier ran fine too.

I did notice that the extern "C" doesn't wrap the header file includes in the generated files, which might address the problem regardless. At any rate - maybe that will help others. Appreciate the help!

[BrianPugh]

thanks for the follow up! Just to clarify, is any action required on my part? The esp_littlefs header has the cpp guard, as does littlefs.

[riversedge]

The header includes are outside the extern "C" guard in the file I saw generated. I'm thinking that for better compliance on a strict compiler that including them within that wrapper would probably help. I have no idea why the python version makes a difference, but at least gives people another option to handle.