-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
libiberty #1
Comments
It's also not possible to regenerate Autotools stuff in the |
For the record, the |
There's some modern C issues with this rather old copy of libiberty too (like -Wimplicit-function-declaration warnings which become fatal in stricter compilers). Any chance this could be removed, or possibly swapped with gnulib if some bits from it are needed? |
My idea is to gradually replace libiberty usage by standard C++ features. (But I'm not working on that, right now.) |
Re the 'const_cast', note that some 'pex_run' usage in GCC does similarly, and see <https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html>: The 'argv[]' and 'envp[]' arrays of pointers and the strings to which those arrays point shall not be modified by a call to one of the 'exec' functions, [...] ..., and "The statement about 'argv[]' and 'envp[]' being constants [...]" in the Rationale section describing the underlying issue.
... in its GCC commit 03b2a04d63c7a320ef86ee4a077bbdcefd02a271 (Subversion r170076) revision. This gets us rid of the (non-fatal) error mentioned in <#1 (comment)>: @@ -84,7 +84,6 @@ checking for unistd.h... yes checking whether byte ordering is bigendian... no checking for a BSD-compatible install... /usr/bin/install -c -/bin/sh: ./../move-if-change: No such file or directory checking for sys/file.h... yes checking for sys/param.h... yes checking for limits.h... yes ..., and changes '[build]/libiberty/Makefile' as follows: @@ -108,6 +108,8 @@ check: check-subdir installcheck: installcheck-subdir +# Warning: this fragment is automatically generated +enable_shared = no INCDIR=$(srcdir)/$(MULTISRCTOP)../include ... by means of '[build]/libiberty/temp-frag' now being 'move-if-change'd to '[build]/libiberty/xhost-mkfrag'. Co-authored-by: Thomas Schwinge <[email protected]>
GCC commit a4ebe104540e7b6d3c637d793dbcd5171b4b8209 (Subversion r209988). Co-authored-by: Thomas Schwinge <[email protected]>
GCC commit ac631cbe7021105c7fb8438deaeef66fe544b9aa (Subversion r238880). Co-authored-by: Thomas Schwinge <[email protected]>
GCC commit 7e2de6df10b532be4e66025e318f68a0ebf2c408 (Subversion r265610). Co-authored-by: Thomas Schwinge <[email protected]>
GCC commit 22e052725189a472e4e86ebb6595278a49f4bcdd (Subversion r265695). Co-authored-by: Thomas Schwinge <[email protected]>
GCC commit d7f00da1c0ed414175305c41a07b3a50fa577cce. Co-authored-by: Thomas Schwinge <[email protected]>
GCC commit 5e431ae4ccc5fb0e077e598cb4efb1e12fc66c68. Co-authored-by: Thomas Schwinge <[email protected]>
GCC commit 3d9439b1bb76c186958d5b86f0076f8b3017b8a2. Co-authored-by: Thomas Schwinge <[email protected]>
GCC commit 86f64400a5692499856d41462461327b93f82b8d. Co-authored-by: Thomas Schwinge <[email protected]>
GCC commit 7ff793415f55fa9a92f348fecb8c75ac8acc8b87. Co-authored-by: Thomas Schwinge <[email protected]>
…GCC, 2018-10-29 [#1, #42]" ..., that is, nvptx-tools commit 98e081c, for GCC commit 7e2de6df10b532be4e66025e318f68a0ebf2c408 (Subversion r265610), which, with 'ptxas' missing, changed, for example: $ ./nvptx-none-as --verify -o o test/as/bare-1.s nvptx-as: error trying to exec 'ptxas': execvp: No such file or directory nvptx-as: ptxas returned 255 exit status ..., to: $ ./nvptx-none-as --verify -o o test/as/bare-1.s nvptx-as: execvp: No such file or directory Manually re-instantiate the lost piece of information.
GCC commit b8e9fd535d6093e3a24af858364d8517a767b0d7 (2024-04-26). Co-authored-by: Thomas Schwinge <[email protected]>
We're including a copy of libiberty.
There is an (apparently non-fatal) error during configuration:
To remove code duplication, and under the assumption that we can probably use "more standard" interfaces than libiberty's, maybe it's not actually hard to get rid of libiberty altogether? (It has not yet been assessed which libiberty interfaces we're actually using.)
The text was updated successfully, but these errors were encountered: