hi
i'm currently building rpms of pike 8.0 for fedora35 and have troubles to "install" the binaries.
my setup: mock (chroot environment for building rpms). inside of that environment there are several steps, mainly extract source-files, prepare, compile, install and collect the final binaries.
the install step for both x86_64 and aarch64 seems to stop at:
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.bdeWDr + umask 022 + cd /builddir/build/BUILD + '[' /builddir/build/BUILDROOT/pike80-8.0.1116-1.fc35.aarch64 '!=' / ']' + rm -rf /builddir/build/BUILDROOT/pike80-8.0.1116-1.fc35.aarch64 ++ dirname /builddir/build/BUILDROOT/pike80-8.0.1116-1.fc35.aarch64 + mkdir -p /builddir/build/BUILDROOT + mkdir /builddir/build/BUILDROOT/pike80-8.0.1116-1.fc35.aarch64 + cd Pike-v8.0.1116 + buildroot=/builddir/build/BUILDROOT/pike80-8.0.1116-1.fc35.aarch64 + rm -rf /builddir/build/BUILDROOT/pike80-8.0.1116-1.fc35.aarch64 + cd build + /usr/bin/make buildroot=/builddir/build/BUILDROOT/pike80-8.0.1116-1.fc35.aarch64 install 'INSTALLARGS=buildroot='''/builddir/build/BUILDROOT/pike80-8.0.1116-1.fc35.aarch64''' lib_prefix='''/usr/lib64/pike80''' include_prefix='''/usr/include/pike80''' --traditional' Makefile:478: warning: ignoring prerequisites on suffix rule definition Makefile:524: warning: ignoring prerequisites on suffix rule definition make[1]: Entering directory '/builddir/build/BUILD/Pike-v8.0.1116/build' Makefile:478: warning: ignoring prerequisites on suffix rule definition Makefile:524: warning: ignoring prerequisites on suffix rule definition make[1]: Leaving directory '/builddir/build/BUILD/Pike-v8.0.1116/build' make[1]: Entering directory '/builddir/build/BUILD/Pike-v8.0.1116/build' Makefile:478: warning: ignoring prerequisites on suffix rule definition Makefile:524: warning: ignoring prerequisites on suffix rule definition make[1]: Leaving directory '/builddir/build/BUILD/Pike-v8.0.1116/build' Installing Pike in /builddir/build/BUILDROOT/pike80-8.0.1116-1.fc35.aarch64/usr, please wait...
i'm waiting for several hours (around 16) now attaching with strace to the running pike gets me:
close_range(11, -1, 0) = -1 EPERM (Operation not permitted) openat(AT_FDCWD, "/proc/self/fd/", O_RDONLY|O_DIRECTORY) = 9 getdents64(9, 0x7ffdc355bb80 /* 13 entries */, 1024) = 312 getdents64(9, 0x7ffdc355bb80 /* 0 entries */, 1024) = 0 close(9) = 0 close_range(11, -1, 0) = -1 EPERM (Operation not permitted) openat(AT_FDCWD, "/proc/self/fd/", O_RDONLY|O_DIRECTORY) = 9 getdents64(9, 0x7ffdc355bb80 /* 13 entries */, 1024) = 312 getdents64(9, 0x7ffdc355bb80 /* 0 entries */, 1024) = 0 close(9) .... fast looping over that lines
any ideas?
the same under fedora 34 built correctly.
any suggestions?
yours josef
hi
Hi.
i'm currently building rpms of pike 8.0 for fedora35 and have troubles to "install" the binaries.
my setup: mock (chroot environment for building rpms). inside of that environment there are several steps, mainly extract source-files, prepare, compile, install and collect the final binaries.
the install step for both x86_64 and aarch64 seems to stop at:
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.bdeWDr
[...]
/builddir/build/BUILDROOT/pike80-8.0.1116-1.fc35.aarch64/usr, please wait...
i'm waiting for several hours (around 16) now attaching with strace to the running pike gets me:
close_range(11, -1, 0) = -1 EPERM (Operation not permitted) openat(AT_FDCWD, "/proc/self/fd/", O_RDONLY|O_DIRECTORY) = 9 getdents64(9, 0x7ffdc355bb80 /* 13 entries */, 1024) = 312 getdents64(9, 0x7ffdc355bb80 /* 0 entries */, 1024) = 0 close(9) = 0 close_range(11, -1, 0) = -1 EPERM (Operation not permitted) openat(AT_FDCWD, "/proc/self/fd/", O_RDONLY|O_DIRECTORY) = 9 getdents64(9, 0x7ffdc355bb80 /* 13 entries */, 1024) = 312 getdents64(9, 0x7ffdc355bb80 /* 0 entries */, 1024) = 0 close(9) .... fast looping over that lines
any ideas?
This looks like a known bug in 8.0.1116. The easiest work-around is to disable the use of closefrom(3):
Either
ac_cv_func_closefrom=no .../configure ...
or edit machine.h after running configure and remove/disable the line
#define HAVE_CLOSEFROM 1
the same under fedora 34 built correctly.
Fedora 34 most likely did not have closefrom(3).
/grubba
The error code here (EPERM) is different from the one I was having (ENOSYS), but hopefully the same fix should work here as well...
that did the trick thanks
On Wed, 10 Nov 2021, Henrik Grubbstr?m (Lysator) @ Pike (-) developers forum wrote:
hi
Hi.
i'm currently building rpms of pike 8.0 for fedora35 and have troubles to "install" the binaries.
my setup: mock (chroot environment for building rpms). inside of that environment there are several steps, mainly extract source-files, prepare, compile, install and collect the final binaries.
the install step for both x86_64 and aarch64 seems to stop at:
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.bdeWDr
[...]
/builddir/build/BUILDROOT/pike80-8.0.1116-1.fc35.aarch64/usr, please wait...
i'm waiting for several hours (around 16) now attaching with strace to the running pike gets me:
close_range(11, -1, 0) = -1 EPERM (Operation not permitted) openat(AT_FDCWD, "/proc/self/fd/", O_RDONLY|O_DIRECTORY) = 9 getdents64(9, 0x7ffdc355bb80 /* 13 entries */, 1024) = 312 getdents64(9, 0x7ffdc355bb80 /* 0 entries */, 1024) = 0 close(9) = 0 close_range(11, -1, 0) = -1 EPERM (Operation not permitted) openat(AT_FDCWD, "/proc/self/fd/", O_RDONLY|O_DIRECTORY) = 9 getdents64(9, 0x7ffdc355bb80 /* 13 entries */, 1024) = 312 getdents64(9, 0x7ffdc355bb80 /* 0 entries */, 1024) = 0 close(9) .... fast looping over that lines
any ideas?
This looks like a known bug in 8.0.1116. The easiest work-around is to disable the use of closefrom(3):
Either
ac_cv_func_closefrom=no .../configure ...
or edit machine.h after running configure and remove/disable the line
#define HAVE_CLOSEFROM 1
the same under fedora 34 built correctly.
Fedora 34 most likely did not have closefrom(3).
/grubba
Actually, my vote is on removing this closefrom business completely. If we can neither trust the function to succeed (as it is documented to always do), nor reliably check whether or not it succeeded, then we should not use it.
The assertion that a failed call will always succeed if you just try it again enough times is also highly dubious...
pike-devel@lists.lysator.liu.se
-
cheese＠nosuchhost.net -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum