Conversation
|
@ofborg eval Seems to have stalled. Retry!! |
|
nixpkgs-review is evaluating fine here. Is it possible that ofborg is running out of memory since the updated graph is so large? |
|
It is unfortunate I didn't notice at the time, but the evaluation tests should never build anything because of precisely this problem: the evaluators are supposed to succeed even in the case of mass rebuilds. @infinisil, maybe you have ideas on ways the lib tests could be evaluation only? Otherwise, I think we'll have to drop that check until it can be made a builder check. |
|
This causes the build of |
|
Oh yeah that's a problem.. Lemme think about that.. |
|
See above two PR's which should fix the eval problem for ofborg |
|
Regarding #85951 (comment), I spent some time with @LnL7 and @lovesegfault yesterday to debug this. The failing command here is https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/setup.sh#L813, which handles the case when Apparently, with this I don't really understand why it's the |
|
I also don't understand why it's specifically The difference can be seen in the
I also guess something similar may affect other packages as well EDIT: the configure check program is: Details#define PACKAGE_NAME "GNU coreutils"
#define PACKAGE_TARNAME "coreutils"
#define PACKAGE_VERSION "8.31"
#define PACKAGE_STRING "GNU coreutils 8.31"
#define PACKAGE_BUGREPORT "[email protected]"
#define PACKAGE_URL "https://www.gnu.org/software/coreutils/"
#define PACKAGE "coreutils"
#define VERSION "8.31"
#define STDC_HEADERS 1
#define HAVE_SYS_TYPES_H 1
#define HAVE_SYS_STAT_H 1
#define HAVE_STDLIB_H 1
#define HAVE_STRING_H 1
#define HAVE_MEMORY_H 1
#define HAVE_STRINGS_H 1
#define HAVE_INTTYPES_H 1
#define HAVE_STDINT_H 1
#define HAVE_UNISTD_H 1
#define __EXTENSIONS__ 1
#define _ALL_SOURCE 1
#define _DARWIN_C_SOURCE 1
#define _GNU_SOURCE 1
#define _NETBSD_SOURCE 1
#define _OPENBSD_SOURCE 1
#define _POSIX_PTHREAD_SEMANTICS 1
#define __STDC_WANT_IEC_60559_ATTRIBS_EXT__ 1
#define __STDC_WANT_IEC_60559_BFP_EXT__ 1
#define __STDC_WANT_IEC_60559_DFP_EXT__ 1
#define __STDC_WANT_IEC_60559_FUNCS_EXT__ 1
#define __STDC_WANT_IEC_60559_TYPES_EXT__ 1
#define __STDC_WANT_LIB_EXT2__ 1
#define __STDC_WANT_MATH_SPEC_FUNCS__ 1
#define _TANDEM_SOURCE 1
#define _HPUX_ALT_XOPEN_SOCKET_API 1
#define HAVE_FSEEKO 1
#define _DARWIN_USE_64_BIT_INODE 1
#define _REENTRANT 1
#define _THREAD_SAFE 1
#define HAVE_FCHMOD 1
#define HAVE_PATHCONF 1
#define HAVE_BTOWC 1
#define HAVE_USELOCALE 1
#define HAVE_CANONICALIZE_FILE_NAME 1
#define HAVE_REALPATH 1
#define HAVE_READLINKAT 1
#define HAVE_CHOWN 1
#define HAVE_FCHOWN 1
#define HAVE_FCHDIR 1
#define HAVE_FDOPENDIR 1
#define HAVE_FACCESSAT 1
#define HAVE_EXPLICIT_BZERO 1
#define HAVE_POSIX_FADVISE 1
#define HAVE_FCHMODAT 1
/* end confdefs.h. */
/* Define lchmod to an innocuous variant, in case <limits.h> declares lchmod.
For example, HP-UX 11i <limits.h> declares gettimeofday. */
#define lchmod innocuous_lchmod
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char lchmod (); below.
Prefer <limits.h> to <assert.h> if __STDC__ is defined, since
<limits.h> exists even on freestanding compilers. */
#ifdef __STDC__
# include <limits.h>
#else
# include <assert.h>
#endif
#undef lchmod
/* Override any GCC internal prototype to avoid an error.
Use char because int might match the return type of a GCC
builtin and then its argument prototype would still apply. */
#ifdef __cplusplus
extern "C"
#endif
char lchmod ();
/* The GNU C library defines this for functions which it implements
to always fail with ENOSYS. Some functions are actually named
something starting with __ and the normal name is an alias. */
#if defined __stub_lchmod || defined __stub___lchmod
choke me
#endif
int
main ()
{
return lchmod ();
;
return 0;
}EDIT: Hmm, looking at why the test program fails / succeeds seems to come down to whether |
lovesegfault
force-pushed
the
binutils-2.34
branch
from
d2d641d to
27a8988
Compare
|
Pinged on IRC, but posting here for prosperity: the EDIT: |
Bumping binutils to 2.32 broke coreutils for unknown reasons[1]. Upon further investigation we found that there was some issue with mknod inside a chroot[2][3], which setting ac_cv_func_lchmod to "no" _somehow_ fixes. We apply this fix and hope to never have to debug this again. Thanks to @flokli and @LnL7 who helped me chase after this and @pbogdan who found the fix in the fedora build. [1]: NixOS#85951 [2]: NixOS#85951 (comment) [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1811038
- I've removed the stack of patch linked to https://sourceware.org/bugzilla/show_bug.cgi?id=23428 . The associated issue says it is closed and targeted for 2.32. - I've ugraded the "no_plugin" patch. The logic changed in https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=41f37a6fb71f2a3de388108f5cdfca9cbe6e9d51 and I tried to keep the same logic by disabling everything. It closes NixOS#78197
lovesegfault
force-pushed
the
binutils-2.34
branch
from
27a8988 to
c5f602f
Compare
|
Good catch, thanks @cole-h! I reverted that deletion |
ofborg
bot
added
10.rebuild-darwin-stdenv
ofborg
bot
added
10.rebuild-darwin: 501+
The patch to separate it from `binutils` didn't apply anymore after updating `binutils` to 2.34[1]. [1] NixOS#85951
|
This seems to have broken the kernel builds: After a |
|
I looked in to what's going on here. I think the root cause is mixing binutils 2.31 with binutils >= 2.32. Some details: Various downstream builds seem to fail due to using So why does this file contain no stubs? The build log for a failed glibc shows: A shell pipeline has masked a critical error in the glibc build. The internet says this is a mutual incompatibility between binutils 2.31 and binutils >= 2.32 due to a bug fix appearing in binutils 2.32. I'm not yet familiar with how stdenv bootstrapping transitions from bootstrap binary binutils (ie, 2.31, I assume) to the in-tree version (2.34, as of this PR). A simple resolution would be a synchronized update of the bootstrap binaries and the in-tree version such that old and new never mix. I'm hoping there's a simpler resolution from tweaking the bootstrapping. |
|
cc. @matthewbauer for bootstrapping questions |
|
Continued in #86954 |
9 participants
Motivation for this change
Noticed it was out of date and that #78204 was out of date.
cc. @guibou who did the original PR
cc. @flokli for review
c.f. https://sourceware.org/pipermail/binutils/2020-April/110818.html for discussion on the coreutils test failures reported in #78204 in the binutils ML.
Closes #78204
Things done
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)