abseil-cpp

This affects an empty absl::Cord with an expected checksum when appending/prepending an rvalue std::string of 512 bytes or more. Assertion builds fail with edge != nullptr in IsDataEdge(); NDEBUG builds can segfault. Strings of 511 bytes or smaller work.

Apply the upstream fix in absl/strings/cord.cc by removing the empty CRC node before creating the large-string tree in both rvalue overloads:

// In Cord::Append(T&& src), inside the else branch for src.size() > 511:
contents_.MaybeRemoveEmptyCrcNode();
CordRep* rep = CordRepFromString(std::forward<T>(src));
contents_.AppendTree(rep, CordzUpdateTracker::kAppendString);

// In Cord::Prepend(T&& src), inside the equivalent else branch:
contents_.MaybeRemoveEmptyCrcNode();
CordRep* rep = CordRepFromString(std::forward<T>(src));
contents_.PrependTree(rep, CordzUpdateTracker::kPrependString);

Then rebuild Abseil and your project. Until the patched version is available, work around the bug by calling SetExpectedChecksum() after the initial data is added, keeping the first append/prepend at 511 bytes or smaller, or using the absl::string_view append/prepend path instead of the large rvalue std::string path.

This happens when move assignment uses allocators that do not propagate and compare unequal. std::list recreates its nodes with the destination allocator, but linked_hash_set's internal iterator index still points to the source nodes, which are then freed. linked_hash_map can also fail to compile because element assignment is ill-formed for std::pair<const K, V>.

Fix: update Abseil to a release containing commit d5c2f53dfc56c6d0d65a93a5e303c16a046e5fe6, or apply that patch and rebuild.

Temporary workarounds:
- Ensure both containers use allocators comparing equal, e.g. the same 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();

This occurs on Abseil commit 71330b9 because ABSL_HAVE_ELF_MEM_IMAGE is enabled for every __ELF__ target, but bare-metal toolchains such as arm-none-eabi-g++ with newlib produce ELF objects without shipping glibc's <link.h>.

Immediate workaround: edit absl/debugging/internal/elf_mem_image.h and add a <link.h> availability check to the existing #if that defines ABSL_HAVE_ELF_MEM_IMAGE:

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

For example, the condition should end with:

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

This disables ELF memory-image support only when the required header is absent. __has_include is available under C++17 and is already used elsewhere in Abseil.

Verify with:

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

An upstream fix may instead keep support enabled by using <elf.h> and defining ElfW locally when <link.h> is unavailable, so updating to a fixed Abseil release is preferred when available.

This error occurs when building Abseil v20260817.0 as a DLL on Windows with MSVC/CMake: the CMake/AbseilDll.cmake file still references the removed crc_cpu_detect build target, which has been replaced by base_cpu_detect in absl/base/CMakeLists.txt. Apply the manual fix: 1. Open CMake/AbseilDll.cmake in your Abseil source directory and navigate to approximately line 548. 2. Replace the reference to crc_cpu_detect with base_cpu_detect. 3. Re-run your CMake configure command and rebuild the project.

This is Abseil issue #2148. On newlib targets such as arm-none-eabi, int32_t is long int, not plain int, so an int argument does not exactly match any EncodeVarint overload. A bool argument can also be ambiguous. Update Abseil to a revision containing the fix, or add explicit int and bool overloads in absl/log/internal/proto.h that forward to fixed-width overloads:

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);
}

If the existing functions are declared only in the header, add matching declarations and put the forwarding definitions in proto.cc. Equivalent workarounds are casting source_line() to int32_t at the call site and explicitly casting bool values to uint64_t before encoding. Rebuild with, for example:

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