Bug#1108841: libabsl-dev: build with ABSL_USES_STD_STRING_VIEW
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 real0m0,007s trixie: % ldd myprog | wc -l 47 % ldd myprog | grep -c absl 35 % time myprog real0m0,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.
Bug#1108841: libabsl-dev: build with ABSL_USES_STD_STRING_VIEW
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.
Bug#1108841: libabsl-dev: build with ABSL_USES_STD_STRING_VIEW
> 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
Bug#1108841: libabsl-dev: build with ABSL_USES_STD_STRING_VIEW
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
Bug#1108841: libabsl-dev: build with ABSL_USES_STD_STRING_VIEW
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
