gprconfig doesn't always find compilers

[paherbst]

https://github.com/AdaCore/gprbuild/blob/24e823ee75ae8d867bcccc10163adb3830a3722a/share/gprconfig/compilers.xml#L180

In share/gprconfig/compilers.xml the "gcc_version" variable should be populated by "gcc -dumpversion"

[t-14]

Thank you for your suggestion, this looks indeed much better than trying to parse "gcc -v". We will do it like that.

[VF22Sturmvogel]

This may not be the best solution either.

On my Xubuntu install: `lrwxrwxrwx 1 root root 5 Sep 17 00:07 /usr/bin/gcc -> gcc-7 lrwxrwxrwx 1 root root 22 Jul 26 2018 /usr/bin/gcc-7 -> x86_64-linux-gnu-gcc-7 lrwxrwxrwx 1 root root 22 Jul 27 2018 /usr/bin/gcc-8 -> x86_64-linux-gnu-gcc-8 lrwxrwxrwx 1 root root 8 Sep 17 00:07 /usr/bin/gcc-ar -> gcc-ar-7 lrwxrwxrwx 1 root root 25 Jul 26 2018 /usr/bin/gcc-ar-7 -> x86_64-linux-gnu-gcc-ar-7 lrwxrwxrwx 1 root root 25 Jul 27 2018 /usr/bin/gcc-ar-8 -> x86_64-linux-gnu-gcc-ar-8 lrwxrwxrwx 1 root root 8 Sep 17 00:07 /usr/bin/gcc-nm -> gcc-nm-7 lrwxrwxrwx 1 root root 25 Jul 26 2018 /usr/bin/gcc-nm-7 -> x86_64-linux-gnu-gcc-nm-7 lrwxrwxrwx 1 root root 25 Jul 27 2018 /usr/bin/gcc-nm-8 -> x86_64-linux-gnu-gcc-nm-8 lrwxrwxrwx 1 root root 12 Sep 17 00:07 /usr/bin/gcc-ranlib -> gcc-ranlib-7 lrwxrwxrwx 1 root root 29 Jul 26 2018 /usr/bin/gcc-ranlib-7 -> x86_64-linux-gnu-gcc-ranlib-7 lrwxrwxrwx 1 root root 29 Jul 27 2018 /usr/bin/gcc-ranlib-8 -> x86_64-linux-gnu-gcc-ranlib-8

and

lrwxrwxrwx 1 root root 6 Jul 27 2018 /usr/bin/gnat -> gnat-8 lrwxrwxrwx 1 root root 23 Jul 27 2018 /usr/bin/gnat-8 -> x86_64-linux-gnu-gnat-8 lrwxrwxrwx 1 root root 10 Jul 27 2018 /usr/bin/gnatbind -> gnatbind-8 lrwxrwxrwx 1 root root 27 Jul 27 2018 /usr/bin/gnatbind-8 -> x86_64-linux-gnu-gnatbind-8 lrwxrwxrwx 1 root root 10 Jul 27 2018 /usr/bin/gnatchop -> gnatchop-8 lrwxrwxrwx 1 root root 27 Jul 27 2018 /usr/bin/gnatchop-8 -> x86_64-linux-gnu-gnatchop-8 lrwxrwxrwx 1 root root 11 Jul 27 2018 /usr/bin/gnatclean -> gnatclean-8 lrwxrwxrwx 1 root root 28 Jul 27 2018 /usr/bin/gnatclean-8 -> x86_64-linux-gnu-gnatclean-8 -rwxr-xr-x 1 root root 354520 Sep 26 2017 /usr/bin/gnatcoll_db2ada -rwxr-xr-x 1 root root 8984456 Sep 1 2017 /usr/bin/gnatdoc lrwxrwxrwx 1 root root 10 Jul 27 2018 /usr/bin/gnatfind -> gnatfind-8 lrwxrwxrwx 1 root root 27 Jul 27 2018 /usr/bin/gnatfind-8 -> x86_64-linux-gnu-gnatfind-8 lrwxrwxrwx 1 root root 22 Jul 27 2018 /usr/bin/gnatgcc -> x86_64-linux-gnu-gcc-8 -rwxr-xr-x 1 root root 38452192 Sep 1 2017 /usr/bin/gnat-gps lrwxrwxrwx 1 root root 10 Jul 27 2018 /usr/bin/gnathtml -> gnathtml-8 lrwxrwxrwx 1 root root 27 Jul 27 2018 /usr/bin/gnathtml-8 -> x86_64-linux-gnu-gnathtml-8 -rwxr-xr-x 1 root root 235888 Sep 26 2017 /usr/bin/gnatinspect lrwxrwxrwx 1 root root 8 Jul 27 2018 /usr/bin/gnatkr -> gnatkr-8 lrwxrwxrwx 1 root root 25 Jul 27 2018 /usr/bin/gnatkr-8 -> x86_64-linux-gnu-gnatkr-8 lrwxrwxrwx 1 root root 10 Jul 27 2018 /usr/bin/gnatlink -> gnatlink-8 lrwxrwxrwx 1 root root 27 Jul 27 2018 /usr/bin/gnatlink-8 -> x86_64-linux-gnu-gnatlink-8 lrwxrwxrwx 1 root root 8 Jul 27 2018 /usr/bin/gnatls -> gnatls-8 lrwxrwxrwx 1 root root 25 Jul 27 2018 /usr/bin/gnatls-8 -> x86_64-linux-gnu-gnatls-8 lrwxrwxrwx 1 root root 10 Jul 27 2018 /usr/bin/gnatmake -> gnatmake-8 lrwxrwxrwx 1 root root 27 Jul 27 2018 /usr/bin/gnatmake-8 -> x86_64-linux-gnu-gnatmake-8 lrwxrwxrwx 1 root root 10 Jul 27 2018 /usr/bin/gnatname -> gnatname-8 lrwxrwxrwx 1 root root 27 Jul 27 2018 /usr/bin/gnatname-8 -> x86_64-linux-gnu-gnatname-8 lrwxrwxrwx 1 root root 10 Jul 27 2018 /usr/bin/gnatprep -> gnatprep-8 lrwxrwxrwx 1 root root 27 Jul 27 2018 /usr/bin/gnatprep-8 -> x86_64-linux-gnu-gnatprep-8 -rwxr-xr-x 1 root root 137392 Sep 1 2017 /usr/bin/gnatspark lrwxrwxrwx 1 root root 10 Jul 27 2018 /usr/bin/gnatxref -> gnatxref-8 lrwxrwxrwx 1 root root 27 Jul 27 2018 /usr/bin/gnatxref-8 -> x86_64-linux-gnu-gnatxref-8`

Maybe "gnatgcc -dumpversion" is a little better than "gcc -dumpversion"?

[t-14]

Maybe "gnatgcc -dumpversion" is a little better than "gcc -dumpversion"?

We can't make an assumption gnatgcc exists. Besides, the above naming convention looks problematic for other, more serious, things than computing the version. For instance, I'd expect Compiler'Driver setting to be wrong.

If that's the typical naming convention on Xubuntu, this needs to be recognized on the level of the knowledge base. As it's orthogonal to the original issue, I recommend that you open a separate one, or better yet, a pull request that adds proper Xubuntu support ;)

[danieagle]

Hi! I using Xubuntu 19.10 gprconfig don't discover gnat anymore. Some one known how fix it? Really Thanks! :-)

ps.: don't work in Xubuntu 10.04, too... :-)

[t-14]

@danieagle, as discussed above, it looks like Xubuntu's way of packaging gnat isn't currently supported by the knowledge base.

[danieagle]

Are there a howto or similar about how alter this knowledge base or hints or etc?

I remember from years ago mingw32 changed it and contributed it. If i successfull in this change, I'll happilly contritute it to gprbuild.

Thanks in Advance, Dani.

Em dom, 28 de abr de 2019 13:31, Vasiliy Fofanov notifications@github.com escreveu:

@danieagle https://github.com/danieagle, as discussed above, it looks like Xubuntu's way of packaging gnat isn't currently supported by the knowledge base.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/AdaCore/gprbuild/issues/54#issuecomment-487394377, or mute the thread https://github.com/notifications/unsubscribe-auth/ADC32VDGQFDUZPSFLZ3ADITPSXGN3ANCNFSM4GTKUUMA .

[t-14]

No howto, unfortunately, this is a tricky case-by-case area. The way to search for GNAT compiler is defined in compilers.xml, and then the configuration is provided (mostly) in gnat.xml. If you run gprconfig with -v switch, it will tell what exactly it's looking for (and presumably not finding); once it manages to find the toolchain and generate configuration project, the latter then needs to be inspected for any anomalies (wrong compiler driver, missing chunks e.g. for linker, etc...)

[danieagle]

Thanks.

Em dom, 28 de abr de 2019 18:19, Vasiliy Fofanov notifications@github.com escreveu:

No howto, unfortunately, this is a tricky case-by-case area. The way to search for GNAT compiler is defined in compilers.xml, and then the configuration is provided (mostly) in gnat.xml. If you run gprconfig with -v switch, it will tell what exactly it's looking for (and presumably not finding); once it manages to find the toolchain and generate configuration project, the latter then needs to be expected for any anomalies (wrong compiler driver, missing chunks e.g. for linker, etc...)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/AdaCore/gprbuild/issues/54#issuecomment-487416384, or mute the thread https://github.com/notifications/unsubscribe-auth/ADC32VG4AP2R4VBFGKEDFCDPSYIGTANCNFSM4GTKUUMA .

[danieagle]

Hi!

I need confirm if is correct "GNAT is candidate" "filename: gnatls" well, this don't need be "filename: gnat" ? in annex the output of gprconfig -v

output_v.txt

Thanks in Advance!

[t-14]

Yes, "GNAT is candidate: filename=gnatls" is correct. However, the output has an incorrect structure. Looks like things are going badly wrong with the lookup. There is supposed to be a message "Done search directories" corresponding to "runtimes: search directories matching ...", followed by confirmation that the toolchain has been stored or rejected, and then the indentation will be reset. Instead, we see lookup for more configs proceeding at a wrong indentation which suggests that the directory lookup has exited at a wrong place without hitting completion and cleanup code.

I am afraid not much more can be gleaned from this output.

[danieagle]

Thanks

Em qua, 8 de mai de 2019 05:58, Vasiliy Fofanov notifications@github.com escreveu:

Yes, "GNAT is candidate: filename=gnatls" is correct. However, the output has an incorrect structure. Looks like things are going badly wrong with the lookup. There is supposed to be a message "Done search directories" corresponding to "runtimes: search directories matching ...", followed by confirmation that the toolchain has been stored or rejected, and then the indentation will be reset. Instead, we see lookup for more configs proceeding at a wrong indentation which suggests that the directory lookup has exited at a wrong place without hitting completion and cleanup code.

I am afraid not much more can be gleaned from this output.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/AdaCore/gprbuild/issues/54#issuecomment-490407405, or mute the thread https://github.com/notifications/unsubscribe-auth/ADC32VCU4T6MJPYUHJ72G2LPUKI35ANCNFSM4GTKUUMA .

[t-14]

Upon further investigation, we rely on additional information contained in gcc -v output to differentiate between compilers packaged by us and by other parties, so we cannot replace it with gcc -dumpversion output. We are closing this issue.