boost-build: configuration of toolset gcc does not enforce requested versions and accepts non-existing commands

[mhassert@…]

When one configures toolset gcc with a non-existing command it is accepted and an error is not reported until compilation starts.

When one configures toolset gcc with a version but no command (e.g. from the command line), boost build silently uses default command g++ without any version checking.

Examples:

a)

• in ~/user-config.jam insert "using gcc : 4.1 : gcc-4.1-FORCE-ERROR ;"
• run bjam --toolset=gcc-4.1 --debug-configuration -d+2

result: configuration of gcc-4.1 notices the not-found command but contuinues and later all compilations fail due to a "command not found"

b)

• add "using gcc : 9.9 ;" to ~/user-config.jam and run "bjam"

OR

• run bjam --toolset=gcc-9.9 --debug-configuration -d+2

result: auto configuration silently uses command "g++" but the version "9.9" is nontheless used in build paths tricking the user into thinking the requested compiler version was actually used. This is especially dangerous as any typo in the version on the command line does result in using the default compiler instead of a previously configured one.

What should happen:

• If only a version is given, boost build should try to deduce the correct command:

"g++-VERSION" and "g++" with matching version should be considered in that order.

• boost build should inform the user if the requested compiler command/version is not available and stop with an error.

I have attached a patch that changes tools/gcc.jam into what I think it should look like.

Note: Several mails on the mailing list suggest that a similar problem exists with toolset msvc and probably other toolsets, too. For example using toolset=msvc-8 instead of toolset=msvc-8.0 seems to use some default version instead of using 8.0 or failing. As msvc configuration code seems quite different, I have not looked further into this.

[mhassert@…]

Patch for configuration of toolset gcc

[mhassert@…]

Second version of patch. Fixed tool search on windows.

[mhassert@…]

My first patch failed to find tools on windows. I attached a fixed version tools_gcc.jam_v2.patch.

[Vladimir Prus]

(In [65633]) Add verification on gcc version and command.

Most importantly, if version is specified and command is not, check for g++-$version and failing that, check if g++ -dumpversion returns the version we've asked about.

Patch from Moritz Hassert. Addresses #4667.

[Vladimir Prus]

(In [65640]) Relax the check between user-specified version and the one from 'g++'.

Fixes #4667.

[Vladimir Prus]

Moritz,

thank you for the patch. I've checked in your patch. While playing with it I've noticed that the comparison between user-provided version and gcc output is pretty strict. If you specify '4.4', then the comparison fails because "g++ -dumpversion" reports 4.4.5. Since gcc developers don't even include the minor version in the binary name, this seems too strict check so I've checked in a follow-up patch to relax it.

Thanks again, Volodya

[mhassert@…]

Hi Volodya,

thanks for accepting the patch and fixing the version comparison. It was indeed too strict.

Now that I looked at the code again, I see another problem:

At the moment, specifying a command without a path and without ".exe" suffix does not work on Windows, because check-tool-aux() in common.jam auto-appends ".exe" only when the given command features a path. Omitting only one of path or .exe should to work. (I can't test right now.)

This behavior of check-tool-aux() seems kind of strange to me.

Passing the user specified command as the second argument in line 73 would work in case of omitted path but won't work for commands with a path. At least as far as I understand the rule find-tool().

Moritz

[Vladimir Prus]

Moritz,

I agree that logic is somewhat strange. We should first compose a list of suffixes to try, and then use on both branches. The reason we have two branches, I think, is to avoid doing GLOB when a directory is explicitly specified. I am not sure whether ther performance hit of GLOB is worth this trouble.

Are you interested in fixing this, or shall I try next time I get to windows?

[mhassert@…]

Volodya,

I'm afraid I'm not sure exactly how to fix it. A few thoughts / questions:

• Why does find-tool use "path.glob" while check-tool-aux uses "GLOB"? Is there a difference?
• What's the check-tool wrapper for?
• Should check-tool-aux convert the path with path.native like find-tool does?
• The rules find-tool() and check-tool-aux() should be merged somehow because it seems find-tool does basically the same as the else part of check-tool-aux. And if we allow .bat and .cmd in check-tool-aux it should be allowed in find-tool, too.