bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
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
 

             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).