Package: libabsl-dev
Version: 20240722.0-4
Severity: normal

Could libabsl be built with ABSL_USES_STD_STRING_VIEW, ABSL_OPTION_USE_STD_OPTIONAL, ABSL_OPTION_USE_STD_VARIANT and
similar settings?

// ABSL_OPTION_USE_STD_STRING_VIEW
//
// This option controls whether absl::string_view is implemented as an alias to // std::string_view, or as an independent implementation.

The standard library supports std::string_view now (for quite a
while indeed). Using a different string_view implementation adds
more friction converting to and from it.

FWIW, I don't use libabsl directly myself, just RE2. Before Trixie,
it had its own string_view-like type (StringPiece), now it switched
to absl::string_view. But instead of improving things as I hoped it
would, it's a regression. StringPiece would at least implicitly
convert from std::string_view (though not to it), absl::string_view
does neither.

-- System Information:
Debian Release: 13.0
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-35-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libabsl-dev depends on:
ii libabsl20240722 20240722.0-4

Versions of packages libabsl-dev recommends:
ii cmake 3.31.6-2
ii g++ 4:14.2.0-1
ii libgmock-dev 1.16.0-1
ii pkgconf 1.8.1-4

libabsl-dev suggests no packages.

-- debconf-show failed

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, July 6, 2025, at 12:50 AM +0200, Frank Heckenbach wrote:

Could libabsl be built with ABSL_USES_STD_STRING_VIEW, ABSL_OPTION_USE_STD_OPTIONAL, ABSL_OPTION_USE_STD_VARIANT and
similar settings?

Yes, but it’s not going to happen in trixie. :|

For background, ABSL_USES_STD_STRING_VIEW and friends have been in
Abseil for a while to support projects that are still using C++14 (or
earlier). Happily, Abseil upstream has officially dropped support for
C++14, and the latest release of Abseil no longer even has these
#defines. Unfortunately, trixie was frozen before that release, so
trixie will ship with absl::string_view != std::string_view. forky will
be the first release to have have absl::string_view == std::string_view everywhere.

I know this is probably not the answer you wanted to hear, and I’m sorry
that RE2’s switch to absl::string_view is creating work for you. I think
the simplest solution right now would be to switch to building Abseil
and RE2 as part of your project rather than using the ones packaged in
trixie; that would let you get the seamless C++17 experience rather than
the static_cast-prone old one. (You should rebuild both Abseil and RE2 –
a from-source Abseil will generally have a different ABI than Abseil in
trixie, so trying to link the trixie RE2 against a from-source Abseil is
likely to result in complex and subtle bugs.)

Benjamin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, July 6, 2025, at 12:50 AM +0200, Frank Heckenbach wrote:

Could libabsl be built with ABSL_USES_STD_STRING_VIEW, ABSL_OPTION_USE_STD_OPTIONAL, ABSL_OPTION_USE_STD_VARIANT and
similar settings?

Yes, but it's not going to happen in trixie. :|

For background, ABSL_USES_STD_STRING_VIEW and friends have been in
Abseil for a while to support projects that are still using C++14 (or earlier). Happily, Abseil upstream has officially dropped support for
C++14, and the latest release of Abseil no longer even has these
#defines. Unfortunately, trixie was frozen before that release, so
trixie will ship with absl::string_view != std::string_view. forky will
be the first release to have have absl::string_view == std::string_view everywhere.

I know this is probably not the answer you wanted to hear, and I'm sorry
that RE2's switch to absl::string_view is creating work for you. I think
the simplest solution right now would be to switch to building Abseil
and RE2 as part of your project rather than using the ones packaged in trixie; that would let you get the seamless C++17 experience rather than
the static_cast-prone old one. (You should rebuild both Abseil and RE2 -
a from-source Abseil will generally have a different ABI than Abseil in trixie, so trying to link the trixie RE2 against a from-source Abseil is likely to result in complex and subtle bugs.)

Thanks for your detailed explanation and the perspective for future
releases.

At the moment, I'm actually facing a bigger problem which makes it
almost impossible to build my software with Abseil: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1108845

The actual culprit here is pkgconf, no doubt, but seeing as my bug
report hasn't even gotten a response so far, I'm not sure it will be
fixed in trixie.

I have to say, though, that Abseil does use very many .pc files:

% ls -la /usr/lib/x86_64-linux-gnu/pkgconfig/*.pc | wc -l
590
% ls -la /usr/lib/x86_64-linux-gnu/pkgconfig/absl*.pc | wc -l
227

So almost half of all .pc files in my system come from a single
library! I do wonder if this fine-grained splitting is really
necessary -- shouldn't -Wl,--as-needed already take care of only
linking what's needed?

I guess in the end I'll have to rebuild RE2 and/or Abseil as you
say. For now, to get my software to compile at all so I can actually
start testing things, I just merged all the .pc files. This seems to
work for me, though of course, it would break with Abseil updates.

Since the current situation is untenable regarding compile times,
you could please do anything about it for trixie (or coordinate with
the pkgconf maintainers)?

Regards,
Frank

#!/bin/bash

set -e
export LC_ALL=C
umask 22

# Merge all absl Libs into absl_all.pc; make each single one depend only on that.
cd "/usr/lib/$(gcc -print-multiarch)/pkgconfig"
mkdir absl-orig
mv absl_* absl-orig
libs="$(sed -n '/^Libs:/{s///;s/[[:space:]]\+/\n/g;p;}' absl-orig/* |
sed '/pop-state/s/^/zzz &/' |
sort -u |
sed 's/^zzz //' |
tr '\n' ' ')"
sed "/^Name/s/:.*/: absl_all/;/^Description/s/base/merged/;/^Requires/d;/^Libs:/s|:.*|:$libs|" absl-orig/absl_base.pc > absl_all.pc
for f in absl-orig/*; do
sed '/^Libs:/d;/^Cflags:/d;/^Requires:/s/:.*/: absl_all/' "$f" > "${f#*/}" done

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, July 16, 2025, at 3:49 PM +0200, Frank Heckenbach wrote:

I do wonder if this fine-grained splitting is really necessary --
shouldn't -Wl,--as-needed already take care of only linking what's
needed?

There might be some parts of Abseil that use dynamic registration and
thus wouldn’t be picked up by -Wl,--as-needed, but I honestly don't
remember. This is probably better answered by Abseil upstream--do you
want to file a bug at https://github.com/abseil/abseil-cpp/issues?

Since the current situation is untenable regarding compile times,
you could please do anything about it for trixie (or coordinate with
the pkgconf maintainers)?

I think trixie is too frozen at this point to do anything about it
before the release. However, https://github.com/pkgconf/pkgconf/issues/229 suggests the pkgconf slowness has been resolved in v2.1.1, which could certainly be backported into trixie after the release occurs.

Additionally, I do want to point out that adopting CMake would work
around the pkgconf issues. CMake is a tad complex for my taste, but
Abseil (like most Google products) does include CMake library
descriptors, and those files are included in the Debian package. To be
clear, I'm not telling you to "just go use CMake" - it's important to
get the pkgconf issues resolved - but as an intermediate solution, it
might be worth investigating.

I'm going to leave this bug open until Debian gets a C++17-only Abseil,
but if it's all right with you, let's move further discussion of the
pkgconf issues to https://bugs.debian.org/1108845.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Benjamin Barenblat wrote:

On Wednesday, July 16, 2025, at 3:49 PM +0200, Frank Heckenbach wrote:

I do wonder if this fine-grained splitting is really necessary --
shouldn't -Wl,--as-needed already take care of only linking what's
needed?

There might be some parts of Abseil that use dynamic registration and
thus wouldn't be picked up by -Wl,--as-needed, but I honestly don't
remember.

This is probably better answered by Abseil upstream--do you
want to file a bug at https://github.com/abseil/abseil-cpp/issues?

There seens to be a similar bug already: https://github.com/abseil/abseil-cpp/issues/367

Which "abseil locked as too heated".
Translation: "We're Google, we don't care, you're just a bloody
nobody." -- There's nothing heated in the conversation in reality.

So it's obviously pointless to file another one.

Sure, that one is about the number of libraries, not .pc files.
But indeed, that's another issue I also notice. It's probably not
relevant in big programs, but here's my tests with a small batch
program using RE2:

bookworm:

% ldd myprog | wc -l
12
% time myprog
real 0m0,007s

trixie:

% ldd myprog | wc -l
47
% ldd myprog | grep -c absl
35
% time myprog
real 0m0,011s

So basically 50% slower start time just for linking RE2, thanks.

Since the current situation is untenable regarding compile times,
you could please do anything about it for trixie (or coordinate with
the pkgconf maintainers)?

I think trixie is too frozen at this point to do anything about it
before the release. However, https://github.com/pkgconf/pkgconf/issues/229 suggests the pkgconf slowness has been resolved in v2.1.1, which could certainly be backported into trixie after the release occurs.

Additionally, I do want to point out that adopting CMake would work
around the pkgconf issues. CMake is a tad complex for my taste, but
Abseil (like most Google products) does include CMake library
descriptors, and those files are included in the Debian package. To be
clear, I'm not telling you to "just go use CMake" - it's important to
get the pkgconf issues resolved - but as an intermediate solution, it
might be worth investigating.

Not for me, sorry. My Makefiles are heavily GNU make specific.

I'm going to leave this bug open until Debian gets a C++17-only Abseil,
but if it's all right with you, let's move further discussion of the
pkgconf issues to https://bugs.debian.org/1108845

Copied and Reply-To set.

Though I actually don't think there's much to discuss anymore.
You made it clear that nothing will change in trixie.
Google made it clear that nothing will change upstream.

So I'm left to my own devices, anyway. Whether I'll mess with the
.pc files, or rebuild RE2 and/or absl as you suggested, I'll wait
and see. (For now I've had enough of trixie already, also because of
other problems, and will defer any attempted upgrade for quite some
time.)

In any case, I've saved a copy of the bookworm RE2 sources.
Maybe it's easiest to just build them under trixie. (Just tried it,
seems to work without problems, and results in build time, start
time and number of libraries used just like in bookworm.)

Anyone else facing one or more of these problems in trixie might
want to do the same.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)