Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wrong source of the zlib-ng is downloaded #169

Closed
ognevny opened this issue Jan 9, 2024 · 4 comments · Fixed by #170
Closed

wrong source of the zlib-ng is downloaded #169

ognevny opened this issue Jan 9, 2024 · 4 comments · Fixed by #170

Comments

@ognevny
Copy link
Contributor

ognevny commented Jan 9, 2024

here's the reference:

...the code actually downloaded:

# head /c/Users/Administrator/.cargo/registry/src/index.crates.io-6f17d22bba15001f/libz-sys-1.1.13/src/zlib-ng/arch/arm/neon_intrins.h
#ifndef ARM_NEON_INTRINS_H
#define ARM_NEON_INTRINS_H

#ifdef _M_ARM64
#  include <arm64_neon.h>
#else
#  include <arm_neon.h>
#endif

#if defined(ARM_NEON) && !defined(__aarch64__) && !defined(_M_ARM64)

I think this is some sort of issue with how libz-sys 1.1.13 was released, somehow with different code than a fresh (recursive) checkout of the tag would have...

Originally posted in msys2/MINGW-packages#19687 (comment)

tl;dr the fix needed for aarch64-pc-windows-gnullvm isn't actually downloaded

@jeremyd2019
Copy link

jeremyd2019 commented Jan 9, 2024

Contrast with:

$ git clone -b 1.1.13 --recursive https://github.com/rust-lang/libz-sys.git 

$ head libz-sys/src/zlib-ng/arch/arm/neon_intrins.h
#ifndef ARM_NEON_INTRINS_H
#define ARM_NEON_INTRINS_H

#if defined(_MSC_VER) && (defined(_M_ARM64) || defined(_M_ARM64EC))
/* arm64_neon.h is MSVC specific */
#  include <arm64_neon.h>
#else
#  include <arm_neon.h>
#endif

@Byron
Copy link
Member

Byron commented Jan 9, 2024

Thanks so much for letting me know!

git status locally showed everything to be clean, which to my mind it shouldn't have the heads aren't at the spot that the superproject dictates.

However, running git submodule update showed…

❯ git submodule update
Submodule path 'src/zlib': checked out '09155eaa2f9270dc4ed1fa13e2b4b2613e6e4851'
Submodule path 'src/zlib-ng': checked out '2bc66887ddc0c50776811a27be68e34430d665e1'

…and more calls come out empty, making me think that it did something.

I double-checked that these are indeed the heads they are supposed to have:

gix index entries --format rich
[..]
        Mode(DIR | SYMLINK) 09155eaa2f9270dc4ed1fa13e2b4b2613e6e4851 src/zlib ➡
        Mode(DIR | SYMLINK) 2bc66887ddc0c50776811a27be68e34430d665e1 src/zlib-ng ➡

And to be sure, I triple checked:

❯ cd src/zlib

zlib (09155ea) via △
❯ ../zlib-ng

zlib-ng (2bc6688) via △
❯

Being sufficiently sure that my local state is now release-worthy, could you create a PR that bumps the patch level like before so I can merge that and create a new release?

Thanks a lot for your help.

@Byron
Copy link
Member

Byron commented Jan 9, 2024

Thanks a lot for your help.

The new release is here: https://github.com/rust-lang/libz-sys/releases/tag/1.1.14

@ognevny
Copy link
Contributor Author

ognevny commented Jan 9, 2024

Thanks a lot for your help.

The new release is here: https://github.com/rust-lang/libz-sys/releases/tag/1.1.14

thanks. I'll push a fix where needed later today

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

Successfully merging a pull request may close this issue.

3 participants