0.10.0 h7e5bf1

[tdejager]

Checklist

• Used a personal fork of the feedstock to propose changes
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering) yes, took the automatic PR as a base

This PR attempts to use the latest version of zig, and also tries to build for osx. But there are still some issues with that, opening it here so it will also run in CI.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[xmnlab]

It looks like it has a memory issue on the liking phase

https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=612288&view=logs&j=656edd35-690f-5c53-9ba3-09c10d0bea97&t=e5c8ab1d-8ff9-5cae-b332-e15ae582ed2d

A 137 code is issued when a process is terminated externally because of its memory consumption. The operating system's out of memory manager (OOM) intervenes to stop the program before it destabilizes the host. As this example returned 137, you know that demo-binary was stopped because it used too much memory.

Not sure yet how to proceed here, maybe there is a way to have the linking phase consuming less memory or maybe we could increase the memory on CI ...

[tdejager]

Hmm, that is an issue, not sure if we could use a different linker under linux e.g.

[tdejager]

@conda-forge-admin please rerender

[tdejager]

It looks like it has a memory issue on the liking phase

https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=612288&view=logs&j=656edd35-690f-5c53-9ba3-09c10d0bea97&t=e5c8ab1d-8ff9-5cae-b332-e15ae582ed2d

A 137 code is issued when a process is terminated externally because of its memory consumption. The operating system's out of memory manager (OOM) intervenes to stop the program before it destabilizes the host. As this example returned 137, you know that demo-binary was stopped because it used too much memory.

Not sure yet how to proceed here, maybe there is a way to have the linking phase consuming less memory or maybe we could increase the memory on CI ...

Also, how did you discern that it hat the exit-code or 137? Scrolling through the logs I only see an exit code of 2. I'm probably missing something?

[tdejager]

I suppose option B could be a solution as listed here: https://github.com/ziglang/zig/wiki/Building-Zig-From-Source#option-b-use-a-pre-built-zig-binary

[xmnlab]

Before the error 2 has an error 137

[xmnlab]

Not sure if it would fix the problem, but it uses mamba instead of conda for building the package.@ocefpaf told me that mamba is faster but consumes more memory so maybe you could try to replace here mamba by conda

zig-feedstock/.scripts/build_steps.sh

Line 60 in 62269ba

conda mambabuild "${RECIPE_ROOT}" -m "${CI_SUPPORT}/${CONFIG}.yaml" \

So there, change "conda mambabuild" to "conda build"

[wolfv]

I think our experience was that mamba uses less memory :) (at least that is what the readthedocs people found!).

[ocefpaf]

I think our experience was that mamba uses less memory :) (at least that is what the readthedocs people found!).

Maybe my info is outdated then. To be fair, I only use micromamba lately :-)

[xmnlab]

I suppose option B could be a solution as listed here: https://github.com/ziglang/zig/wiki/Building-Zig-From-Source#option-b-use-a-pre-built-zig-binary

no objection from my side, maybe we could try it and check with the conda-forge core if it is a valid approach here.

[tdejager]

I suppose option B could be a solution as listed here: https://github.com/ziglang/zig/wiki/Building-Zig-From-Source#option-b-use-a-pre-built-zig-binary

no objection from my side, maybe we could try it and check with the conda-forge core if it is a valid approach here.

Might be wise indeed, it will also make the compile take a lot longer.. Not sure how homebrew for example is dealing with this, they seem to be using Option A). Also, they are linking statically, which I assume would use at least use as much memory or more when compared to linking dynamically.

@wolfv @ocefpaf any idea what the max amount of memory is in the Azure VM?

[xmnlab]

it seems this PR fixed the problem: ziglang/zig#13560

@ocefpaf what would be a better approach to have it here?
get the source directly from that commit? or maybe create a patch file with all changes since the tag was released?

[ocefpaf]

@ocefpaf what would be a better approach to have it here?
get the source directly from that commit? or maybe create a patch file with all changes since the tag was released?

Usually we patch small things but those changes are 68 commits and 579 file changes!!! What are the chances of getting a new release? If not, one alternative is to get the source from that commit but publish it as a dev release following CFEP-05.

[xmnlab]

got it .. thanks for the explanation @ocefpaf ! appreciate that

[tdejager]

Probably this will be included in the next zig release I suppose, but then you would be missing 0.10 from conda-forge

[xmnlab]

What are the chances of getting a new release?

@ocefpaf , the estimate data for that is by the end of may: https://github.com/ziglang/zig/milestone/17

one alternative is to get the source from that commit but publish it as a dev release following CFEP-05.

@tdejager is it something that you would like to work on?

[tdejager]

@wolfv is trying with more memory (swap) in the Azure vm. Which would still be the easiest I think

[tdejager]

Seems like 2 things going on:

1. Missing pthread_nonshared for the linux64 build. Not sure what we would need to depend on to get this resolved.
2. In the OSX build unpacking the system sdk runs into a problem. Maybe because it's being untarred while also being xz compressed. See: https://askubuntu.com/a/407911 . Don't know if that is still relevant.

[wolfv]

I checked, and that file (libpthread_nonshared.a) can be found in the sysroot_linux-64 package under $PREFIX/x86_64-conda-linux-gnu/usr/lib64/libpthread_nonshared.a. I don't know how to teach that to zig or CMake, though, because I couldn't find where it searches for this library.

[wolfv]

Worst case adding a symlink might work (is statically linked anyways), haha (ln -s /usr/lib/libpthread_nonshared.a $BUILD_PREFIX/...)

[xmnlab]

Worst case adding a symlink might work (is statically linked anyways), haha (ln -s /usr/lib/libpthread_nonshared.a $BUILD_PREFIX/...)

@tdejager , is it something you could do? Thanks

[pavelzw]

Nowadays you can also create a swapfile, but I think only for linux runners. https://github.com/conda-forge/polars-feedstock/blob/81713313ff444aea8c755d9e4fcb7102555dde3a/conda-forge.yml#L13-L15

conda-forge/conda-smithy#1751

[jakirkham]

Do we need 0.10.0 specifically or would 0.11.0 be ok? Asking since that release came out a couple months ago so is a bit more recent (and may have addressed some of these build issues)

[pavelzw]

I tried v0.11.0 in #9. One major problem is that zig requires glibc >=2.25. Not sure how this is handled in conda-forge packages.

[jakirkham]

Oh interesting. Maybe we should try 0.10.1 first then

[MementoRC]

@wolfv Do you think we still need 0.10.0? I think I have an acceptable 0.13.0 build recipe for linux x86_64/aarch64 and osx. If so, I would prefer to build it with the newer recipe in a separate branch

[jakirkham]

It looks like we are already on 0.12.0: #10

Maybe we should close?

Thanks all for the efforts on getting this updated! 🙏

[MementoRC]

@jakirkham Yes, I'd prefer close and reopen as a separate branch if needed. We are actually on 0.13.0, adding osx and aarch64 ;P

We are having a lot of difficulties with win and ppc64le. I would like to try a 2xlarge for windows (I saw a PR related to that, but don't know if I can simply apply it to test out the win build)

[jakirkham]

Please go ahead with a new PR. We can discuss CI setup in that PR

[MementoRC]

Closing. If needed, we will create a branch from the latest recipe