Bug #911515 is invalid. The user that filed has a misunderstanding of the way in which the configure process is operating. The configure script is attempting to determine whether certain functions exist in the libraries or not, the implicitness is irrelevant. The problem is that including these files screws up further parts of the configure script leading to it not finding the functions that really are there. I'm not sure if the final result is the same on everyone's machines, but for me it ends up yelling about not finding gnat1 because it can't properly setup the search path because it thinks realpath doesn't exist because it runs into a realpath double definition because stdlib.h was erroneously included. Please don't try to fix things that aren't broken. There's no point in chasing implicit declarations in configuration unless they lead to implicit declarations in the actual build. Reproducible: Always Steps to Reproduce: 1. Build gnat-gpl 2. Run "gcc-10 -print-search-dirs" (gcc-10 is the version that gnat-gpl-2021 targets) Actual Results: install: /usr/bin/../../../lib/gcc/x86_64-pc-linux-gnu/10/ programs: =/usr/bin/../../../libexec/gcc/x86_64-pc-linux-gnu/10/:/usr/bin/../../../libexec/gcc/:/usr/bin/../../../lib/gcc/x86_64-pc-linux-gnu/10/../../../../x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu/10/:/usr/bin/../../../lib/gcc/x86_64-pc-linux-gnu/10/../../../../x86_64-pc-linux-gnu/bin/ libraries: =/usr/bin/../../../lib/gcc/x86_64-pc-linux-gnu/10/:/usr/bin/../../../lib/gcc/:/usr/bin/../../../lib/gcc/x86_64-pc-linux-gnu/10/../../../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/10/:/usr/bin/../../../lib/gcc/x86_64-pc-linux-gnu/10/../../../../x86_64-pc-linux-gnu/lib/../lib64/:/usr/lib/x86_64-linux-gnu/x86_64-pc-linux-gnu/10/:/usr/lib/x86_64-linux-gnu/../lib64/:/usr/bin/../../../lib/gcc/x86_64-pc-linux-gnu/10/../../../x86_64-pc-linux-gnu/10/:/usr/bin/../../../lib/gcc/x86_64-pc-linux-gnu/10/../../../../lib64/:/lib/x86_64-pc-linux-gnu/10/:/lib/../lib64/:/usr/lib/x86_64-pc-linux-gnu/10/:/usr/lib/../lib64/:/usr/bin/../../../lib/gcc/x86_64-pc-linux-gnu/10/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/x86_64-linux-gnu/:/usr/bin/../../../lib/gcc/x86_64-pc-linux-gnu/10/../../../:/lib/:/usr/lib/ Expected Results: install: /usr/lib/gcc/x86_64-pc-linux-gnu/10/ programs: =/usr/libexec/gcc/x86_64-pc-linux-gnu/10/:/usr/libexec/gcc/x86_64-pc-linux-gnu/10/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/10/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/10/../../../../x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu/10/:/usr/lib/gcc/x86_64-pc-linux-gnu/10/../../../../x86_64-pc-linux-gnu/bin/ libraries: =/usr/lib/gcc/x86_64-pc-linux-gnu/10/:/usr/lib/gcc/x86_64-pc-linux-gnu/10/../../../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/10/:/usr/lib/gcc/x86_64-pc-linux-gnu/10/../../../../x86_64-pc-linux-gnu/lib/../lib64/:/usr/lib/x86_64-linux-gnu/x86_64-pc-linux-gnu/10/:/usr/lib/x86_64-linux-gnu/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/10/../../../x86_64-pc-linux-gnu/10/:/usr/lib/gcc/x86_64-pc-linux-gnu/10/../../../../lib64/:/lib/x86_64-pc-linux-gnu/10/:/lib/../lib64/:/usr/lib/x86_64-pc-linux-gnu/10/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/10/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/10/../../../:/lib/:/usr/lib/ Additionally, you can try compiling the following file (as hello.adb): with Ada.Text_IO; use Ada.Text_IO; procedure Hello is begin Put_Line ("Hello WORLD!"); end Hello; # gnatmake-10 hello.adb gnatbind-10 -x hello.ali gnatlink-10 hello.ali gcc-10: fatal error: cannot execute ‘gnat1’: execvp: No such file or directory compilation terminated. gnatmake-10: *** link failed. On a proper install (i.e. built last Friday) this works, now it doesn't.
> Please don't try to fix things that aren't broken. There's no point in chasing implicit declarations in configuration unless they lead to implicit declarations in the actual build. No, that's not right either. We have seen many cases where the stricter compiler changes mean that configure concludes a wrong property of the system but may still build. That doesn't mean the change in question is right, but your assertion here is wrong.
Ok, now that I've read up that it's Clang 16 and not just some weird tick about trying to reduce warnings for the heck of it I apologize. I misunderstood the situation. That said, it would be greatly appreciated if after making such a change the person making it would check the logs. I wasted several hours banging my head into the wall on this one because I didn't realize the build scripts had changed and didn't know where to look. Once I figured out that it was a configuration file it took me all of about a minute to figure out something was screwy between the two config logs by simply looking at them in a diff. (Then it took me a while longer to understand why two builds from the same rev number would have two different config scripts). As the people making such changes know exactly what changes they're making they should check the associate config logs to make sure that their changes only have "positive" affects. In this case it's pretty obvious that for instance the check for "canonicalize_file_name" has gone horribly wrong. Finally, I'm not sure where the best place to propose a feature request would be (and I know it would take a while to build consensus), but I'd like to say it would be really nice to have a "build" part of the ebuild version. Similar to the rev number except that emerge would treat it as being an equivalent version (e.g. not rebuild on upgrade). Most of my time was spent trying to figure out what was different between the docker and kaniko build environments because I had no clue that I was building a different package. As an example, in this case the original ebuild would have been dev-lang/gnat-gpl-2021-r4 and the modified ebuild would have been dev-lang/gnat-gpl-2021-r4-b1. Things like emerge -v or /var/db/pkg would show the -b1, but for anyone with -r1 installed an emerge -u would not trigger an upgrade. Again, sorry for my overreaction, I didn't realize Clang 16 was getting strict. P.S. If you think it's worth doing, I can look into a proper fix for this that will remove the implicit function declarations. Not sure if it's worth doing as this is basically gcc and therefore unlikely to be built with clang.
(In reply to Alex Orange from comment #2) > P.S. If you think it's worth doing, I can look into a proper fix for this > that will remove the implicit function declarations. Not sure if it's worth > doing as this is basically gcc and therefore unlikely to be built with clang. I will appreciate it. However while I'm building it again trying to reproduce, can you please post the build log
(In reply to Alex Orange from comment #2) > Ok, now that I've read up that it's Clang 16 and not just some weird tick > about trying to reduce warnings for the heck of it I apologize. I > misunderstood the situation. > It happens and I've done it before. > That said, it would be greatly appreciated if after making such a change the > person making it would check the logs. I wasted several hours banging my > head into the wall on this one because I didn't realize the build scripts > had changed and didn't know where to look. Yeah, in particular with GCC's build system, one has to be especially careful because not all headers are always available at all points, especially for cross. It's important here to definitely check config.log before/after, although I'd encourage it whenever fixing any of these bugs. > [...] > > Finally, I'm not sure where the best place to propose a feature request > would be (and I know it would take a while to build consensus), but I'd like > to say it would be really nice to have a "build" part of the ebuild version. Yeah, this is an interesting idea. Prefix used to have "interrevisions" which had a different purpose/behaviour to what you describe but it's similar. It'd be worth filing a new bug for this. It's possible Portage could do this for you rather than us representing it in the ebuild filename / real version. > > Again, sorry for my overreaction, I didn't realize Clang 16 was getting > strict. > It's actually worse/better than that, GCC 14 is doing it too (https://wiki.gentoo.org/wiki/Modern_C_porting). Great in the long-run, painful right now.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=23efe86242c8871d0a614640da3c784d7eceb655 commit 23efe86242c8871d0a614640da3c784d7eceb655 Author: Alfredo Tupone <tupone@gentoo.org> AuthorDate: 2024-03-05 10:18:23 +0000 Commit: Alfredo Tupone <tupone@gentoo.org> CommitDate: 2024-03-05 10:19:11 +0000 dev-lang/gnat-gpl: fix configure Closes: https://bugs.gentoo.org/926177 Signed-off-by: Alfredo Tupone <tupone@gentoo.org> dev-lang/gnat-gpl/files/gnat-gpl-2021-gentoo.patch | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
(Needs a revbump as the installed product is broken.)
(In reply to Sam James from comment #6) > (Needs a revbump as the installed product is broken.) Revbump done. Thanks for suggestion
(In reply to Tupone Alfredo from comment #3) > (In reply to Alex Orange from comment #2) > > > P.S. If you think it's worth doing, I can look into a proper fix for this > > that will remove the implicit function declarations. Not sure if it's worth > > doing as this is basically gcc and therefore unlikely to be built with clang. > > I will appreciate it. > > However while I'm building it again trying to reproduce, can you please post > the build log Thanks for the suggestion, I actually meant to attach the two config.log files from libiberty ... but I forgot.
Created attachment 886759 [details] config.log from build/libiberty from the working version
Created attachment 886760 [details] config.log from build/libiberty from the working version
Created attachment 886761 [details] config.log from build/libiberty from the broken version
