all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: emacs-devel@gnu.org
Cc: bug-gnulib <bug-gnulib@gnu.org>,
	7856@debbugs.gnu.org, 7859@debbugs.gnu.org
Subject: bug#7856: syncing Emacs from sources maintained elsewhere
Date: Wed, 19 Jan 2011 02:38:59 -0800	[thread overview]
Message-ID: <4D36BF43.3050007__5682.28888228095$1295434496$gmane$org@cs.ucla.edu> (raw)
In-Reply-To: <25y66hjmiu.fsf@fencepost.gnu.org>

I got a copy of preprocessed sources from bryan d. o'connor.
Here's what seems to be the problem:

* <config.h> has "#define __GETOPT_PREFIX rpl_" as expected.

* unexmacosx.c includes the Gnulib <unistd.h>.

* The Gnulib <unistd.h> includes the system unistd.h, which declares
  the getopt-related names itself (without including anything) and then finishes.

* The Gnulib <unistd.h> then includes the Gnulib <getopt.h>.

* The Gnulib <getopt.h> includes the system getopt.h.

* The system getopt.h includes the Gnulib <unistd.h>.

* This inner Gnulib <unistd.h> does nothing, and finishes.

* The system getopt.h declares 'struct option' and other stuff, and finishes.

* The Gnulib <getopt.h> then does this:

     #if defined __GETOPT_PREFIX && !defined __need_getopt
     # if !@HAVE_GETOPT_H@
     #  include <stdlib.h>
     #  include <stdio.h>
     #  include <unistd.h>
     # endif
     # undef __need_getopt
     ...
     # undef option
     # define __GETOPT_CONCAT(x, y) x ## y
     # define __GETOPT_XCONCAT(x, y) __GETOPT_CONCAT (x, y)
     # define __GETOPT_ID(y) __GETOPT_XCONCAT (__GETOPT_PREFIX, y)
     ...
     # define option __GETOPT_ID (option)
     ...
     #endif

* This should "#define option rpl_option", but apparently it doesn't.

* Presumably __GETOPT_PREFIX is defined, but __need_getopt is also defined,
  so the entire #if is skipped.

* And when Gnulib <getopt.h> declares a 'struct option', this clashes
  with the 'struct option' declared in the system getopt.h.
       
If my analysis is right, we need to figure out why __need_getopt is
defined.  Can you send the output of the following?

cd emacs
grep -r __need_getopt . /usr/include


PS.  This all seems to be a case where we should be using Gnulib's
identifier replacement mechanism, but I don't understand it that
well and if memory serves it doesn't work with struct tags anyway.





  parent reply	other threads:[~2011-01-19 10:38 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-11  0:50 syncing Emacs from sources maintained elsewhere Paul Eggert
2011-01-11  1:38 ` Miles Bader
2011-01-11  4:39   ` Paul Eggert
2011-01-17 20:37 ` Paul Eggert
2011-01-17 21:35   ` Stefan Monnier
2011-01-17 22:12     ` Paul Eggert
2011-01-18 10:11   ` Andy Moreton
2011-01-18 15:20     ` Eli Zaretskii
2011-01-18 18:13       ` Paul Eggert
2011-01-18 22:57         ` Eli Zaretskii
2011-01-19  0:36           ` Paul Eggert
2011-01-19 15:03             ` Eli Zaretskii
2011-01-19  1:20         ` Glenn Morris
2011-01-19  6:04           ` Paul Eggert
     [not found]             ` <4D368D16.7020702@swipnet.se>
2011-01-19  9:00               ` Glenn Morris
2011-01-19 10:38                 ` Paul Eggert
2011-01-19 15:54                   ` bug#7856: bug#7859: " Jan Djärv
2011-01-19 15:54                   ` Jan Djärv
2011-01-19 23:44                     ` bug#7856: " Paul Eggert
2011-01-19 23:44                     ` Paul Eggert
2011-01-20  0:21                       ` Eli Zaretskii
2011-01-20  0:21                       ` Eli Zaretskii
2011-01-20  6:45                       ` Jan Djärv
2011-01-20  6:45                       ` bug#7856: " Jan Djärv
2011-01-20  6:45                       ` Jan Djärv
2011-01-20  7:51                         ` Paul Eggert
2011-01-20 11:26                           ` Jan D.
2011-01-20 11:26                           ` bug#7856: " Jan D.
2011-01-20 11:26                           ` Jan D.
2011-01-20  7:51                         ` Paul Eggert
2011-01-20  7:51                         ` bug#7856: " Paul Eggert
2011-01-19 23:44                     ` Paul Eggert
2011-01-19 23:49                     ` Paul Eggert
2011-01-20  2:30                       ` Tom Tromey
2011-01-19 15:54                   ` Jan Djärv
2011-01-20  0:27                   ` bug#7856: " Eric Blake
2011-01-20  0:27                   ` bug#7859: " Eric Blake
2011-01-20  0:27                   ` Eric Blake
2011-01-19 10:38                 ` bug#7859: " Paul Eggert
2011-01-19 10:38                 ` Paul Eggert [this message]
2011-01-19  6:04           ` bug#7856: " Paul Eggert
2011-01-19  6:04           ` bug#7859: " Paul Eggert
2011-01-23 12:39         ` Eli Zaretskii
2011-01-23 20:38           ` Paul Eggert
2011-01-24  4:08             ` Eli Zaretskii
2011-01-24 23:48               ` Paul Eggert
2011-01-25  4:02                 ` Eli Zaretskii
2011-01-26 15:43                 ` Eli Zaretskii
2011-01-27  9:22                   ` Paul Eggert
2011-01-27  9:55                     ` Eli Zaretskii
2011-01-27 10:29                       ` Bruno Haible
2011-01-28 10:09                         ` Eli Zaretskii
2011-01-28 21:06                           ` Paul Eggert
2011-01-28 22:36                             ` Eli Zaretskii
2011-01-28 22:40                               ` Eric Blake
2011-01-29  8:48                                 ` Eli Zaretskii
2011-01-29  9:32                                   ` Simon Josefsson
2011-01-29 10:24                                     ` Eli Zaretskii
2011-01-27 20:50                       ` gnulib strftime, Emacs, and nanosecond-resolution time stamps Paul Eggert
2011-01-24  6:18             ` syncing Emacs from sources maintained elsewhere Ralf Wildenhues
2011-01-29 10:04             ` Eli Zaretskii
2011-01-31  8:19               ` Paul Eggert
2011-01-29 12:53     ` Eli Zaretskii
2011-01-29 15:46       ` Chong Yidong

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='4D36BF43.3050007__5682.28888228095$1295434496$gmane$org@cs.ucla.edu' \
    --to=eggert@cs.ucla.edu \
    --cc=7856@debbugs.gnu.org \
    --cc=7859@debbugs.gnu.org \
    --cc=bug-gnulib@gnu.org \
    --cc=emacs-devel@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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.