From: Paul Eggert <eggert@cs.ucla.edu>
To: 18368@debbugs.gnu.org
Subject: bug#18368: HYBRID_MALLOC broke AIX build
Date: Sat, 30 Aug 2014 15:50:30 -0700 [thread overview]
Message-ID: <54025536.7010803@cs.ucla.edu> (raw)
The trunk's recent HYBRID_MALLOC changes broke the build on AIX. Here
are the first couple of compile-time diagnostics:
xlc -c -Demacs -I. -I. -I../lib -I../lib -g3 -O gmalloc.c
"/usr/include/unistd.h", line 201.17: 1506-343 (S) Redeclaration of
lseek64 differs from previous declaration on line 199 of
"/usr/include/unistd.h".
"/usr/include/unistd.h", line 201.17: 1506-050 (I) Return type "long
long" in redeclaration is not compatible with the previous return type
"long".
The culprit is this part of gmalloc.c:
/* If HYBRID_MALLOC is defined in config.h, then conf_post.h #defines
malloc and friends as macros before including stdlib.h. In this
file we will need the prototypes for the system malloc, so we must
include stdlib.h before config.h. And we have to do this
unconditionally, since HYBRID_MALLOC hasn't been defined yet. */
#include <stdlib.h>
#include <config.h>
This doesn't work, as <config.h> must come first for various reasons; I
suspect the AIX breakage is just the tip of the iceberg.
One possible fix is to declare the system malloc directly, if
HYBRID_MALLOC is defined. Another one, which might be safer, is to
modify config.h to capture the system malloc before it's redefined.
Since AIX does not define HYBRID_MALLOC, I have temporarily worked
around the problem on my AIX host by using this in gmalloc.c:
#ifdef HYBRID_MALLOC
#include <stdlib.h>
#endif
#include <config.h>
#include <stdlib.h>
but I suspect this is not the right way to fix the problems on platforms
that need HYBRID_MALLOC but have AIX-like problems with redefinitions.
next reply other threads:[~2014-08-30 22:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-30 22:50 Paul Eggert [this message]
2014-08-31 1:41 ` bug#18368: HYBRID_MALLOC broke AIX build Ken Brown
2014-08-31 2:21 ` Paul Eggert
2014-08-31 2:42 ` Ken Brown
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://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54025536.7010803@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=18368@debbugs.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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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).