GNU bug report logs - #35174
emacs-git sha f2d22273599f96a731e23b2f6d7571af8bb7bb3f fails to build

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 35174 in the body.
You can then email your comments to 35174 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Cocora <stefan.cocora <at> googlemail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: emacs-git sha f2d22273599f96a731e23b2f6d7571af8bb7bb3f fails to build
Date: Sat, 6 Apr 2019 20:08:43 +0100

[Message part 1 (text/plain, inline)]

Hi devel team,


FYI:
Latest emacs-git from HEAD f2d22273599f96a731e23b2f6d7571af8bb7bb3f
fails to build inside an nspawn clean and updated archlinux chroot, with
this missing libgnu.a error:

...
  GEN      time.h
  GEN      unistd.h
  AR       libgnu.a
ar: fcntl.o: No such file or directory
make[1]: *** [Makefile:103: libgnu.a] Error 1
make: *** [Makefile:410: lib] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
```

Full build log can be found here:
- attached to this email
- https://gitlab.com/snippets/1843871
- https://gist.github.com/stefancocora/743cc3e1f5c2a7baa484c4666ce30a58

The build is automated using this archlinux PKGBUILD package manifest
- https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=emacs-git
- attached to this email

As far as the archlinux package content search is able to find only
"extra/clisp" contains this libgnu.a file but even when adding clisp to
the depends list emacs-git fails to build.

Note:
emacs-git cf6950366bd2b2aad4daa2d601bd8ccdb50df700 has been able to
build fine using the same archlinux nspawn clean chroot and the same
PKGBUILD 2-3 weeks ago.


Regards,
Stefan

[emacs-git-f2d2227-failed-build.log (text/x-log, attachment)]

[PKGBUILD (text/plain, attachment)]

Message #8 received at 35174 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Stefan Cocora <stefan.cocora <at> googlemail.com>
Cc: 35174 <at> debbugs.gnu.org
Subject: Re: bug#35174: emacs-git sha f2d22273599f96a731e23b2f6d7571af8bb7bb3f
 fails to build
Date: Sat, 06 Apr 2019 15:48:11 -0400

Stefan Cocora <stefan.cocora <at> googlemail.com> writes:

> Latest emacs-git from HEAD f2d22273599f96a731e23b2f6d7571af8bb7bb3f
> fails to build inside an nspawn clean and updated archlinux chroot, with
> this missing libgnu.a error:
>
> ...
>   GEN      time.h
>   GEN      unistd.h
>   AR       libgnu.a
> ar: fcntl.o: No such file or directory

> As far as the archlinux package content search is able to find only
> "extra/clisp" contains this libgnu.a file but even when adding clisp to
> the depends list emacs-git fails to build.

libgnu.a is being built, it's not a dependency.  fcntl.o is what's
missing, it's supposed to be built from lib/fcntl.c.  I'm not sure why
make is skipping compilation (and for all the other C files in that
directory).  For reference, I excerpt what the build is supposed to look
below.  Which makes me notice the archlinux log doesn't seem to have the
"make[1]: Entering directory ..." part, perhaps that is significant?

make[1]: Entering directory `/tmp/emacs-master/lib'
  GEN      alloca.h
  ...
  GEN      time.h
  GEN      unistd.h
  CC       explicit_bzero.o
  CC       fcntl.o
  ...
  CC       save-cwd.o
  AR       libgnu.a
make[1]: Leaving directory `/tmp/emacs-master/lib'

Message #11 received at 35174 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Cocora <stefan.cocora <at> googlemail.com>
To: 35174 <at> debbugs.gnu.org
Subject: Re: bug#35174: emacs-git sha f2d22273599f96a731e23b2f6d7571af8bb7bb3f
 fails to build
Date: Sun, 7 Apr 2019 08:57:00 +0100

[Message part 1 (text/plain, inline)]

Thanks for the pointers Noah, I was misreading the build log re "libgnu.a".


The weird part is that a previous(2019-Mar-24) emacs-git build, built
with the same PKGBUILD worked fine, found and built lib/fcntl.c.
- previous successful log build attached to this email

I've ran again, today, the build for emacs-git from the latest HEAD
(0c16bb5a39b38c48374bc3ad4ca99208ff329d46) and it fails in the same way,
it fails to find and build lib/fcntl.c, very weird.


On 4/6/19 20:48, Noam Postavsky wrote:
> Stefan Cocora <stefan.cocora <at> googlemail.com> writes:
> 
>> Latest emacs-git from HEAD f2d22273599f96a731e23b2f6d7571af8bb7bb3f
>> fails to build inside an nspawn clean and updated archlinux chroot, with
>> this missing libgnu.a error:
>>
>> ...
>>   GEN      time.h
>>   GEN      unistd.h
>>   AR       libgnu.a
>> ar: fcntl.o: No such file or directory
> 
>> As far as the archlinux package content search is able to find only
>> "extra/clisp" contains this libgnu.a file but even when adding clisp to
>> the depends list emacs-git fails to build.
> 
> libgnu.a is being built, it's not a dependency.  fcntl.o is what's
> missing, it's supposed to be built from lib/fcntl.c.  I'm not sure why
> make is skipping compilation (and for all the other C files in that
> directory).  For reference, I excerpt what the build is supposed to look
> below.  Which makes me notice the archlinux log doesn't seem to have the
> "make[1]: Entering directory ..." part, perhaps that is significant?
> 
> make[1]: Entering directory `/tmp/emacs-master/lib'
>   GEN      alloca.h
>   ...
>   GEN      time.h
>   GEN      unistd.h
>   CC       explicit_bzero.o
>   CC       fcntl.o
>   ...
>   CC       save-cwd.o
>   AR       libgnu.a
> make[1]: Leaving directory `/tmp/emacs-master/lib'
> 
> 

[emacs-git-27.0.50.135639-1-x86_64-build.log (text/x-log, attachment)]

Message #14 received at 35174 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Stefan Cocora <stefan.cocora <at> googlemail.com>
Cc: 35174 <at> debbugs.gnu.org
Subject: Re: bug#35174: emacs-git sha f2d22273599f96a731e23b2f6d7571af8bb7bb3f
 fails to build
Date: Sun, 07 Apr 2019 07:49:19 -0400

Stefan Cocora <stefan.cocora <at> googlemail.com> writes:

> The weird part is that a previous(2019-Mar-24) emacs-git build, built
> with the same PKGBUILD worked fine, found and built lib/fcntl.c.
> - previous successful log build attached to this email

So I notice this successful build also is also printing the recursive
make invocation (and it seems to be running in parallel) whereas the
failing build just goes straight to printing the GEN lines.  I think
this all this points to some change in the build system on the server;
was 'make' updated recently?

make -C lib all
make info-real info-dir
make[1]: Entering directory '/build/emacs-git/src/emacs-git/lib'
make[1]: Entering directory '/build/emacs-git/src/emacs-git'
make -C doc/lispref info
  GEN      alloca.h
  GEN      dirent.h

Message #19 received at 35174 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: 35174 <at> debbugs.gnu.org
Cc: Stefan Cocora <stefan.cocora <at> googlemail.com>
Subject: Re: bug#35174: emacs-git sha f2d22273599f96a731e23b2f6d7571af8bb7bb3f
 fails to build
Date: Tue, 09 Apr 2019 18:35:06 -0400

[Message part 1 (text/plain, inline)]

[forwarding to list, please use "Reply All" to keep 35174 <at> debbugs.gnu.org on Cc]

[Message part 2 (message/rfc822, inline)]

From: Stefan Cocora <stefan.cocora <at> googlemail.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Subject: Re: bug#35174: emacs-git sha f2d22273599f96a731e23b2f6d7571af8bb7bb3f fails to build
Date: Tue, 9 Apr 2019 19:59:00 +0100

On 4/7/19 12:49, Noam Postavsky wrote:
> Stefan Cocora <stefan.cocora <at> googlemail.com> writes:
> 
>> The weird part is that a previous(2019-Mar-24) emacs-git build, built
>> with the same PKGBUILD worked fine, found and built lib/fcntl.c.
>> - previous successful log build attached to this email
> 
> So I notice this successful build also is also printing the recursive
> make invocation (and it seems to be running in parallel) whereas the
> failing build just goes straight to printing the GEN lines.  I think
> this all this points to some change in the build system on the server;
> was 'make' updated recently?
> 
> make -C lib all
> make info-real info-dir
> make[1]: Entering directory '/build/emacs-git/src/emacs-git/lib'
> make[1]: Entering directory '/build/emacs-git/src/emacs-git'
> make -C doc/lispref info
>   GEN      alloca.h
>   GEN      dirent.h
> 

Not sure how make would switch from printing the recursive make
invocation to printing GEN lines, since I've not touched the upstream
emacs Makefile.

Since this build is running in a clean chroot, it will install,
unattended, the latest available make version. (4.2.1)

Looking at the git changes for the archlinux make pkg, the last version
update was in 2018-11

https://git.archlinux.org/svntogit/packages.git/log/trunk?h=packages/make

Message #22 received at 35174 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: 35174 <at> debbugs.gnu.org
Cc: Stefan Cocora <stefan.cocora <at> googlemail.com>
Subject: Re: bug#35174: emacs-git sha f2d22273599f96a731e23b2f6d7571af8bb7bb3f
 fails to build
Date: Tue, 09 Apr 2019 19:18:43 -0400

>>> The weird part is that a previous(2019-Mar-24) emacs-git build, built
>>> with the same PKGBUILD worked fine, found and built lib/fcntl.c.
>>> - previous successful log build attached to this email
>> 
>> So I notice this successful build also is also printing the recursive
>> make invocation (and it seems to be running in parallel) whereas the
>> failing build just goes straight to printing the GEN lines.  I think
>> this all this points to some change in the build system on the server;
>> was 'make' updated recently?
>> 
>> make -C lib all
>> make info-real info-dir
>> make[1]: Entering directory '/build/emacs-git/src/emacs-git/lib'
>> make[1]: Entering directory '/build/emacs-git/src/emacs-git'
>> make -C doc/lispref info
>>   GEN      alloca.h
>>   GEN      dirent.h
>> 
>
> Not sure how make would switch from printing the recursive make
> invocation to printing GEN lines, since I've not touched the upstream
> emacs Makefile.

Hmm, but it's not the upstream emacs Makefile, because it's working fine
in other automated from scratch builds, e.g.:

https://hydra.nixos.org/jobset/gnu/emacs-trunk/evals (latest log as of
this writing is at
https://nix-cache.s3.amazonaws.com/log/4xpdrx48lfakc6piby1zihdmy9xcxyyp-emacs-tarball-unknown.drv)

> Since this build is running in a clean chroot, it will install,
> unattended, the latest available make version. (4.2.1)
>
> Looking at the git changes for the archlinux make pkg, the last version
> update was in 2018-11

And not make itself, since it hasn't changed since March when it worked
fine.  How mysterious.  Perhaps you could pass --debug to make and we
might get some more clues?

Message #25 received at 35174 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Cocora <stefan.cocora <at> googlemail.com>
To: Noam Postavsky <npostavs <at> gmail.com>, 35174 <at> debbugs.gnu.org
Cc: Stefan Cocora <stefan.cocora <at> googlemail.com>
Subject: Re: bug#35174: emacs-git sha f2d22273599f96a731e23b2f6d7571af8bb7bb3f
 fails to build
Date: Thu, 2 May 2019 07:52:51 +0100

I've finally had time and validated that there isn't anything wrong with
the upstream emacs  build.

Although I don't see what is wrong, I've validated that something is
wrong with the wrapper make script that invokes the archlinux makepkg
build tool which invokes the upstream emacs build tools(make).

If I manually invoke the archlinux makepkg build tool (still running in
a chroot) emacs-git builds fine.

Thanks for looking into this issue Noam and for all the pointers !


On 4/10/19 00:18, Noam Postavsky wrote:
> 
>>>> The weird part is that a previous(2019-Mar-24) emacs-git build, built
>>>> with the same PKGBUILD worked fine, found and built lib/fcntl.c.
>>>> - previous successful log build attached to this email
>>>
>>> So I notice this successful build also is also printing the recursive
>>> make invocation (and it seems to be running in parallel) whereas the
>>> failing build just goes straight to printing the GEN lines.  I think
>>> this all this points to some change in the build system on the server;
>>> was 'make' updated recently?
>>>
>>> make -C lib all
>>> make info-real info-dir
>>> make[1]: Entering directory '/build/emacs-git/src/emacs-git/lib'
>>> make[1]: Entering directory '/build/emacs-git/src/emacs-git'
>>> make -C doc/lispref info
>>>   GEN      alloca.h
>>>   GEN      dirent.h
>>>
>>
>> Not sure how make would switch from printing the recursive make
>> invocation to printing GEN lines, since I've not touched the upstream
>> emacs Makefile.
> 
> Hmm, but it's not the upstream emacs Makefile, because it's working fine
> in other automated from scratch builds, e.g.:
> 
> https://hydra.nixos.org/jobset/gnu/emacs-trunk/evals (latest log as of
> this writing is at
> https://nix-cache.s3.amazonaws.com/log/4xpdrx48lfakc6piby1zihdmy9xcxyyp-emacs-tarball-unknown.drv)
> 
>> Since this build is running in a clean chroot, it will install,
>> unattended, the latest available make version. (4.2.1)
>>
>> Looking at the git changes for the archlinux make pkg, the last version
>> update was in 2018-11
> 
> And not make itself, since it hasn't changed since March when it worked
> fine.  How mysterious.  Perhaps you could pass --debug to make and we
> might get some more clues?
> 

Message #28 received at 35174 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Stefan Cocora <stefan.cocora <at> googlemail.com>
Cc: 35174 <at> debbugs.gnu.org
Subject: Re: bug#35174: emacs-git sha f2d22273599f96a731e23b2f6d7571af8bb7bb3f
 fails to build
Date: Sat, 11 May 2019 10:13:34 -0400

# Not an Emacs bug
tags 35174 = notabug
close 35174
quit

Stefan Cocora <stefan.cocora <at> googlemail.com> writes:

> Although I don't see what is wrong, I've validated that something is
> wrong with the wrapper make script that invokes the archlinux makepkg
> build tool which invokes the upstream emacs build tools(make).
>
> If I manually invoke the archlinux makepkg build tool (still running in
> a chroot) emacs-git builds fine.
>
> Thanks for looking into this issue Noam and for all the pointers !

Okay, thanks for the confirmation, I'm closing the bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.