libgcrypt: bump to v1.11. #9680
Conversation
|
Well, this is weird. Locally, |
Fixed by forcing v1.50, although I'm still confused why it wouldn't use this with a
I wonder if part of the host environment is leaking into the build, making it end up building different sources, or using different options? The code is hidden behind a feature flag: https://github.com/gpg/libgcrypt/blob/4876a1a45c25d7e3ffb45a0af4e7c8995ce3a552/random/jitterentropy-base-user.h#L81-L98 EDIT: so locally, the build does reach that branch, which means |
c3d2374 to
e871619
Compare
|
MWE: #include <stdint.h>
typedef uint64_t u64;
#include <time.h>
static void
jent_get_nstime(u64 *out)
{
struct timespec tv;
u64 tmp;
/* On Linux we could use CLOCK_MONOTONIC(_RAW), but with
* CLOCK_REALTIME we get some nice extra entropy once in a while
* from the NTP actions that we want to use as well... though, we do
* not rely on that extra little entropy. */
if (!clock_gettime (CLOCK_REALTIME, &tv))
{
tmp = tv.tv_sec;
tmp = tmp << 32;
tmp = tmp | tv.tv_nsec;
}
else
tmp = 0;
*out = tmp;
}With Yggdrasil cloned on amdci7 and instantiating the CI Manifest, I get: On my local system, with otherwise the exact same set-up, everything works fine... Some part of the set-up isn't identical though, but I'm not sure how or why. Locally: On Yggdrasil: |
|
It even reproduces with a fresh depot... Here's the verbose logs of both invocations, one on my local system, one on amdci7: https://gist.github.com/maleadt/e5764478bf01b161842ee1e0bc0edea9 @giordano I'm out of ideas here, do you have any? The logs look mostly identical. Despite starting with a fresh depot, one That specific header doesn't provide vs. on the 'bad' system: Another breadcrumb: These two artifacts map onto the Aha, something corroborating that: In the log I posted above, you can see how both systems map the artifacts in a different order: vs Notice how |
% find build/i686-w64-mingw32/*/.mounts -name time.h -exec md5sum {} \; 2> /dev/null | sort
14a0dab31a3dea92cbbe2fd9a40c9072 build/i686-w64-mingw32/yNJdRiPh/.mounts/GCCBootstrap-x86_64-linux-musl.v4.8.5.x86_64-linux-musl.squashfs/x86_64-linux-musl/sys-root/usr/include/time.h
25b6994f6b4e75f2ce9582f5ac81af78 build/i686-w64-mingw32/yNJdRiPh/.mounts/GCCBootstrap-i686-w64-mingw32.v4.8.5.x86_64-linux-musl.squashfs/i686-w64-mingw32/sys-root/include/time.h
29e1e232fdf102bf5c56856c8a066ed8 build/i686-w64-mingw32/yNJdRiPh/.mounts/PlatformSupport-i686-w64-mingw32.v2024.8.10.x86_64-linux-musl.squashfs/i686-w64-mingw32/sys-root/include/time.h
7e6318050651a97ad6076a81e6384cb1 build/i686-w64-mingw32/yNJdRiPh/.mounts/LLVMBootstrap.v18.1.7.x86_64-linux-musl.squashfs/lib/clang/18/include/llvm_libc_wrappers/time.h
849dabb9216c8f53bbf721c4720a9356 build/i686-w64-mingw32/yNJdRiPh/.mounts/GCCBootstrap-i686-w64-mingw32.v4.8.5.x86_64-linux-musl.squashfs/i686-w64-mingw32/sys-root/include/sys/time.h
849dabb9216c8f53bbf721c4720a9356 build/i686-w64-mingw32/yNJdRiPh/.mounts/PlatformSupport-i686-w64-mingw32.v2024.8.10.x86_64-linux-musl.squashfs/i686-w64-mingw32/sys-root/include/sys/time.h
a8f8234ef9e90aae9be3252e80c1d2b6 build/i686-w64-mingw32/yNJdRiPh/.mounts/GCCBootstrap-x86_64-linux-musl.v4.8.5.x86_64-linux-musl.squashfs/x86_64-linux-musl/sys-root/usr/include/linux/time.h
a8f8234ef9e90aae9be3252e80c1d2b6 build/i686-w64-mingw32/yNJdRiPh/.mounts/PlatformSupport-x86_64-linux-musl.v2024.8.10.x86_64-linux-musl.squashfs/x86_64-linux-musl/sys-root/usr/include/linux/time.h
adeb9c7928c2fb4c364d63f7938472d9 build/i686-w64-mingw32/yNJdRiPh/.mounts/GCCBootstrap-x86_64-linux-musl.v4.8.5.x86_64-linux-musl.squashfs/x86_64-linux-musl/sys-root/usr/include/sys/time.hthat seems to be the problem, yes. Interesting we never ran into this before, also not great the two artifacts step onto each other's toes. |
|
Perhaps using two wildly different versions of mingw at Yggdrasil/0_RootFS/gcc_sources.jl Lines 278 to 279 in ff8aa2b Yggdrasil/0_RootFS/PlatformSupport/build_tarballs.jl Lines 52 to 53 in ff8aa2b |
Yggdrasil/M/MGARD/build_tarballs.jl Lines 45 to 47 in ff8aa2b Also, FWIW, the |
|
Ah, the reference to notcurses brought me to #4059 (comment) and #4059 (comment). I'm somewhat convinced that in platformsupports we should at very least match what we do in gccbootstrap, or just remove that, since I'm missing why we duplicate the work (and do it wrong). I wonder if @staticfloat would have some opinions about this 😇 |
2a13800 to
c54846c
Compare
My opinion is that PlatformTools is very ill-defined, and instead we should be directly using the Mingw JLLs where needed, which makes it much more explicit when and where these header files are included. BB2 does this, but progress on that front continues, despite its slowness. |
This takes inspiration from JuliaPackaging#9680 to raise the compatibility bound of the Libgpg_error_jll dependency to include a version that has the necessary FreeBSD support
* [XSLT] Update dependency for freebsd-aarch64 support This takes inspiration from #9680 to raise the compatibility bound of the Libgpg_error_jll dependency to include a version that has the necessary FreeBSD support * [XSLT] Update to v1.1.42 * Work around win32 build error by requesting older build version of XML2 * Revert "Work around win32 build error by requesting older build version of XML2" This reverts commit 36f9939. * Change to requiring GCC 11
No description provided.