make bootstrap: need moral support. :-(

make bootstrap: need moral support. :-(

[Alan Mackenzie]

Hi, Emacs!

I've got CC Mode 5.31.3 ready for merging into the Emacs CVS.  First, I
should be testing it on an up to date Emacs 22.

So, I cvs updated my copy of CVS Emacs this morning.  I followed this
with a ./configure and a make bootstrap.  It failed in process.c with a
"dereferencing pointer to incomplete type" error, whatever that is.

I also cvs updated back on 28th November.  My make failed then too, and I
never got round to fixing it.

I originally cvs checkedout my CVS Emacs on 9th September last year.  It
built then, though not without effort.  So all my testing on CVS Emacs is
on the version from September last year.

I've got gcc 2.95.3 and make 3.79.1.  Surely they should build Emacs OK?
Surely?

Right now, I've got that "Oh my goodness, do I have to go through all
_this_ yet again?" feeling about this.  That I've got several hours or
even days of drudgery, just to get Emacs to build - That I'll track down
the first error, fix it (with perhaps some little tweak in my ./configure
options, or #undefining some option, or), then stumble across the next
glitsch, ....., and a week later, perhaps, I'll have an up to date
working CVS Emacs.

Surely, things shouldn't be like this.  Are things really like this, or
am I just being unlucky at the moment?  Do other people have this ghastly
experience too, or do most of you hit the <CR> on "make bootstrap" or the
like with the expectation that it's "probably going to build OK, no
sweat"?  Or do I need some magic parameters to my ./configure?

Would somebody cheer me up, please.

-- 
Alan Mackenzie (Munich, Germany)

Re: make bootstrap: need moral support. :-(

[Giorgos Keramidas]

On 2006-02-19 15:07, Alan Mackenzie <acm@muc.de> wrote:
> Hi, Emacs!
>
> I've got CC Mode 5.31.3 ready for merging into the Emacs CVS.  First, I
> should be testing it on an up to date Emacs 22.
>
> So, I cvs updated my copy of CVS Emacs this morning.  I followed this
> with a ./configure and a make bootstrap.  It failed in process.c with a
> "dereferencing pointer to incomplete type" error, whatever that is.

Strange.  I just rebuilt an Emacs snapshot on FreeBSD/amd64, but I don't
see incomplete type dereferencing errors.

How are you checking out your copy?

Does the environment contain any special CFLAGS when you run ./configure?

> I also cvs updated back on 28th November.  My make failed then too, and I
> never got round to fixing it.

This indicates a local environment problem, IMHO.  Can you send the
output of:

    $ env | sort

right before you run `./configure'?

> I originally cvs checkedout my CVS Emacs on 9th September last year.  It
> built then, though not without effort.  So all my testing on CVS Emacs is
> on the version from September last year.
>
> I've got gcc 2.95.3 and make 3.79.1.  Surely they should build Emacs OK?
> Surely?

Hmmm, not sure.  I'm using gcc-3.4.4 here; the one that comes with
FreeBSD-CURRENT as the base-system compiler & toolchain.

> Right now, I've got that "Oh my goodness, do I have to go through all
> _this_ yet again?" feeling about this.  That I've got several hours or
> even days of drudgery, just to get Emacs to build - That I'll track down
> the first error, fix it (with perhaps some little tweak in my ./configure
> options, or #undefining some option, or), then stumble across the next
> glitsch, ....., and a week later, perhaps, I'll have an up to date
> working CVS Emacs.
>
> Surely, things shouldn't be like this.  Are things really like this, or
> am I just being unlucky at the moment?

No, things are pretty stable here.  I've been building Emacs CVS
snapshot since last October on FreeBSD 7.0-CURRENT.  The only problem
that I have to track down is why enabling HAVE_POSIX_MEMALIGN in
src/config.h crashes at bootstrap time.

Without HAVE_POSIX_MEMALIGN, current Emacs builds are stable enough for
months in a row now.

> Do other people have this ghastly experience too, or do most of you
> hit the <CR> on "make bootstrap" or the like with the expectation that
> it's "probably going to build OK, no sweat"?  Or do I need some magic
> parameters to my ./configure?
>
> Would somebody cheer me up, please.

It's probably a local environment option that's causing all this.  We'll
find out what it is and fix it -- don't worry :)

- Giorgos

Re: make bootstrap: need moral support. :-(

[Robert J. Chassell]

    ... or am I just being unlucky at the moment?

You are just being unlucky.  I updated CVS at 11:44 UTC this morning, 
2006 Feb 19, and built it with

     (progn (cd "/usr/local/src/emacs/") (compile "time make bootfast"))

It built fine.  I did use gcc 4.0.3 but not long ago, I used gcc 2.95.
I am also using GNU Make 3.81beta4, but I expect that make 3.79.1
would work.

(I presume that the slower

     (progn
       (cd "/usr/local/src/emacs/")
       (compile
        "./configure --with-type1 --with-x-toolkit=gtk \
         --prefix=/usr/local --with-sound=yes && \
         time make bootstrap && date"))

would also work, but I try to avoid `make bootstrap' whenever I can
because it is slow.  Every so often, I have to

     (progn (cd "/usr/local/src/emacs/") (compile "make maintainer-clean"))

before running `make bootstrap'.)

Occasionally, I cannot built successfully, but truthfully, that is
fairly rare.  Generally, I build once a day, start an instance of it
with `emacs/src/emacs -Q -D', and run a brief test.  Once in a while,
I remember to launch a new instance that I use regularly (loading my
.emacs file). That gives that day's CVS a good work out over the next
several weeks.

I complain once in a while, but in fact, people are pretty good about
checking that a change they commit works (or else they are good
programmers :-)

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: make bootstrap: need moral support. :-(

[Miles Bader]

"Robert J. Chassell" <bob@rattlesnake.com> writes:
> Occasionally, I cannot built successfully, but truthfully, that is
> fairly rare.

Yeah me too ... I update from CVS pretty randomly and I'd estimate that
it doesn't build around 5% of the time.  Not often enough to have
induced me to change my habits, anyway...

-Miles
-- 
"1971 pickup truck; will trade for guns"

Re: make bootstrap: need moral support. :-(

[Randal L. Schwartz]

>>>>> "Robert" == Robert J Chassell <bob@rattlesnake.com> writes:

Robert>     ... or am I just being unlucky at the moment?
Robert> You are just being unlucky.  I updated CVS at 11:44 UTC this morning, 
Robert> 2006 Feb 19, and built it with

Robert>      (progn (cd "/usr/local/src/emacs/") (compile "time make bootfast"))

Robert> It built fine.  I did use gcc 4.0.3 but not long ago, I used gcc 2.95.
Robert> I am also using GNU Make 3.81beta4, but I expect that make 3.79.1
Robert> would work.

I built from CVS just now on OSX with:

        make distclean
        ./configure --prefix=/opt/emacs --without-x
        make bootstrap install

and died with:

/emacs-CVS/lib-src/../src  -fpascal-strings -DMAC_OSX -I../mac/src   -g -O2 -Wno-pointer-sign  -DVERSION="\"22.0.50\"" /Users/merlyn/MIRROR/emacs-CVS/lib-src/etags.c getopt.o getopt1.o regex.o  -o etags
/usr/bin/ld: Undefined symbols:
_xmalloc
_xrealloc
collect2: ld returned 1 exit status
make[3]: *** [etags] Error 1
make[2]: *** [lib-src] Error 2
make[1]: *** [bootstrap-build] Error 2
make: *** [bootstrap] Error 2
make bootstrap install  856.14s user 189.33s system 40% cpu 43:07.15 total

This is definitely recent.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: make bootstrap: need moral support. :-(

[Michael Price]

[-- Attachment #1: Type: text/plain, Size: 991 bytes --]

On 20 Feb 2006 07:24:28 -0800, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
> I built from CVS just now on OSX with:
>
>         make distclean
>         ./configure --prefix=/opt/emacs --without-x
>         make bootstrap install
>
> and died with:
>
> /emacs-CVS/lib-src/../src  -fpascal-strings -DMAC_OSX -I../mac/src   -g -O2 -Wno-pointer-sign  -DVERSION="\"22.0.50\"" /Users/merlyn/MIRROR/emacs-CVS/lib-src/etags.c getopt.o getopt1.o regex.o  -o etags
> /usr/bin/ld: Undefined symbols:
> _xmalloc
> _xrealloc
> collect2: ld returned 1 exit status
> make[3]: *** [etags] Error 1
> make[2]: *** [lib-src] Error 2
> make[1]: *** [bootstrap-build] Error 2
> make: *** [bootstrap] Error 2
>
> This is definitely recent.

I compile emacs from cvs on a Mac several times a week and had no
problems for the last few months until this weekend when I started
getting the same error you describe above. Anyone know how to fix
this?

I'm running 10.4.5 on a powerpc with xcode 2.2.1.

Michael

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: make bootstrap: need moral support. :-(

[Giorgos Keramidas]

On 2006-02-20 07:24, "Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
> >>>>> "Robert" == Robert J Chassell <bob@rattlesnake.com> writes:
>
> Robert>     ... or am I just being unlucky at the moment?
> Robert> You are just being unlucky.  I updated CVS at 11:44 UTC this morning,
> Robert> 2006 Feb 19, and built it with
>
> Robert>      (progn (cd "/usr/local/src/emacs/") (compile "time make bootfast"))
>
> Robert> It built fine.  I did use gcc 4.0.3 but not long ago, I used gcc 2.95.
> Robert> I am also using GNU Make 3.81beta4, but I expect that make 3.79.1
> Robert> would work.
>
> I built from CVS just now on OSX with:
>
>         make distclean
>         ./configure --prefix=/opt/emacs --without-x
>         make bootstrap install
>
> and died with:
>
> /emacs-CVS/lib-src/../src  -fpascal-strings -DMAC_OSX -I../mac/src   -g -O2 -Wno-pointer-sign  -DVERSION="\"22.0.50\"" /Users/merlyn/MIRROR/emacs-CVS/lib-src/etags.c getopt.o getopt1.o regex.o  -o etags
> /usr/bin/ld: Undefined symbols:
> _xmalloc
> _xrealloc
> collect2: ld returned 1 exit status
> make[3]: *** [etags] Error 1
> make[2]: *** [lib-src] Error 2
> make[1]: *** [bootstrap-build] Error 2
> make: *** [bootstrap] Error 2
> make bootstrap install  856.14s user 189.33s system 40% cpu 43:07.15 total
>
> This is definitely recent.

Yes.

The malloc/realloc -> xmalloc/xrealloc change to src/regex.c adds a
conditional dependency on some of the allocators available in emacs/src/
to lib-src files too.

I'm currently building a snapshot with the following patch applied to
see if it fixes things:

%%%
Index: emacs/lib-src/Makefile.in
===================================================================
--- emacs/lib-src/Makefile.in	(.../branches/gnu)	(revision 21)
+++ emacs/lib-src/Makefile.in	(.../trunk)	(revision 21)
@@ -399,13 +399,36 @@
 #ifdef REGEXP_IN_LIBC
 REGEXPOBJ =
 REGEXPDEPS =
-#else
-REGEXPOBJ = regex.o
-REGEXPDEPS = $(REGEXPOBJ) $(srcdir)/../src/regex.h
+#else /* !REGEXP_IN_LIBC */
+
+/* The Emacs regexp code depends on our own memory allocation stuff. */
+#ifndef SYSTEM_MALLOC
+#ifndef DOUG_LEA_MALLOC
+GMALLOCOBJ = gmalloc.o
 #endif
 
+#ifdef REL_ALLOC
+RALLOCOBJ = ralloc.o
+#endif
+
+MALLOCOBJ = ${GMALLOCOBJ} ${RALLOCOBJ} vm-limit.o
+#endif /* SYSTEM_MALLOC */
+
+REGEXPOBJ = regex.o $(MALLOCOBJ)
+REGEXPDEPS = $(REGEXPOBJ) $(MALLOCOBJ) $(srcdir)/../src/regex.h
+#endif
+
+gmalloc.o: $(srcdir)/../src/gmalloc.c ../src/config.h
+	${CC} -c ${ALL_CFLAGS} ${srcdir}/../src/gmalloc.c
+
+ralloc.o: $(srcdir)/../src/ralloc.c ../src/config.h
+	${CC} -c ${ALL_CFLAGS} ${srcdir}/../src/ralloc.c
+
+vm-limit.o: $(srcdir)/../src/vm-limit.c $(srcdir)/../src/mem-limits.h ../src/config.h
+	${CC} -c ${ALL_CFLAGS} ${srcdir}/../src/vm-limit.c
+
 regex.o: $(srcdir)/../src/regex.c $(srcdir)/../src/regex.h ../src/config.h
-	${CC} -c ${BASE_CFLAGS} -DCONFIG_BROKETS -DINHIBIT_STRING_HEADER ${srcdir}/../src/regex.c
+	${CC} -c ${ALL_CFLAGS} -DCONFIG_BROKETS -DINHIBIT_STRING_HEADER ${srcdir}/../src/regex.c
 
 etags${EXEEXT}: ${srcdir}/etags.c $(GETOPTDEPS) $(REGEXPDEPS) ../src/config.h
 	$(CC) ${ALL_CFLAGS} -DVERSION="\"${version}\"" ${srcdir}/etags.c $(GETOPTOBJS) $(REGEXPOBJ) $(LOADLIBES) -o etags
%%%

It isn't finished yet, and I haven't actually tried running Emacs with
it, but it may help someone more knowledgeable to find the real fix.

- Giorgos

Re: make bootstrap: need moral support. :-(

[Giorgos Keramidas]

On 2006-02-20 22:57, Giorgos Keramidas <keramida@ceid.upatras.gr> wrote:
> Yes.
>
> The malloc/realloc -> xmalloc/xrealloc change to src/regex.c adds a
> conditional dependency on some of the allocators available in emacs/src/
> to lib-src files too.
>
> I'm currently building a snapshot with the following patch applied to
> see if it fixes things:

Actually, scratch that.  The `etags.c' source file already has
xrealloc() and xmalloc(), but they are static.  The patch that fixes
bootstrap for me here is much simpler :)

%%%
Index: emacs/lib-src/etags.c
===================================================================
--- emacs/lib-src/etags.c	(.../branches/gnu)	(revision 26)
+++ emacs/lib-src/etags.c	(.../trunk)	(revision 26)
@@ -414,8 +414,8 @@
 static void canonicalize_filename __P((char *));
 static void linebuffer_init __P((linebuffer *));
 static void linebuffer_setlen __P((linebuffer *, int));
-static PTR xmalloc __P((unsigned int));
-static PTR xrealloc __P((char *, unsigned int));
+PTR xmalloc __P((unsigned int));
+PTR xrealloc __P((char *, unsigned int));
 
 \f
 static char searchar = '/';	/* use /.../ searches */
@@ -6864,7 +6864,7 @@
 }
 
 /* Like malloc but get fatal error if memory is exhausted. */
-static PTR
+PTR
 xmalloc (size)
      unsigned int size;
 {
@@ -6874,7 +6874,7 @@
   return result;
 }
 
-static PTR
+PTR
 xrealloc (ptr, size)
      char *ptr;
      unsigned int size;
%%%

Re: make bootstrap: need moral support. :-(

[Eli Zaretskii]

> Date: Sun, 19 Feb 2006 15:07:54 +0000 (GMT)
> From: Alan Mackenzie <acm@muc.de>
> 
> I've got CC Mode 5.31.3 ready for merging into the Emacs CVS.  First, I
> should be testing it on an up to date Emacs 22.
> 
> So, I cvs updated my copy of CVS Emacs this morning.  I followed this
> with a ./configure and a make bootstrap.  It failed in process.c with a
> "dereferencing pointer to incomplete type" error, whatever that is.
> [...]
> Would somebody cheer me up, please.

How about if you tell us the details, like the precise error message,
for example?

Re: make bootstrap: need moral support. :-(

[Alan Mackenzie]

Hi, Eli!

On Mon, 20 Feb 2006, Eli Zaretskii wrote:

>> Date: Sun, 19 Feb 2006 15:07:54 +0000 (GMT)
>> From: Alan Mackenzie <acm@muc.de>
>> 
>> I've got CC Mode 5.31.3 ready for merging into the Emacs CVS.  First, I
>> should be testing it on an up to date Emacs 22.
>> 
>> So, I cvs updated my copy of CVS Emacs this morning.  I followed this
>> with a ./configure and a make bootstrap.  It failed in process.c with a
>> "dereferencing pointer to incomplete type" error, whatever that is.
>> [...]
>> Would somebody cheer me up, please.
>
>How about if you tell us the details, like the precise error message,
>for example?

It was 

process.c: In function `conv_sockaddr_to_lisp':
process.c:2245: dereferencing pointer to incomplete type
process.c:2246: dereferencing pointer to incomplete type
process.c:2249: dereferencing pointer to incomplete type
process.c:2249: dereferencing pointer to incomplete type
process.c:2249: dereferencing pointer to incomplete type
<etc>

The source code in process.c looks like this:
#ifdef AF_INET6
    case AF_INET6:
      {
        struct sockaddr_in6 *sin6 = (struct sockaddr_in6 *) sa;
        uint16_t *ip6 = (uint16_t *)&sin6->sin6_addr;      <======= L2245

All of these places were within #ifdef AF_INET6 regions.  This symbol is
defined in socket.h, and "ls -lu" indicates that my Emacs compiled with
the socket.h in a linux-2.4.17 tree.  It seems that that this socket.h
and Emacs have different ideas about the type sockaddr_in6.  I worked
around this problem by putting #undef AF_INET6 near the top of the file.

Emacs then built immediately! (well, actually, it took nearer 3 hours,
but it managed without further intervention from me.  :-).

However, when I started it up, it complained about this form in my
site-start.el:

    (define-key help-mode-map "\M-n" 'clone-buffer)

I had to wrap this form in an (eval-after-load "help-mode" ....).  Is
this failure to load help-mode at start-up deliberate, or is it a bug?
It used to be loaded, at least as recently as last September.

-- 
Alan.

Re: make bootstrap: need moral support. :-(

[Eli Zaretskii]

> Date: Mon, 20 Feb 2006 04:03:39 +0000 (GMT)
> From: Alan Mackenzie <acm@muc.de>
> cc: emacs-devel@gnu.org
> 
> process.c: In function `conv_sockaddr_to_lisp':
> process.c:2245: dereferencing pointer to incomplete type
> process.c:2246: dereferencing pointer to incomplete type
> process.c:2249: dereferencing pointer to incomplete type
> process.c:2249: dereferencing pointer to incomplete type
> process.c:2249: dereferencing pointer to incomplete type
> <etc>
> 
> The source code in process.c looks like this:
> #ifdef AF_INET6
>     case AF_INET6:
>       {
>         struct sockaddr_in6 *sin6 = (struct sockaddr_in6 *) sa;
>         uint16_t *ip6 = (uint16_t *)&sin6->sin6_addr;      <======= L2245

This means that the IPv6 configury test is misbehaving.  Please look
into your headers and try to find out why the configure-time test
decides that your system supports IPv6, but `struct sockaddr_in6' is
not defined by your system headers.

> It seems that that this socket.h and Emacs have different ideas
> about the type sockaddr_in6.

They don't have different ideas; your socket.h does not define struct
sockaddr_in6 at all.

> I worked around this problem by putting #undef AF_INET6 near the top
> of the file.
> 
> Emacs then built immediately!

Well, that's good for you, but what about all the other users who will
have the same problem?  I'd suggest not to sweep the problem under the
carpet, but rather try to find out what is wrong with the
configure-time test, so that it could be fixed for others as well.

> However, when I started it up, it complained about this form in my
> site-start.el:
> 
>     (define-key help-mode-map "\M-n" 'clone-buffer)
> 
> I had to wrap this form in an (eval-after-load "help-mode" ....).  Is
> this failure to load help-mode at start-up deliberate, or is it a bug?

I think it's deliberate: why should we load help-mode before Help
commands are used?

Btw, your workaround is not the best way to solve this, I think: each
mode has a mode hook, precisely for these situations.  Just define a
function that binds that key and add that function to help-mode-hook.

> It used to be loaded, at least as recently as last September.

I don't see in the logs anything since last September that could
change this; perhaps I'm blind.

Re: make bootstrap: need moral support. :-(

[Alan Mackenzie]

Hi, Eli!

On Mon, 20 Feb 2006, Eli Zaretskii wrote:

>> Date: Mon, 20 Feb 2006 04:03:39 +0000 (GMT)
>> From: Alan Mackenzie <acm@muc.de>
>> cc: emacs-devel@gnu.org

>> process.c: In function `conv_sockaddr_to_lisp':
>> process.c:2245: dereferencing pointer to incomplete type
>> process.c:2246: dereferencing pointer to incomplete type
>> process.c:2249: dereferencing pointer to incomplete type
>> process.c:2249: dereferencing pointer to incomplete type
>> process.c:2249: dereferencing pointer to incomplete type
>> <etc>

>> The source code in process.c looks like this:
>> #ifdef AF_INET6
>>     case AF_INET6:
>>       {
>>         struct sockaddr_in6 *sin6 = (struct sockaddr_in6 *) sa;
>>         uint16_t *ip6 = (uint16_t *)&sin6->sin6_addr;      <======= L2245

>This means that the IPv6 configury test is misbehaving.  Please look
>into your headers and try to find out why the configure-time test
>decides that your system supports IPv6, but `struct sockaddr_in6' is
>not defined by your system headers.

In Linux 2.4.17, that struct is defined in the file
linux-2.4.17/include/linux/in6.h/.  Emacs files.c don't #include this
file at all.  I'll have a look at ./configure, sometime.

[ .... ]

>> I worked around this problem by putting #undef AF_INET6 near the top
>> of the file.

>> Emacs then built immediately!

>Well, that's good for you, but what about all the other users who will
>have the same problem?  I'd suggest not to sweep the problem under the
>carpet, but rather try to find out what is wrong with the
>configure-time test, so that it could be fixed for others as well.

OK.  It's just that I didn't have enough confidence in my ability to
build Emacs to assume that this problem was a bug (as contrasted to me
not giving some parameter to ./configure, or something).

>> However, when I started it up, it complained about this form in my
>> site-start.el:

>>     (define-key help-mode-map "\M-n" 'clone-buffer)

>> I had to wrap this form in an (eval-after-load "help-mode" ....).  Is
>> this failure to load help-mode at start-up deliberate, or is it a bug?

>I think it's deliberate: why should we load help-mode before Help
>commands are used?

:-)  It has historically always been so loaded.  Who gets through an
Emacs session without C-h?  But then, loading it early is not that
important.

>Btw, your workaround is not the best way to solve this, I think: each
>mode has a mode hook, precisely for these situations.  Just define a
>function that binds that key and add that function to help-mode-hook.

The key sequence needs binding only once.  Won't help-mode-hook be called
every time a help command is invoked?

-- 
Alan.

Re: make bootstrap: need moral support. :-(

[Eli Zaretskii]

> Date: Mon, 20 Feb 2006 22:32:29 +0000 (GMT)
> From: Alan Mackenzie <acm@muc.de>
> cc: emacs-devel@gnu.org
> 
> >> The source code in process.c looks like this:
> >> #ifdef AF_INET6
> >>     case AF_INET6:
> >>       {
> >>         struct sockaddr_in6 *sin6 = (struct sockaddr_in6 *) sa;
> >>         uint16_t *ip6 = (uint16_t *)&sin6->sin6_addr;      <======= L2245
> 
> >This means that the IPv6 configury test is misbehaving.  Please look
> >into your headers and try to find out why the configure-time test
> >decides that your system supports IPv6, but `struct sockaddr_in6' is
> >not defined by your system headers.
> 
> In Linux 2.4.17, that struct is defined in the file
> linux-2.4.17/include/linux/in6.h/.  Emacs files.c don't #include this
> file at all.  I'll have a look at ./configure, sometime.

Thanks.

> >Btw, your workaround is not the best way to solve this, I think: each
> >mode has a mode hook, precisely for these situations.  Just define a
> >function that binds that key and add that function to help-mode-hook.
> 
> The key sequence needs binding only once.  Won't help-mode-hook be called
> every time a help command is invoked?

Yes, but so what?  Entering help mode is not exactly a real-time
operation ;-)

Re: make bootstrap: need moral support. :-(

[Jan D.]

> > >> The source code in process.c looks like this:
> > >> #ifdef AF_INET6
> > >>     case AF_INET6:
> > >>       {
> > >>         struct sockaddr_in6 *sin6 = (struct sockaddr_in6 *) sa;
> > >>         uint16_t *ip6 = (uint16_t *)&sin6->sin6_addr;      <======= L2245
> > 
> > >This means that the IPv6 configury test is misbehaving.  Please look
> > >into your headers and try to find out why the configure-time test
> > >decides that your system supports IPv6, but `struct sockaddr_in6' is
> > >not defined by your system headers.
> > 
> > In Linux 2.4.17, that struct is defined in the file
> > linux-2.4.17/include/linux/in6.h/.  Emacs files.c don't #include this
> > file at all.  I'll have a look at ./configure, sometime.
> 

struct sockaddr_in6 should be defined in netinet/in.h also.

	Jan D.

Re: make bootstrap: need moral support. :-(

[Kim F. Storm]

Eli Zaretskii <eliz@gnu.org> writes:

>> The source code in process.c looks like this:
>> #ifdef AF_INET6
>>     case AF_INET6:
>>       {
>>         struct sockaddr_in6 *sin6 = (struct sockaddr_in6 *) sa;
>>         uint16_t *ip6 = (uint16_t *)&sin6->sin6_addr;      <======= L2245
>
> This means that the IPv6 configury test is misbehaving.  

IIRC, configure has no explicit test for IPv6 -- process.c
just tests whether AF_INET6 being defined.  

But that obviously doesn't load the proper header files 
in all cases.

Can one of the configure hackers please DTRT?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: make bootstrap: need moral support. :-(

[Eric Hanchrow]

Often, the only way I can get Emacs to build is to

       $ cd /usr/local/src/emacs-cvs
       
       # Delete everything except the top-level CVS directory
       $ find . -! -name CVS -mindepth 1 -maxdeptn 1 | xargs rm -rf

       $ cvs up

       $ ./configure && make bootstrap

I might be going overboard, but I needed to do this at least once, and
I'm superstitious enough that I keep doing it whenever Emacs acts
funny.

-- 
When it comes to electronic voting, most liberals are just plain
old-fashioned nuts.
        -- Joe Andrew, former chairman of the Democratic National
           Committee

Re: make bootstrap: need moral support. :-(

[Giorgos Keramidas]

On 2006-02-20 08:21, Eric Hanchrow <offby1@blarg.net> wrote:
> Often, the only way I can get Emacs to build is to
>
>        $ cd /usr/local/src/emacs-cvs
>
>        # Delete everything except the top-level CVS directory
>        $ find . -! -name CVS -mindepth 1 -maxdeptn 1 | xargs rm -rf
>
>        $ cvs up
>
>        $ ./configure && make bootstrap
>
> I might be going overboard, but I needed to do this at least once, and
> I'm superstitious enough that I keep doing it whenever Emacs acts
> funny.

I, on the other hand, keep a local subversion branch with the Emacs
sources unchanged, in file:///svnroot/emacs/branches/gnu/.  Any changes
*I* make are made to file:///svnroot/emacs/trunk/, so when I need a
clean copy of the source tree, I just remove the checkout of /trunk and
check it out again.

No serious build problems so far :)

How do the people who work with the repository keep up to date their
sources?  Is there a way to actually _mirror_ the CVS changes, like
CVSup or similar?

- Giorgos

Re: make bootstrap: need moral support. :-(

[Ken Raeburn]

On Feb 20, 2006, at 16:38, Giorgos Keramidas wrote:
> I, on the other hand, keep a local subversion branch with the Emacs
> sources unchanged, in file:///svnroot/emacs/branches/gnu/.  Any  
> changes
> *I* make are made to file:///svnroot/emacs/trunk/, so when I need a
> clean copy of the source tree, I just remove the checkout of /trunk  
> and
> check it out again.

Works for me too... or "svn revert" works pretty well also.

> How do the people who work with the repository keep up to date their
> sources?  Is there a way to actually _mirror_ the CVS changes, like
> CVSup or similar?

Well, you can rsync from the FSF CVS repository, so you can have a  
local copy updated fairly efficiently.  I do that, but only because  
it makes the "svk sync" process I use to mirror the repository into  
Subversion go much faster. :-)
(To mirror CVS into SVN, you can install the VCP package and its SVN  
interface.  I think cvs2svn might also work for incremental updates,  
but last I looked, the docs seemed to suggest that it was not  
intended for that and it might not work.  Oh, and SVN doesn't like  
one of the filenames in the CVS repository, which has a control  
character in its name; I just tell rsync to leave it out.)

Ken

Re: make bootstrap: need moral support. :-(

[Giorgos Keramidas]

On 2006-02-21 00:18, Ken Raeburn <raeburn@raeburn.org> wrote:
> Well, you can rsync from the FSF CVS repository, so you can
> have a local copy updated fairly efficiently.  I do that, but
> only because it makes the "svk sync" process I use to mirror
> the repository into Subversion go much faster. :-)

This sounds like an ideal plan.  Thanks for the tip :)

I don't know where/how to access the rsync server though.  A quick
search in savannah.gnu.org and Google, doesn't reveal much.

Re: make bootstrap: need moral support. :-(

[Ken Raeburn]

On Feb 21, 2006, at 03:52, Giorgos Keramidas wrote:
> I don't know where/how to access the rsync server though.  A quick
> search in savannah.gnu.org and Google, doesn't reveal much.

I'm using something like this:

   rsync -azvH --delete --exclude "a?b,v" --exclude config \
      cvs.savannah.gnu.org::sources/emacs/. /my/emacs/cvs/mirror/.

The trailing "/." is an old habit, so I don't have to think about  
whether it's going to mirror "emacs" to "mirror", or mirror "emacs"  
into a subdirectory of "mirror"; it may work fine without them.  The  
"a?b,v" is because of a file with a ^L control character in its name  
(in an Attic subdirectory; it's a dead file, but the cvs->svn mirror  
code sees it anyways and gets unhappy); "config" is to get rid of  
CVSROOT/config which has some keywords that the cvs->svn code doesn't  
recognize.

I use VCP and SVK to do the mirroring (install both, use "svk mirror"  
to set up the mirror, "svk sync" to update), but SVN for most of my  
actual work.  VCP is a little finicky; the version I've got gets  
unhappy if your working directory is in NFS(!), but start it in a  
local /tmp and it'll be fine.

Ken

Re: make bootstrap: need moral support. :-(

[Richard M. Stallman]

    So, I cvs updated my copy of CVS Emacs this morning.  I followed this
    with a ./configure and a make bootstrap.  It failed in process.c with a
    "dereferencing pointer to incomplete type" error, whatever that is.

If you want help in figuring out the problem, please include precise
details.  Show the error message; show the code that gets the error.

Re: make bootstrap: need moral support. :-(

[Alan Mackenzie]

Hi, Richard and Everybody!

On Mon, 20 Feb 2006, Richard M. Stallman wrote:

>    So, I cvs updated my copy of CVS Emacs this morning.  I followed this
>    with a ./configure and a make bootstrap.  It failed in process.c with a
>    "dereferencing pointer to incomplete type" error, whatever that is.

>If you want help in figuring out the problem, please include precise
>details.  Show the error message; show the code that gets the error.

No, I've figured out the problem, I think.

What I really needed was a quiet beer with somebody, because I was
feeling a bit down, and a bit -ve towards Emacs.  You guys came up with
trumps, and persuaded me I needn't be worried about updating more
frequently from savannah.

Thanks!

-- 
Alan Mackenzie (Munich, Germany).

Re: make bootstrap: need moral support. :-(

[Eli Zaretskii]

> Date: Mon, 20 Feb 2006 22:37:13 +0000 (GMT)
> From: Alan Mackenzie <acm@muc.de>
> Cc: emacs-devel@gnu.org
> 
> What I really needed was a quiet beer with somebody, because I was
> feeling a bit down

If you are prepared to fly in, I'd be happy to have a beer with you.
This time, the beer will be on me.

Re: make bootstrap: need moral support. :-(

[Francesco Potorti`]

>===================================================================
>--- emacs/lib-src/etags.c	(.../branches/gnu)	(revision 26)
>+++ emacs/lib-src/etags.c	(.../trunk)	(revision 26)
>@@ -414,8 +414,8 @@
> static void canonicalize_filename __P((char *));
> static void linebuffer_init __P((linebuffer *));
> static void linebuffer_setlen __P((linebuffer *, int));
>-static PTR xmalloc __P((unsigned int));
>-static PTR xrealloc __P((char *, unsigned int));
>+PTR xmalloc __P((unsigned int));
>+PTR xrealloc __P((char *, unsigned int));
> 
> \f
> static char searchar = '/';	/* use /.../ searches */
>@@ -6864,7 +6864,7 @@
> }
> 
> /* Like malloc but get fatal error if memory is exhausted. */
>-static PTR
>+PTR
> xmalloc (size)
>      unsigned int size;
> {
>@@ -6874,7 +6874,7 @@
>   return result;
> }
> 
>-static PTR
>+PTR
> xrealloc (ptr, size)
>      char *ptr;
>      unsigned int size;
>%%%

This patch is harmless, from the etags point of view.  The choice for
"static" was of theoretical cleanness and source documentation, but
involved no practical issues.

If you need that patch, I can apply it myself (I am the etags
maintainer) or you can apply it, if you like it better.  Just let me
know. 

Re: make bootstrap: need moral support. :-(

[Giorgos Keramidas]

On 2006-02-22 11:30, Francesco Potorti` <pot@gnu.org> wrote:
> >===================================================================
> >--- emacs/lib-src/etags.c	(.../branches/gnu)	(revision 26)
> >+++ emacs/lib-src/etags.c	(.../trunk)	(revision 26)
> >@@ -414,8 +414,8 @@
> > static void canonicalize_filename __P((char *));
> > static void linebuffer_init __P((linebuffer *));
> > static void linebuffer_setlen __P((linebuffer *, int));
> >-static PTR xmalloc __P((unsigned int));
> >-static PTR xrealloc __P((char *, unsigned int));
> >+PTR xmalloc __P((unsigned int));
> >+PTR xrealloc __P((char *, unsigned int));
> >
> > \f
> > static char searchar = '/';	/* use /.../ searches */
> >@@ -6864,7 +6864,7 @@
> > }
> >
> > /* Like malloc but get fatal error if memory is exhausted. */
> >-static PTR
> >+PTR
> > xmalloc (size)
> >      unsigned int size;
> > {
> >@@ -6874,7 +6874,7 @@
> >   return result;
> > }
> >
> >-static PTR
> >+PTR
> > xrealloc (ptr, size)
> >      char *ptr;
> >      unsigned int size;
> >%%%
>
> This patch is harmless, from the etags point of view.  The choice for
> "static" was of theoretical cleanness and source documentation, but
> involved no practical issues.
>
> If you need that patch, I can apply it myself (I am the etags
> maintainer) or you can apply it, if you like it better.  Just let me
> know.

No, that's fine.  Thanks for the offer.  The patch was only needed while
regex.c used xmalloc/xrealloc.  Now that the change is reverted, I've
locally reverted this patch from my tree too.

Again, thanks :)