Arch Linux User Repository

@Digitalghost, here is the patch adding +#include <cstdint>, can be applied with just git apply eternalterminal-aur-add-cstdint.patch in the package directory:

https://gist.github.com/xHasKx/5f24c1fe0558aae3838d5e8b4bb0ff12

Please submit a PR with the patch, thanks!

This still doesn't build, and the patch provided in the previous reply doesn't apply because the diff context of the patch is broken.

@Digitalghost The discussion in the upstream is still open, but it doesn't seem to be active enough. Is it possible to include the patch in the AUR repository for the time being? Here's a working patch and PKGBUILD.

The suggestion in the error fixes it, added the .patch locally and it built. So easy fix for @Digitalghost or the ET dev at least.

--- external_imported/sentry-native/external/crashpad/util/file/filesystem.h.orig       2025-05-03 09:26:14.327832930 -0700
+++ external_imported/sentry-native/external/crashpad/util/file/filesystem.h    2025-05-03 09:26:39.102503957 -0700
@@ -19,6 +19,7 @@

 #include "base/files/file_path.h"
 #include "util/file/file_io.h"
+#include <cstdint>

@gyscos, I went ahead and reported it upstream as well in issue #690.

I'm getting compilation error with gcc 15.1.1:

In file included from /home/gyscos/.cache/paru/clone/eternalterminal/src/EternalTerminal-et-v6.2.9/external_imported/sentry-native/external/crashpad/util/file/scoped_remove_file.cc:17:
/home/gyscos/.cache/paru/clone/eternalterminal/src/EternalTerminal-et-v6.2.9/external_imported/sentry-native/external/crashpad/util/file/filesystem.h:119:1: error: ‘uint64_t’ does not name a
 type
  119 | uint64_t GetFileSize(const base::FilePath& filepath);
      | ^~~~~~~~
/home/gyscos/.cache/paru/clone/eternalterminal/src/EternalTerminal-et-v6.2.9/external_imported/sentry-native/external/crashpad/util/file/filesystem.h:22:1: note: ‘uint64_t’ is defined in hea
der ‘<cstdint>’; this is probably fixable by adding ‘#include <cstdint>’
   21 | #include "util/file/file_io.h"
  +++ |+#include <cstdint>
   22 |
/home/gyscos/.cache/paru/clone/eternalterminal/src/EternalTerminal-et-v6.2.9/external_imported/sentry-native/external/crashpad/util/file/filesystem.h:128:1: error: ‘uint64_t’ does not name a
 type
  128 | uint64_t GetDirectorySize(const base::FilePath& dirPath);
      | ^~~~~~~~
/home/gyscos/.cache/paru/clone/eternalterminal/src/EternalTerminal-et-v6.2.9/external_imported/sentry-native/external/crashpad/util/file/filesystem.h:128:1: note: ‘uint64_t’ is defined in he
ader ‘<cstdint>’; this is probably fixable by adding ‘#include <cstdint>’
[ 35%] Building CXX object external_imported/sentry-native/crashpad_build/util/CMakeFiles/crashpad_util.dir/misc/lexing.cc.o
make[2]: *** [external_imported/sentry-native/crashpad_build/util/CMakeFiles/crashpad_util.dir/build.make:177: external_imported/sentry-native/crashpad_build/util/CMakeFiles/crashpad_util.di
r/file/scoped_remove_file.cc.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:1116: external_imported/sentry-native/crashpad_build/util/CMakeFiles/crashpad_util.dir/all] Error 2

I had the same experience as @partion. Removing eternalterminal and reinstalling fixed it for me.

Broken after latest update:

$ etserver
etserver: error while loading shared libraries: libabsl_log_internal_check_op.so.2308.0.0: cannot open shared object file: No such file or directory

Pulling from upstream and compiling manually worked fine.

6.2.8 fixes gcc-13 and incorporates the patches from 6.2.4.

Thanks everyone for your contributions and support!

@macdems thanks for that. I was having issues with linking binaries until now.

Here is a working PKGBUILD with all fixes:

https://gist.github.com/figue/8ecdf31ce7e0437efe36ad13c4aca9e5

I also resolved some other warnings, but it seems they are not important.