FS#77924 - [python-pytorch-rocm] note: ‘std::string_view’ is only available from C++17 onwards

Attached to Project: Community Packages
Opened by Lubosz Sarnecki (lubosz) - Monday, 20 March 2023, 19:20 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:05 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Torsten Keßler (tpkessler)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
When building the flatbuffer submodule, it fails to finish the build since it wants C++17 features, but only C++14 is enabled during the build.

GCC errors:
```
/usr/include/absl/strings/string_view.h:52:26: error: ‘string_view’ in namespace ‘std’ does not name a type
52 | using string_view = std::string_view;
| ^~~~~~~~~~~
/usr/include/absl/strings/string_view.h:52:21: note: ‘std::string_view’ is only available from C++17 onwards
52 | using string_view = std::string_view;
| ^~~
/usr/include/absl/strings/string_view.h:686:8: error: ‘string_view’ does not name a type
686 | inline string_view ClippedSubstr(string_view s, size_t pos,
| ^~~~~~~~~~~
/usr/include/absl/strings/string_view.h:697:11: error: ‘string_view’ does not name a type
697 | constexpr string_view NullSafeStringView(const char* p) {
```

`-std=gnu++14` is passed to the `/usr/bin/g++-11` command, which prevents the submodule to build.

Additional info:
* package version(s) 1.13.1-2 / git hash 5689e7f44f082ba3c37724c2890e93e7106002a1

The reason for this regression is that the PKGBUILD does not specify git hashes on the submodules and flatbuffer master branch regressed.
A fix would be appending `#commit=<hash>` to known working commits to the urls in the `source` list.


Steps to reproduce:
Run makepkg.
This task depends upon

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:05 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/p ackaging/packages/python-pytorch/issues/ 2
Comment by loqs (loqs) - Tuesday, 21 March 2023, 14:34 GMT
Are you able to reproduce the issue in a clean chroot [1]? As python-pytorch-rocm-1.13.1-2-x86_64.pkg.tar.zst's .BUILDINFO does not contain abseil-cpp meaning the package was built without abseil-cpp installed.

On git submodules see [2] for how they are pinned.
Edit:
Side note it does fail for me in a clean chroot but that is due to the onednn package being updated to incompatible version [3] since the package was built.

[1] https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot
[2] https://wiki.archlinux.org/title/VCS_package_guidelines#Git_submodules
[3] https://github.com/pytorch/pytorch/issues/91968
Comment by Torsten Keßler (tpkessler) - Monday, 27 March 2023, 11:05 GMT
With version 2.0.0 python-pytorch-rocm is now part of the python-pytorch split package that is currently in [community-testing]. Any particular reason you wanted to build the package from source?

Loading...