public inbox for libstdc++-cvs@sourceware.org help / color / mirror / Atom feed
From: Jonathan Wakely <redi@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org, libstdc++-cvs@gcc.gnu.org Subject: [gcc r11-10580] libstdc++: Horrible macro hacks to allow building on avr Date: Thu, 16 Mar 2023 16:51:22 +0000 (GMT) [thread overview] Message-ID: <20230316165122.B8327385B520@sourceware.org> (raw) https://gcc.gnu.org/g:061700c9f6f0f9f4219ddeb236d55764b42869b6 commit r11-10580-g061700c9f6f0f9f4219ddeb236d55764b42869b6 Author: Jonathan Wakely <jwakely@redhat.com> Date: Thu Feb 2 18:03:26 2023 +0000 libstdc++: Horrible macro hacks to allow building on avr In r12-4071-g59ffa3e3dba5a7 I added a new __unsupported() function and replaced all std::filesystem's uses of std::errc::not_supported and ENOTSUP with a call to that function. Then in r13-5664-g5c43f06c228d16 that function was tweaked to use ENOSYS instead of EOPNOTSUP for avr, due to limitations of <errno.h> on avr-libc. In the gcc-11 branch we don't have __unsupported(), so we get loads and loads of failures when trying to compile the src/c++17/fs_*.cc files. This horrible hack uses macros to redefine not_supported and ENOTSUP as function_not_supported and ENOSYS respectively, to fix the build for avr. libstdc++-v3/ChangeLog: * src/c++17/fs_ops.cc [AVR] (not_supported): Define as a macro for function_not_supported. * src/filesystem/ops-common.h [AVR] (ENOTSUP): Define as a macro for ENOSYS. Diff: --- libstdc++-v3/src/c++17/fs_ops.cc | 4 ++++ libstdc++-v3/src/filesystem/ops-common.h | 4 ++++ 2 files changed, 8 insertions(+) diff --git a/libstdc++-v3/src/c++17/fs_ops.cc b/libstdc++-v3/src/c++17/fs_ops.cc index 4155b4d64b9..802894ea5b5 100644 --- a/libstdc++-v3/src/c++17/fs_ops.cc +++ b/libstdc++-v3/src/c++17/fs_ops.cc @@ -61,6 +61,10 @@ #define _GLIBCXX_END_NAMESPACE_FILESYSTEM } #include "../filesystem/ops-common.h" +#ifdef __AVR__ +# define not_supported function_not_supported +#endif + #pragma GCC diagnostic ignored "-Wunused-parameter" namespace fs = std::filesystem; diff --git a/libstdc++-v3/src/filesystem/ops-common.h b/libstdc++-v3/src/filesystem/ops-common.h index 54bafff2a9c..a680a51c984 100644 --- a/libstdc++-v3/src/filesystem/ops-common.h +++ b/libstdc++-v3/src/filesystem/ops-common.h @@ -170,6 +170,10 @@ namespace __gnu_posix # endif using char_type = char; #else // ! _GLIBCXX_FILESYSTEM_IS_WINDOWS && ! _GLIBCXX_HAVE_UNISTD_H +#ifdef __AVR__ +# define ENOTSUP ENOSYS +#endif + inline int open(const char*, int, ...) { errno = ENOTSUP; return -1; } inline int close(int) { errno = ENOTSUP; return -1; } using mode_t = int;
reply other threads:[~2023-03-16 16:51 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20230316165122.B8327385B520@sourceware.org \ --to=redi@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ --cc=libstdc++-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).