From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Cc: Joel Brobecker <brobecker@adacore.com>
Subject: [RFA/Python] Fix procfs.c build failure on 32bit solaris (_FILE_OFFSET_BITS)
Date: Tue, 23 Nov 2010 01:14:00 -0000 [thread overview]
Message-ID: <1290474834-1945-1-git-send-email-brobecker@adacore.com> (raw)
This is a bit ugly...
A recent change introduced the include of "python-internal.h" from
inside breakpoint.h. This in turn affected procfs.c:
| In file included from /usr/include/sys/procfs.h:29:0,
| from ../../src/gdb/core-regset.c:42:
| /usr/include/sys/old_procfs.h:39:2: error: #error "Cannot use procfs in the large file compilation environment"
What happens is that _FILE_OFFSET_BITS gets unconditionally re-defined
by pyconfig.h to a value that procfs.c does not support. So far, we were
able to get by with the following #undef:
/* On sparc-solaris, /usr/include/sys/feature_tests.h defines
_FILE_OFFSET_BITS, which pyconfig.h also defines. Same work
around technique as above. */
#undef _FILE_OFFSET_BITS
...because procfs.c never included Python, even indirectly. But this
is no longer sufficient, because the indirect dependency causes procfs.c
to get a value of _FILE_OFFSET_BITS that it does not support.
As I was looking at this, I looked at the configure script in Python 2.7,
and it appears that disabling large-file support is not possible.
Regardless of that, I think we want to be able to build GDB against
pre-built versions of Python if we can...
So the fix I applied was to make sure we restore the initial value
of _FILE_OFFSET_BITS after having included Python.h.
gdb/ChangeLog:
* python/python-internal.h (_FILE_OFFSET_BITS): Restore initial value
after having included "Python.h".
It fixes the problem on sparc-solaris. Tested on x86_64-linux.
OK to commit?
---
gdb/python/python-internal.h | 18 ++++++++++++++++--
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/gdb/python/python-internal.h b/gdb/python/python-internal.h
index 30d7533..026a05a 100644
--- a/gdb/python/python-internal.h
+++ b/gdb/python/python-internal.h
@@ -37,9 +37,16 @@
#undef _XOPEN_SOURCE
/* On sparc-solaris, /usr/include/sys/feature_tests.h defines
- _FILE_OFFSET_BITS, which pyconfig.h also defines. Same work
- around technique as above. */
+ _FILE_OFFSET_BITS, which pyconfig.h also defines. We cannot apply
+ the same technique as above, because the actual value is important.
+ If we let Python define _FILE_OFFSET_BITS to a value that is not
+ compatible with procfs, we will get a compilation error while trying
+ to include sys/procfs.h. To avoid that, we save the current value,
+ and restore it after Python.h has been included. */
+#ifdef _FILE_OFFSET_BITS
+#define OLD_FILE_OFFSET_BITS _FILE_OFFSET_BITS
#undef _FILE_OFFSET_BITS
+#endif
#if HAVE_LIBPYTHON2_4
#include "python2.4/Python.h"
@@ -62,6 +69,13 @@ typedef int Py_ssize_t;
#error "Unable to find usable Python.h"
#endif
+/* Restore the original _FILE_OFFSET_BITS value if applicable. */
+#ifdef OLD_FILE_OFFSET_BITS
+#undef _FILE_OFFSET_BITS
+#define _FILE_OFFSET_BITS OLD_FILE_OFFSET_BITS
+#undef OLD_FILE_OFFSET_BITS
+#endif
+
/* If Python.h does not define WITH_THREAD, then the various
GIL-related functions will not be defined. However,
PyGILState_STATE will be. */
--
1.7.1
next reply other threads:[~2010-11-23 1:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-23 1:14 Joel Brobecker [this message]
2010-11-23 3:25 ` Jan Kratochvil
2010-11-23 12:42 ` Pedro Alves
2010-11-23 15:22 ` Tom Tromey
2010-11-23 16:29 ` Pedro Alves
2010-11-23 17:23 ` Phil Muldoon
2010-11-23 17:47 ` Pedro Alves
2010-11-24 17:20 ` Joel Brobecker
2010-11-25 13:12 ` Pedro Alves
2010-11-24 18:25 ` Tom Tromey
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=1290474834-1945-1-git-send-email-brobecker@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.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