abseil-cpp

이 문제는 512바이트 이상의 rvalue std::string을 append/prepend할 때 예상 체크섬이 설정된 빈 absl::Cord에 영향을 미칩니다. Assertion 빌드에서는 IsDataEdge()에서 edge != nullptr로 실패하며, NDEBUG 빌드에서는 segfault가 발생할 수 있습니다. 511바이트 이하의 문자열은 정상적으로 동작합니다.

absl/strings/cord.cc에서 두 rvalue 오버로드 모두 큰 문자열 트리를 생성하기 전에 빈 CRC 노드를 제거하는 업스트림 수정 사항을 적용하세요:

// Cord::Append(T&& src)에서 src.size() > 511인 else 분기 내부:
contents_.MaybeRemoveEmptyCrcNode();
CordRep* rep = CordRepFromString(std::forward<T>(src));
contents_.AppendTree(rep, CordzUpdateTracker::kAppendString);

// Cord::Prepend(T&& src)에서 이에 해당하는 else 분기 내부:
contents_.MaybeRemoveEmptyCrcNode();
CordRep* rep = CordRepFromString(std::forward<T>(src));
contents_.PrependTree(rep, CordzUpdateTracker::kPrependString);

그런 다음 Abseil과 프로젝트를 다시 빌드하세요. 패치된 버전을 사용할 수 있을 때까지는 초기 데이터가 추가된 후에 SetExpectedChecksum()을 호출하거나, 첫 번째 append/prepend를 511바이트 이하로 유지하거나, 큰 rvalue std::string 경로 대신 absl::string_view append/prepend 경로를 사용하여 버그를 우회하세요.

이 문제는 이동 대입에서 전파되지 않으며 서로 같지 않은 것으로 비교되는 할당자를 사용할 때 발생합니다. std::list는 대상 할당자로 노드를 다시 생성하지만, linked_hash_set의 내부 반복자 인덱스는 여전히 소스 노드를 가리키고 있으며, 이 소스 노드는 이후 해제됩니다. linked_hash_map의 경우에도 std::pair<const K, V>에 대한 요소 대입이 ill-formed이기 때문에 컴파일에 실패할 수 있습니다.

해결 방법: 커밋 d5c2f53dfc56c6d0d65a93a5e303c16a046e5fe6이 포함된 릴리스로 Abseil을 업데이트하거나, 해당 패치를 적용한 후 다시 빌드하세요.

임시 해결 방법:
- 두 컨테이너가 동일한 것으로 비교되는 할당자를 사용하도록 하세요. 예를 들어 동일한 std::pmr::memory_resource를 사용합니다:

Set a{Alloc(&resource)};
Set b{Alloc(&resource)}; // same resource
b = std::move(a);        // safe

b.clear();
for (const auto& x : a) b.insert(x);
a.clear();

이 문제는 Abseil 커밋 71330b9에서 발생합니다. ABSL_HAVE_ELF_MEM_IMAGE가 모든 __ELF__ 타겟에 대해 활성화되지만, newlib를 사용하는 arm-none-eabi-g++와 같은 베어메탈 툴체인은 glibc의 <link.h>를 제공하지 않은 채 ELF 오브젝트를 생성하기 때문입니다.

즉시 적용 가능한 해결 방법: absl/debugging/internal/elf_mem_image.h를 편집하여 ABSL_HAVE_ELF_MEM_IMAGE를 정의하는 기존 #if에 <link.h> 사용 가능 여부 검사를 추가하세요:

!defined(__XTENSA__) && __has_include(<link.h>)

예를 들어, 조건은 다음과 같이 끝나야 합니다:

#if defined(__ELF__) &&
    // ...existing deny-list checks...
    !defined(__XTENSA__) && __has_include(<link.h>)
#define ABSL_HAVE_ELF_MEM_IMAGE 1
#endif

이렇게 하면 필요한 헤더가 없는 경우에만 ELF 메모리 이미지 지원이 비활성화됩니다. __has_include는 C++17에서 사용할 수 있으며 Abseil의 다른 부분에서도 이미 사용되고 있습니다.

다음 명령으로 확인하세요:

arm-none-eabi-g++ -std=c++17 -I. -fsyntax-only absl/debugging/internal/elf_mem_image.cc
arm-none-eabi-g++ -std=c++17 -I. -fsyntax-only absl/debugging/internal/vdso_support.cc

업스트림 수정에서는 <link.h>를 사용할 수 없을 때 <elf.h>를 사용하고 ElfW를 로컬에서 정의하는 방식으로 지원을 계속 활성화할 수도 있으므로, 가능한 경우 수정된 Abseil 릴리스로 업데이트하는 것이 바람직합니다.

이 오류는 MSVC/CMake를 사용하여 Windows에서 Abseil v20260817.0을 DLL로 빌드할 때 발생합니다: CMake/AbseilDll.cmake 파일이 여전히 제거된 crc_cpu_detect 빌드 타겟을 참조하고 있으며, 이 타겟은 absl/base/CMakeLists.txt에서 base_cpu_detect로 대체되었습니다. 다음 수동 수정 방법을 적용하세요: 1. Abseil 소스 디렉터리에서 CMake/AbseilDll.cmake 파일을 열고 약 548번째 줄로 이동합니다. 2. crc_cpu_detect에 대한 참조를 base_cpu_detect로 바꿉니다. 3. CMake configure 명령을 다시 실행하고 프로젝트를 다시 빌드합니다.

이것은 Abseil issue #2148입니다. arm-none-eabi와 같은 newlib 타겟에서는 int32_t가 일반 int가 아니라 long int이므로, int 인자가 어떤 EncodeVarint 오버로드와도 정확히 일치하지 않습니다. bool 인자도 모호할 수 있습니다. 수정 사항이 포함된 리비전으로 Abseil을 업데이트하거나, 고정 너비 오버로드로 전달하는 명시적인 int 및 bool 오버로드를 absl/log/internal/proto.h에 추가하세요:

bool EncodeVarint(uint64_t field_number, int value,
                  absl::Span<char>* buf) {
  return EncodeVarint(field_number, static_cast<int32_t>(value), buf);
}

bool EncodeVarint(uint64_t field_number, bool value,
                  absl::Span<char>* buf) {
  return EncodeVarint(field_number, static_cast<uint64_t>(value), buf);
}

기존 함수가 헤더에만 선언되어 있는 경우, 일치하는 선언을 추가하고 전달 정의는 proto.cc에 넣으세요. 동등한 해결 방법으로는 호출 지점에서 source_line()을 int32_t로 캐스팅하는 방법과 인코딩 전에 bool 값을 uint64_t로 명시적으로 캐스팅하는 방법이 있습니다. 예를 들어 다음과 같이 다시 빌드하세요:

arm-none-eabi-g++ -std=c++17 -I. -fsyntax-only \
  absl/log/internal/structured_proto.cc \
  absl/log/internal/log_message.cc