From: Paul Eggert <eggert@cs.ucla.edu>
To: Gnulib bugs <bug-gnulib@gnu.org>
Subject: _FILE_OFFSET_BITS problem on Solaris 10 due to new stdbool.h handling
Date: Sun, 22 Jan 2023 00:57:40 -0600 [thread overview]
Message-ID: <65ea1fb5-d901-1431-2a7c-aecff76cc93d@cs.ucla.edu> (raw)
[-- Attachment #1: Type: text/plain, Size: 123 bytes --]
I ran into a problem on Solaris 10 gcc when building bleeding-edge grep
and installed the attached into Gnulib to fix it.
[-- Attachment #2: stackvma.patch --]
[-- Type: text/x-patch, Size: 2687 bytes --]
diff --git a/ChangeLog b/ChangeLog
index d474155df7..61107c67fa 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,16 @@
+2023-01-22 Paul Eggert <eggert@cs.ucla.edu>
+
+ sigsegv, vma-iter: port to Solaris 10
+ On this platform, <sys/types.h> does not define off_t if neither
+ _LP64 nor _FILE_OFFSET_BITS is defined, which can happen if we
+ #undef _FILE_OFFSET_BITS. This became a problem with the new way
+ of doing stdbool, since config.h now includes <stdbool.h>, and
+ Solaris 10 <stdbool.h> includes <sys/feature_tests.h> which
+ arranges for _FILE_OFFSET_BITS to always be defined (if only to 32),
+ which <sys/types.h> assumes.
+ * lib/stackvma.c, lib/vma-iter.c (_FILE_OFFSET_BITS) [__sun && !_LP64]:
+ Define to 32 instead of leaving undefined.
+
2023-01-21 Bruno Haible <bruno@clisp.org>
login_tty: Ensure declaration in <utmp.h>.
diff --git a/lib/stackvma.c b/lib/stackvma.c
index 4408ca8e15..1224b7b07c 100644
--- a/lib/stackvma.c
+++ b/lib/stackvma.c
@@ -22,6 +22,7 @@
/* On Solaris in 32-bit mode, when gnulib module 'largefile' is in use,
prevent a compilation error
"Cannot use procfs in the large file compilation environment"
+ while also preventing <sys/types.h> from not defining off_t.
On Android, when targeting Android 4.4 or older with a GCC toolchain,
prevent a compilation error
"error: call to 'mmap' declared with attribute error: mmap is not
@@ -30,7 +31,11 @@
switch to Clang."
The files that we access in this compilation unit are less than 2 GB
large. */
-#if defined __sun || defined __ANDROID__
+#if defined __sun && !defined _LP64 && _FILE_OFFSET_BITS == 64
+# undef _FILE_OFFSET_BITS
+# define _FILE_OFFSET_BITS 32
+#endif
+#ifdef __ANDROID__
# undef _FILE_OFFSET_BITS
#endif
diff --git a/lib/vma-iter.c b/lib/vma-iter.c
index ccb221d273..2584d5ec34 100644
--- a/lib/vma-iter.c
+++ b/lib/vma-iter.c
@@ -20,6 +20,7 @@
/* On Solaris in 32-bit mode, when gnulib module 'largefile' is in use,
prevent a compilation error
"Cannot use procfs in the large file compilation environment"
+ while also preventing <sys/types.h> from not defining off_t.
On Android, when targeting Android 4.4 or older with a GCC toolchain,
prevent a compilation error
"error: call to 'mmap' declared with attribute error: mmap is not
@@ -28,7 +29,11 @@
switch to Clang."
The files that we access in this compilation unit are less than 2 GB
large. */
-#if defined __sun || defined __ANDROID__
+#if defined __sun && !defined _LP64 && _FILE_OFFSET_BITS == 64
+# undef _FILE_OFFSET_BITS
+# define _FILE_OFFSET_BITS 32
+#endif
+#ifdef __ANDROID__
# undef _FILE_OFFSET_BITS
#endif
next reply other threads:[~2023-01-22 6:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-22 6:57 Paul Eggert [this message]
2023-01-22 10:39 ` _FILE_OFFSET_BITS problem on Solaris 10 due to new stdbool.h handling Bruno Haible
2023-01-22 20:56 ` Paul Eggert
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
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=65ea1fb5-d901-1431-2a7c-aecff76cc93d@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=bug-gnulib@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: link
Be 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).