[std module] Building `std` module fails with _FORTIFY_SOURCE

[nmlgc]

Tested on a relatively current trunk, but exists since at least Clang 18:

clang version 20.0.0 (/home/nmlgc/aur/llvm-git/llvm-project 743c84bb9b79ed70d9bed926c2a173db3b30f587)
Target: x86_64-pc-linux-gnu
Thread model: posix

$ clang++ -O -D_FORTIFY_SOURCE -stdlib=libc++ -std=c++2c --precompile -Wno-reserved-module-identifier /usr/share/libc++/v1/std.cppm
In file included from /usr/share/libc++/v1/std.cppm:229:
/usr/share/libc++/v1/std/cstdio.inc:47:14: error: using declaration referring to 'snprintf' with internal linkage cannot be exported
   47 |   using std::snprintf _LIBCPP_USING_IF_EXISTS;
      |              ^
/usr/include/bits/stdio2.h:75:8: note: target of using declaration
   75 | __NTH (snprintf (__fortify_clang_overload_arg (char *, __restrict, __s),
      |        ^
In file included from /usr/share/libc++/v1/std.cppm:229:
/usr/share/libc++/v1/std/cstdio.inc:48:14: error: using declaration referring to 'sprintf' with internal linkage cannot be exported
   48 |   using std::sprintf _LIBCPP_USING_IF_EXISTS;
      |              ^
/usr/include/bits/stdio2.h:37:8: note: target of using declaration
   37 | __NTH (sprintf (__fortify_clang_overload_arg (char *, __restrict, __s),
      |        ^
In file included from /usr/share/libc++/v1/std.cppm:234:
/usr/share/libc++/v1/std/cwchar.inc:30:14: error: using declaration referring to 'swprintf' with internal linkage cannot be exported
   30 |   using std::swprintf _LIBCPP_USING_IF_EXISTS;
      |              ^
/usr/include/bits/wchar2.h:181:8: note: target of using declaration
  181 | __NTH (swprintf (__fortify_clang_overload_arg (wchar_t *, __restrict, __s),
      |        ^
3 errors generated.

_FORTIFY_SOURCE is part of the default CFLAGS of (at least) Arch Linux during package builds via makepkg, and would need to be manually removed to work with modules.

[llvmbot]

@llvm/issue-subscribers-clang-modules

Author: Nmlgc (nmlgc)

Tested on a relatively current trunk, but exists since at least Clang 18:

clang version 20.0.0 (/home/nmlgc/aur/llvm-git/llvm-project 743c84bb9b79ed70d9bed926c2a173db3b30f587)
Target: x86_64-pc-linux-gnu
Thread model: posix

$ clang++ -O -D_FORTIFY_SOURCE -stdlib=libc++ -std=c++2c --precompile -Wno-reserved-module-identifier /usr/share/libc++/v1/std.cppm
In file included from /usr/share/libc++/v1/std.cppm:229:
/usr/share/libc++/v1/std/cstdio.inc:47:14: error: using declaration referring to 'snprintf' with internal linkage cannot be exported
   47 |   using std::snprintf _LIBCPP_USING_IF_EXISTS;
      |              ^
/usr/include/bits/stdio2.h:75:8: note: target of using declaration
   75 | __NTH (snprintf (__fortify_clang_overload_arg (char *, __restrict, __s),
      |        ^
In file included from /usr/share/libc++/v1/std.cppm:229:
/usr/share/libc++/v1/std/cstdio.inc:48:14: error: using declaration referring to 'sprintf' with internal linkage cannot be exported
   48 |   using std::sprintf _LIBCPP_USING_IF_EXISTS;
      |              ^
/usr/include/bits/stdio2.h:37:8: note: target of using declaration
   37 | __NTH (sprintf (__fortify_clang_overload_arg (char *, __restrict, __s),
      |        ^
In file included from /usr/share/libc++/v1/std.cppm:234:
/usr/share/libc++/v1/std/cwchar.inc:30:14: error: using declaration referring to 'swprintf' with internal linkage cannot be exported
   30 |   using std::swprintf _LIBCPP_USING_IF_EXISTS;
      |              ^
/usr/include/bits/wchar2.h:181:8: note: target of using declaration
  181 | __NTH (swprintf (__fortify_clang_overload_arg (wchar_t *, __restrict, __s),
      |        ^
3 errors generated.

_FORTIFY_SOURCE is part of the default CFLAGS of (at least) Arch Linux during package builds via makepkg, and would need to be manually removed to work with modules.

[ChuanqiXu9]

From the error message, it looks this is a library issue. We indeed can't export declaration with internal linkage. Previously when we met such problems, we will refactor the source to declare functions from static inline to inline.

I think we need to contact with the providers of these functions to change the linkage of these functions.

Although this is not directly related to libc++, I add the libc++ tag to CC libc++ folks.

[frederick-vs-ja]

Seems because of that glibc incorrectly (?) marks some C standard libary functions static when compiling with Clang with _FORTIFY_SOURCE defined.

# define __fortify_function_error_function static __attribute__((__unused__))

Not sure whether we want workaround like that used in MSVC STL's <ctime>.

[ChuanqiXu9]

I feel, on the one hand, we need to submit an issue report to glibc. On the other hand, giving glibc is rarely updated for most users, it is better to do some workarounds.

[mordante]

We've seen this issue before with other C libraries. libc++ is an a different spot as MSVC STL, MSVC STL only needs to support on C library. For libc++ there are multiple C libraries used. So I'm not convinced adding workarounds is feasible.

@ChuanqiXu9 how do you feel about an attribute like ignore_internal_linkage? Then the compiler would diagnose the issue, but only as a warning. Then users can still include the required header and use modules.

[thesamesam]

I feel, on the one hand, we need to submit an issue report to glibc. On the other hand, giving glibc is rarely updated for most users, it is better to do some workarounds.

Please report a glibc bug first so their response can be seen, the link can be cited in commit messages / comments, and then it can be dropped eventually.

[mordante]

I feel, on the one hand, we need to submit an issue report to glibc. On the other hand, giving glibc is rarely updated for most users, it is better to do some workarounds.

Please report a glibc bug first so their response can be seen, the link can be cited in commit messages / comments, and then it can be dropped eventually.

Just FYI this is the third or fourth C standard library I've seen with this issue. I agree they should be fixed, but I like to be more robust against these libraries.

[ChuanqiXu9]

We've seen this issue before with other C libraries. libc++ is an a different spot as MSVC STL, MSVC STL only needs to support on C library. For libc++ there are multiple C libraries used. So I'm not convinced adding workarounds is feasible.

@ChuanqiXu9 how do you feel about an attribute like ignore_internal_linkage? Then the compiler would diagnose the issue, but only as a warning. Then users can still include the required header and use modules.

Maybe it is a good idea to make this a default behavior.

[mordante]

We've seen this issue before with other C libraries. libc++ is an a different spot as MSVC STL, MSVC STL only needs to support on C library. For libc++ there are multiple C libraries used. So I'm not convinced adding workarounds is feasible.
@ChuanqiXu9 how do you feel about an attribute like ignore_internal_linkage? Then the compiler would diagnose the issue, but only as a warning. Then users can still include the required header and use modules.

Maybe it is a good idea to make this a default behavior.

I'm not sure we want to do that since it violates [module.interface]/3. I would be less opposed to make this a compiler switch like we did for Wno-reserved-module-identifier. (Making it part of the same diagnostic seems a bit ugly, but would require no changes to build systems.)