bug#53038: 28.0.50; problem building

[joakim@verona.se]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Fri, 07 Jan 2022 13:55:12 +0100, joakim@verona.se said:
>
>     joakim> Robert Pluim <rpluim@gmail.com> writes:
>     >>>>>>> On Fri, 07 Jan 2022 13:44:08 +0200, Eli Zaretskii <eliz@gnu.org> said:
>     >> 
>     >> >> From: joakim@verona.se
>     >> >> Cc: 53038@debbugs.gnu.org
>     >> >> Date: Fri, 07 Jan 2022 09:44:14 +0100
>     >> >> 
>     >> >> > When the build fails, does the file lisp/international/emoji.el exist?
>     >> >> 
>     >> >> It does exist, yes.
>     >> 
>     Eli> So the problem seems to be with finding files via load-path.
>     >> 
>     Eli> My suggestion is to run the failing command manually, and if it also
>     Eli> fails, run it under a debugger to see why Emacs cannot find an
>     Eli> existing Lisp file.
>     >> 
>     >> Looking through the build log, $PWD and the paths reported by the
>     >> build look different. Is there some symlinking or NFS-mounting going
>     >> on?
>
>     joakim> There is:
>     joakim> ls -la ~|grep build
>     joakim> lrwxrwxrwx.   1 joakim joakim            9 Oct  8  2019 build -> /mnt/fast
>
>     joakim> To rule out this being a problem I went to the target of the symlink,
>     joakim> and did maintainer-clean, and make again. The problem persists.
>
>     joakim> For fun I can try on a completely different disk.
>
> Sure. And for completeness, from a clean checkout without symlinks in
> /mnt/fast somewhere.

I tried building in several different directories which were not
symlinked. 

Further datapoint:

I managed to build emacs inside a docker container on the host,


FROM fedora:34
RUN dnf -y install make gcc  gtk3-devel libXpm-devel gnutls-devel giflib-devel ncurses-devel texinfo libjpeg-turbo-devel findutils
RUN dnf -y install git # why is this neeed for the build? Error: (file-missing "Searching for program" "No such file or directory" "git")

COPY emacs.clean emacs
WORKDIR     emacs
RUN make -j32 # i have 32 threads...

this managed to build, and i can also run the resulting emacs inside the
container.

fedora:34 is the same as on the host, which should rule out that there
is something weird with fedora:34 as such.



>
> Robert
-- 
Joakim Verona
joakim@verona.se