ODB compile uses `gcc` from PATH

[roe85]

We found an compatibility issue with the pre-build ODB on RHEL 8 and I also guess other OS versions: the the full path to gcc binary is not baked in the odb binary during compile-time.
This leads to problems if there is a different (e.g. newer) gcc in the PATH. This can easily happen when you are using a gcc-toolset-XX. A workaround is to invoke odb with PATH=/usr/bin/:$PATH odb.

I guess the solution would be to bake in the the fullpath to gcc and not rely on runtime PATH resolution.

[boris-kolpackov]

A workaround is to invoke odb with PATH=/usr/bin/:$PATH odb.

Or with odb -x /usr/bin/g++ ... .

I guess the solution would be to bake in the the fullpath to gcc [...].

This would only be a partial solution since this won't help an upgrade of GCC in place (as commonly happens in more "fluid" distributions, such as Debian and Fedora). And GCC is notorious for not caring about API stability where plugins are concerned, so we essentially need a build of the ODB plugin for each major GCC release.

GCC itself offers a related mechanism: we can install the plugin shared object into the GCC's plugin directory (as returned with gcc -print-file-name=plugin), pass just the plugin name with -fplugin (e.g., -fplugin=odb) and GCC will automatically append the version-specific directory. While it won't solve your specific problem, it will give a reasonable informative diagnostics, for example:

g++ -fplugin=odb test.cxx
cc1plus: fatal error: inaccessible plugin file /usr/lib/gcc/x86_64-linux-gnu/14/plugin/odb.so expanded from short plugin name odb: No such file or directory

It will also open the door for multiple plugin builds sharing the same odb driver (e.g., installed in /usr/bin), which will in turn allow doing things like:

$ odb -x g++-15 ...
$ odb -x g++-16 ...