Skip to content

Fixes for 0.1.0rc1 - #239

Open
embray wants to merge 7 commits into
asdf-format:mainfrom
embray:release-0.1.0-followups
Open

Fixes for 0.1.0rc1#239
embray wants to merge 7 commits into
asdf-format:mainfrom
embray:release-0.1.0-followups

Conversation

@embray

@embray embray commented Jul 27, 2026

Copy link
Copy Markdown
Collaborator

Description

Fixes for various issues found while trying to build the new conda-forge recipe I added at conda-forge/staged-recipes#34323

Would have been good to test this first but that's exactly why I decided to make a release candidate first; adding an rc1 is no big deal, then I can point the conda-forge recipe to that.

One caveat: These fixes fix the conda-forge build for me locally on Linux, but I don't have any way to test it locally on macOS so hopefully no additional problems will be discovered there...

AI Disclosure

No AI tools used.

embray added 5 commits July 27, 2026 15:18
In particular, try UFFD_USER_MODE_ONLY flag even if it wasn't defined in
the kernel headers (as on Conda) and refactor to better support caching
the result of the probe at the process-level.

This gets rid of the previous hack "warning: UFFD_USER_MODE_ONLY_MISSING"
which was actually the wrong behavior for Linux 5.11+ kernels.
Just use the portable ``PRI<T>`` macros.
ci: fix this in the CI as well; will be curious to see how this impacts
the macOS build (which was still compiling without MD5 support
previously)
This would cause the malloc-fail tests to break since they wrap strdup
by symbol name (which is replaced with __strdup if the inline versions
are defined).  This can be disabled in bits/string2.h by defining
__NO_STRING_INLINES.
@embray embray added documentation Improvements or additions to documentation release Tasks related to preparing and publishing releases build Issues related to build system problems or enhancements labels Jul 27, 2026
@embray
embray force-pushed the release-0.1.0-followups branch from 9189946 to 38bfc1d Compare July 27, 2026 15:20
@embray

embray commented Jul 27, 2026

Copy link
Copy Markdown
Collaborator Author

Hmm...

/Users/runner/work/libasdf/libasdf/tests/shell-test.sh: line 56:  8151 Abort trap: 6           ${asdfprog} ${SUBCOMMAND} ${EXTRA_ARGS} "$input" 2>&1 > "$actual"
--- /Users/runner/work/libasdf/libasdf/tests/fixtures/verify-checksums/255-2-blocks.verify-checksums.txt	2026-07-27 15:20:47
+++ /Users/runner/work/libasdf/libasdf/build/tests/tmp/255-2-blocks.verify-checksums.out.txt	2026-07-27 15:21:51
@@ -1,4 +0,0 @@
-Block 0: OK
-  checksum: e2c865db4162bed963bfaa9ef6ac18f0
-Block 1: OK
-  checksum: e2c865db4162bed963bfaa9ef6ac18f0
❌ Test failed: 255-2-blocks

Now that we actually are building with MD5 support on macOS this error is everywhere. Investigating.... 😞

@embray

embray commented Jul 27, 2026

Copy link
Copy Markdown
Collaborator Author

Ugh, confirmed:

                 (undefined) external _MD5Final (from libSystem)
                 (undefined) external _MD5Init (from libmd)
                 (undefined) external _MD5Update (from libmd)

This is the same as irods/irods#2578

@embray

embray commented Jul 27, 2026

Copy link
Copy Markdown
Collaborator Author

Well investigating the build logs I also realized there are still some "error: Invalid UTF8 (invalid) in the input stream" coming from libfyaml; that was supposed to be fixed I thought in 2b20d02 ; this has come up a few times actually. But despite the error log the tests were still silently passing so whatever the issue is there wasn't a blocker, but it's still a bit jarring.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

build Issues related to build system problems or enhancements documentation Improvements or additions to documentation release Tasks related to preparing and publishing releases

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant