Potential Regression on #4189: Incorrectly attempting to link `flockfile`

[mvastola]

Hi,
So I'm running into the same issue identified in #4189. I'm trying to compile fmt for use on a Raspberry Pi Pico 2 (with the official pico-sdk). I'm using the latest release (12.1.0).

I'm assuming the issue has to do with the function being defined in the headers but not any of the linked libraries (as this is for a micro-controller without an OS or, thus, any filesystems).

If there isn't a way to properly disable this using existing compile flags/checks, can one be added?
As a workaround I'm currently just commenting out these lines:

fmt/include/fmt/format-inl.h

Lines 1481 to 1483 in 407c905

	template <typename F>
	struct has_flockfile<F, void_t<decltype(flockfile(&std::declval<F&>()))>>
	: std::true_type {};

---

As a potential aside (not sure if it's relevant), I'm having a bit of difficulty fully debugging the issue because I can see the enable_if-style guard for has_flockfile checks for the existence of the f(un)lockfile functions, but functions of this name are literally defined within fmt, so I'm honestly not sure if it's the standard library headers or fmt itself that is creating the belief the f(un)lockfile functions exist.

I also can't make heads or tails of the functions within fmt of that name because they depend on functions named _(un)lock_file, and I wasn't able to figure out where they are supposed to be defined.

fmt/include/fmt/format-inl.h

Lines 1465 to 1470 in 407c905

	template <typename F> auto flockfile(F* f) -> decltype(_lock_file(f)) {
	_lock_file(f);
	}
	template <typename F> auto funlockfile(F* f) -> decltype(_unlock_file(f)) {
	_unlock_file(f);
	}

[vitaut]

Please post the full error that you get.

[vitaut]

Most likely your system defines flockfile but doesn't provide an implementation - I think we've seen a broken system like this in the past. You can disable the file locking functionality by compiling with the FMT_USE_FALLBACK_FILE macro defined to 1.

[vitaut]

Closing since it doesn't look like a bug in {fmt} and there is a way to workaround it on problematic systems.

[mvastola]

@vitaut,
Sorry for the delay, but this is the error I'm getting.

/usr/lib/gcc/arm-none-eabi/14.2.1/../../../arm-none-eabi/bin/ld: ../_deps/fmt-build/libfmtd.a(format.cc.o): in function `fmt::v12::detail::file_print_buffer<__sFILE, void>::file_print_buffer(__sFILE*)':
/home/mvastola/src/Pico2-MultiTool/.cache/cpm-sources/fmt/c411/fmt/include/fmt/format-inl.h:1683:(.text._ZN3fmt3v126detail17file_print_bufferI7__sFILEvEC2EPS3_[_ZN3fmt3v126detail17file_print_bufferI7__sFILEvEC5EPS3_]+0x24): undefined reference to `flockfile'
/usr/lib/gcc/arm-none-eabi/14.2.1/../../../arm-none-eabi/bin/ld: ../_deps/fmt-build/libfmtd.a(format.cc.o): in function `fmt::v12::detail::file_print_buffer<__sFILE, void>::~file_print_buffer()':
/home/mvastola/src/Pico2-MultiTool/.cache/cpm-sources/fmt/c411/fmt/include/fmt/format-inl.h:1692:(.text._ZN3fmt3v126detail17file_print_bufferI7__sFILEvED2Ev[_ZN3fmt3v126detail17file_print_bufferI7__sFILEvED5Ev]+0x3c): undefined reference to `funlockfile'

If it matters, I'm using fmt via CPM. This is how I'm trying to add it.

CPMAddPackage(
  NAME fmt
  GIT_TAG 12.1.0
  GITHUB_REPOSITORY "fmtlib/fmt"
  OPTIONS
    EXCLUDE_FROM_ALL
    "FMT_SYSTEM_HEADERS ON"
    "FMT_UNICODE OFF"
    "FMT_OS OFF" # disable using os libraries
    "FMT_MODULE OFF"
    "FMT_TEST OFF"
    "CMAKE_BUILD_TYPE Debug"
    "BUILD_SHARED_LIBS OFF"
    "FMT_INSTALL OFF"
    "FMT_LIB_EXPORT ON"
    "FMT_USE_CMAKE_MODULES ON"
    "FMT_USE_FALLBACK_FILE 1"
    "CMAKE_CXX_FLAGS -DFMT_USE_FALLBACK_FILE=1"
    "CMAKE_VERBOSE_MAKEFILE ON"
  PATCHES
#    "${TOPLEVEL}/cmake/patches/fmt-disable-flock.diff"
    "${TOPLEVEL}/cmake/patches/fmt-constexpr-static-format.diff" # fixed in next release
     "${TOPLEVEL}/cmake/patches/fmt-test-error.diff"
)
target_compile_definitions(fmt INTERFACE FMT_USE_FALLBACK_FILE=1)
target_compile_definitions(fmt PUBLIC FMT_USE_FALLBACK_FILE=1)

As for the patch files, this is fmt-disable-flock.diff (which prevents the error):

diff --git a/include/fmt/format-inl.h b/include/fmt/format-inl.h
index 945cb91..ba19164 100644
--- a/include/fmt/format-inl.h
+++ b/include/fmt/format-inl.h
@@ -1478,9 +1478,9 @@ template <typename F> auto getc_unlocked(F* f) -> decltype(_fgetc_nolock(f)) {
 template <typename F = FILE, typename Enable = void>
 struct has_flockfile : std::false_type {};

-template <typename F>
-struct has_flockfile<F, void_t<decltype(flockfile(&std::declval<F&>()))>>
-    : std::true_type {};
+//template <typename F>
+//struct has_flockfile<F, void_t<decltype(flockfile(&std::declval<F&>()))>>
+//    : std::true_type {};

 // A FILE wrapper. F is FILE defined as a template parameter to make system API
 // detection work.

This is fmt-test-error.diff, which is diff I created to ensure FMT_USE_FALLBACK_FILE is being set.

diff --git a/include/fmt/format-inl.h b/include/fmt/format-inl.h
index 945cb912..49aaf5b3 100644
--- a/include/fmt/format-inl.h
+++ b/include/fmt/format-inl.h
@@ -1475,6 +1475,9 @@ template <typename F> auto getc_unlocked(F* f) -> decltype(_fgetc_nolock(f)) {
 }
 #endif

+#if !FMT_USE_FALLBACK_FILE
+#error FMT_USE_FALLBACK_FILE is not set
+#endif
 template <typename F = FILE, typename Enable = void>
 struct has_flockfile : std::false_type {};

As an aside, is there any way FMT_USE_FALLBACK_FILE (or something similar) could be made a CPM-compatible config option? Something I noticed was that I needed to manually set

target_compile_definitions(fmt PUBLIC FMT_USE_FALLBACK_FILE=1)

to ensure fmt/format-inl.h was only ever included with FMT_USE_FALLBACK_FILE.

To be clear though, I'm getting the linker error even with that target_compile_definitions(fmt PUBLIC ...) line.

(FWIW, I can't figure out why the INTERFACE definition doesn't work by itself, but that's a separate issue.)

[vitaut]

Ah, you are right - FMT_USE_FALLBACK_FILE is insufficient to remove the use of flockfile. I think we should add a separate macro to control it, FMT_USE_FLOCKFILE, to force the has_flockfile trait to false even if there is a declaration of flockfile. A PR to do it is welcome.

As an aside, is there any way FMT_USE_FALLBACK_FILE (or something similar) could be made a CPM-compatible config option?

I am not familiar with CPM. Do you mean adding a CMake option in addition to the macro?

[mvastola]

Ah, you are right - FMT_USE_FALLBACK_FILE is insufficient to remove the use of flockfile. I think we should add a separate macro to control it, FMT_USE_FLOCKFILE, to force the has_flockfile trait to false even if there is a declaration of flockfile. A PR to do it is welcome.

Cool. I'll try my hand at a PR then.

I am not familiar with CPM. Do you mean adding a CMake option in addition to the macro?

My bad, I thought CPM was officially supported (I think they give an example of using fmt rather than the reverse.) But yes, that's part of it. The other part is making it so when this library is built with FMT_USE_FALLBACK_FILE and imported into another CMake project,

target_compile_definitions(fmt PUBLIC FMT_USE_FALLBACK_FILE=1)

or its equivalent comes pre-set.

[mvastola]

To clarify, would FMT_USE_FLOCKFILE be set to 0 (and therefore default to 1) to force has_flockfile to false? I'm a little confused by the naming.

Could you also please explain what FMT_USE_FALLBACK_FILE is intended to do? (For the CMake option description, as well as so I can understand haha).

Thanks,
Mike

[vitaut]

To clarify, would FMT_USE_FLOCKFILE be set to 0 (and therefore default to 1) to force has_flockfile to false?

Yes

Let's not introduce CMake options yet. FMT_USE_FALLBACK_FILE disables detection of known FILE layouts and related optimizations.

[mvastola]

Ah ok. Then the PR is pretty trivial. Will be done in 5.