cc: @dongjoon-hyun @wgtmac

Do we need to backport to another branch, because on macOS 15.4.1 make pacage fails because the zlib version too low ?

@cxzl25 . Could you provide us more details? Specifically, which branches do you mean?

FYI, we have CI test coverages for MacOS 15.4.1. Supporting additional newer OSes is an improvement, but we need to backport CI test coverage if that's required.

Here is the GitHub Action result.

• main: https://github.com/apache/orc/actions/runs/14839653954/job/41659287344
• branch-2.1: https://github.com/apache/orc/actions/runs/14839616139/job/41659155376
• branch-2.0: https://github.com/apache/orc/actions/runs/14816974550/job/41598733062

Operating System
  macOS
  15.4.1
  24E263

branch-2.0 seems to pass MacOS 15.4.1 tests without ORC-1827. Could you double-check it?

cc @wgtmac (Please correct me if I'm wrong).

Hmm, I didn't hit this issue on my Mac 15.4.1. BTW, usually downstream users in production do not use the vendored zlib. So I think it is fine to not backport this?

Thank you for the confirmation, @wgtmac . Yes, it does. Usually, we don't want to take a risk to change dependencies on the released branches. It's only allowed exceptionally when there are critical issues like CVEs.

Could you provide us more details?

[ 13%] Performing configure step for 'zlib_ep'
-- zlib_ep configure command succeeded.  See also /tmp/v2.0.5-rc0/orc-2.0.5/build/zlib_ep-prefix/src/zlib_ep-stamp/zlib_ep-configure-*.log
[ 14%] Performing build step for 'zlib_ep'
CMake Error at /tmp/v2.0.5-rc0/orc-2.0.5/build/zlib_ep-prefix/src/zlib_ep-stamp/zlib_ep-build-RELEASE.cmake:49 (message):
  Command failed: 2

   '/Library/Developer/CommandLineTools/usr/bin/make'

  See also

    /tmp/v2.0.5-rc0/orc-2.0.5/build/zlib_ep-prefix/src/zlib_ep-stamp/zlib_ep-build-*.log


make[2]: *** [zlib_ep-prefix/src/zlib_ep-stamp/zlib_ep-build] Error 1
make[1]: *** [CMakeFiles/zlib_ep.dir/all] Error 2
make: *** [all] Error 2

make --version
GNU Make 3.81

build log

In file included from /tmp/v2.0.5-rc0/orc-2.0.5/build/zlib_ep-prefix/src/zlib_ep/adler32.c:8:
/tmp/v2.0.5-rc0/orc-2.0.5/build/zlib_ep-prefix/src/zlib_ep/zutil.h:163:11: warning: 'OS_CODE' macro redefined [-Wmacro-redefined]
  163 | #  define OS_CODE 19
      |           ^
/tmp/v2.0.5-rc0/orc-2.0.5/build/zlib_ep-prefix/src/zlib_ep/zutil.h:134:11: note: previous definition is here
  134 | #  define OS_CODE  7


In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX15.4.sdk/usr/include/stdio.h:61:
/Library/Developer/CommandLineTools/SDKs/MacOSX15.4.sdk/usr/include/_stdio.h:318:7: error: expected identifier or '('
  318 | FILE    *fdopen(int, const char *) __DARWIN_ALIAS_STARTING(__MAC_10_6, __IPHONE_2_0, __DARWIN_ALIAS(fdopen));
      |          ^

4 warnings and 3 errors generated.
make[5]: *** [CMakeFiles/zlib.dir/zutil.o] Error 1
make[4]: *** [CMakeFiles/zlib.dir/all] Error 2
make[3]: *** [all] Error 2

It looks weird.

• Did you check the difference between your local environment and GitHub Action MacOS 15?
• Do all 2.0.x tag fail to build in your local environment?

I probably found the reason, the AppleClang 16 version used by github, and the AppleClang 17 version used by MacOS 15.4.

https://github.com/apache/orc/actions/runs/14816974550/job/41598733062

-- The C compiler identification is AppleClang 16.0.0.16000026
-- The CXX compiler identification is AppleClang 16.0.0.16000026

MacOS 15.4

-- The C compiler identification is AppleClang 17.0.0.17000013
-- The CXX compiler identification is AppleClang 17.0.0.17000013

If I specify the lower version of llvm, it can be compiled in branch 2.0

export LDFLAGS="-L/opt/homebrew/opt/llvm@16/lib"
export CPPFLAGS="-I/opt/homebrew/opt/llvm@16/include"

https://github.com/ahrm/sioyek/issues/1361

https://github.com/madler/zlib/commit/4bd9a71f3539b5ce47f0c67ab5e01f3196dc8ef9

Thank you for the investigation, @cxzl25 .

I tried locally today with AppleClang 17, but it seems that I failed snappy first. I can confirm that we have issues with new versions. Do we need more backports in addition to ZLIB (ORC-1827), @cxzl25 ?

$ g++ --version | head -n1
Apple clang version 17.0.0 (clang-1700.0.13.3)

...
[  9%] Performing configure step for 'snappy_ep'
CMake Error at /Users/dongjoon/APACHE/orc-merge/build/snappy_ep-prefix/src/snappy_ep-stamp/snappy_ep-configure-RELWITHDEBINFO.cmake:49 (message):
  Command failed: 1

   '/opt/homebrew/bin/cmake' '-DCMAKE_INSTALL_PREFIX=/Users/dongjoon/APACHE/orc-merge/build/c++/libs/thirdparty/snappy_ep-install' '-DBUILD_SHARED_LIBS=OFF' '-DCMAKE_INSTALL_LIBDIR=lib' '-DSNAPPY_BUILD_TESTS=OFF' '-GUnix Makefiles' '-S' '/Users/dongjoon/APACHE/orc-merge/build/snappy_ep-prefix/src/snappy_ep' '-B' '/Users/dongjoon/APACHE/orc-merge/build/snappy_ep-prefix/src/snappy_ep-build'

  See also

    /Users/dongjoon/APACHE/orc-merge/build/snappy_ep-prefix/src/snappy_ep-stamp/snappy_ep-configure-*.log


make[2]: *** [snappy_ep-prefix/src/snappy_ep-stamp/snappy_ep-configure] Error 1
make[1]: *** [CMakeFiles/snappy_ep.dir/all] Error 2

but it seems that I failed snappy first

I cannot reproduce the build snappy failure in MacOS 15.5. We need to check snappy_ep-configure-*.log to know the reason for the failure.

Have you tried to upgrade the snappy version of ThirdpartyToolchain.cmake ?

No, the failure happens on the vanilla branch-2.0.

Have you tried to upgrade the snappy version of ThirdpartyToolchain.cmake ?

Due to the above failure, I couldn't validate ZLIB until yet.

I would be fine for backporting ZLIB if there is a common ground for the situation. Given the situation where your and my local environment cannot match at all, I'm a little reluctant to make a decision on branch-2.0 because it could be the same for the others.

We need a verifiable way to move forward. I can image the following ways.
A. When MacOS 15 CI starts to fail on the vanilla branch-2.0, we can start to backport the required patches like ZLIB, Snappy or more
B. When MacOS 15 CI starts to fail, we may want to drop MacOS 15 from the CI test pipeline in old branches.
C. By revising GitHub Action settings, we may find a way to make MacOS 15 CI fail . Then, we can start (A) and (B) decision immediately.

BTW, which branch do you need this, @cxzl25 ?

• Technically, MacOS 15 supported is added at Apache ORC 2.0+.
• I guess we can backport up to branch-2.0. For branch-1.9, we need to consider more.

A. When MacOS 15 CI starts to fail on the vanilla branch-2.0, we can start to backport the required patches like ZLIB, Snappy or more

I think option A is fine, let's see if other developers have encountered this problem before deciding if we need a backport or not.

Thank you. @dongjoon-hyun