abseil/abseil-cpp

libmusl: error: 'off64_t' has not been declared

Mizux opened this issue · 4 comments

Mizux commented

Describe the issue

[  4%] Building CXX object _deps/absl-build/absl/base/CMakeFiles/malloc_internal.dir/internal/low_level_alloc.cc.o
cd /home/project/build/_deps/absl-build/absl/base && /usr/bin/c++  -isystem /home/project/build/_deps/absl-src -O3 -DNDEBUG -std=c++17 -fPIC -Wall -Wextra -Wcast-qual -Wconversion-null -Wformat-security -Wmissing-declarations -Woverlength-strings -Wpointer-arith -Wundef -Wunused-local-typedefs -Wunused-result -Wvarargs -Wvla -Wwrite-strings -DNOMINMAX -MD -MT _deps/absl-build/absl/base/CMakeFiles/malloc_internal.dir/internal/low_level_alloc.cc.o -MF CMakeFiles/malloc_internal.dir/internal/low_level_alloc.cc.o.d -o CMakeFiles/malloc_internal.dir/internal/low_level_alloc.cc.o -c /home/project/build/_deps/absl-src/absl/base/internal/low_level_alloc.cc
In file included from /home/project/build/_deps/absl-src/absl/base/internal/low_level_alloc.cc:26:
/home/project/build/_deps/absl-src/absl/base/internal/direct_mmap.h:75:25: error: 'off64_t' has not been declared
   75 |                         off64_t offset) noexcept {
      |                         ^~~~~~~
make[2]: *** [_deps/absl-build/absl/base/CMakeFiles/malloc_internal.dir/build.make:76: _deps/absl-build/absl/base/CMakeFiles/malloc_internal.dir/internal/low_level_alloc.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:2610: _deps/absl-build/absl/base/CMakeFiles/malloc_internal.dir/all] Error 2
make[2]: Leaving directory '/home/project/build'
make[1]: Leaving directory '/home/project/build'
make: *** [Makefile:166: all] Error 2
The command '/bin/sh -c cmake --build build --target all -v' returned a non-zero code: 2
make: Leaving directory '/home/runner/work/or-tools/or-tools/cmake'
make: *** [Makefile:338: alpine_cpp_build] Error 2

ref: https://github.com/google/or-tools/actions/runs/4668224407/jobs/8265016854#step:6:2211

spotted also here: https://bugs.gentoo.org/906218

Steps to reproduce the problem

google/or-tools, [main] branch, alpine jobs

git clone -b main git@github.com:google/or-tools.git
# run ci jobs (docker alpine orchestrated through a Makefile)
make --directory=cmake alpine_cpp_build

trace: https://github.com/google/or-tools/actions/runs/4668224407/jobs/8265016854#step:6:2211

What version of Abseil are you using?

last release + small patch (20230125.3)
(your cmake is still borken (spotted few months ago) TLDR on debian and since cmake 3.19 IIRC CMAKE_CXX_FLAGS is not injected when "trying to build" (you should drop kokoro and leverage github workflows with docker + make) -> fallback to c++14 even when c++20 is set... -> need to send a report or file a buganiser asap -_-)
ref: https://github.com/google/or-tools/blob/b9609e774988f83a59247efadc6f781832fecd3a/cmake/dependencies/CMakeLists.txt#L84-L86

What operating system and version are you using?

docker alpine:edge

What compiler and version are you using?

The CXX compiler identification is GNU 12.2.1

What build system are you using?

CMake (bazel is borken on windows/macos when using auto-config toolchain)

Additional context

Just FYI and link this issue with gentoo tracker...

Mizux commented

// Platform specific logic extracted from
// https://chromium.googlesource.com/linux-syscall-support/+/master/linux_syscall_support.h
inline void* DirectMmap(void* start, size_t length, int prot, int flags, int fd,
off64_t offset) noexcept {

In https://chromium.googlesource.com/linux-syscall-support/+/master/linux_syscall_support.h
we can see:

#elif defined(__x86_64__)
--
/* Need to make sure __off64_t isn't truncated to 32-bits under x32.  */
LSS_INLINE void* LSS_NAME(mmap)(void *s, size_t l, int p, int f, int d,
int64_t o) {
LSS_BODY(6, void*, mmap, LSS_SYSCALL_ARG(s), LSS_SYSCALL_ARG(l),
LSS_SYSCALL_ARG(p), LSS_SYSCALL_ARG(f),
LSS_SYSCALL_ARG(d), (uint64_t)(o));
}
#else
/* Remaining 64-bit architectures. */
LSS_INLINE _syscall6(void*, mmap, void*, addr, size_t, length, int, prot,
int, flags, int, fd, int64_t, offset)

You should replace off64_t by int64_t

Unfortunately this needs to be rolled back again.

Mizux commented

seems related to:

Looks like this was a false alarm. It did not need to be rolled back.