[odb-users] odb-2.2.1 should install the odb.so plugin into $(gcc -print-file-name=plugin)

[Hugo.Mildenberger at web.de]

Hi Boris,

  > Anyway, here is the plan that I think will address all the issues:
  > 
  > 1. Add --{with,without}-gcc-plugin-dir option to ODB configure. This
  >    option can be used as follows:
  > 
  >    a) --with-gcc-plugin-dir: force installing into GCC's plugin dir
  >       with is obtainer by running $CXX -print-file-name=plugin
  > 
  >    b) --without-gcc-plugin-dir: force installing into $libexecdir/odb/
  >       even if test #2.b below succeeds.
  > 
  >    c) --with-gcc-plugin-dir=/path/to/gcc/plugin/dir: install plugin
  >       into the specified directory. This method will have to be used
  >       for cross-compilation.
  > 
  > 2. If we are not cross-compiling, then:
  > 
  >    b) If $libexecdir is a prefix of `$CXX -print-file-name=plugin`,
  >       then install into the gcc plugin dir. One can use 
  >       --without-gcc-plugin-dir to override this.

On my systems at least, condition 2.b) will likely never be met:

  $ gcc --print-file-name=plugin
  /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/plugin

  $ ls /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.2/plugin/
  gengtype

Note that "gengtype" plugin. That is kinda interesting, because gcc -fplugin=gengtype does  not find it, obviously because gcc searches only '/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/plugin'. I've also looked into what dragonegg does, however they too install into their own directory, so not much to learn from them.

  >    c) Use `$CXX -print-file-name=plugin`/include as the plugin include
  >       directory.

That would be in full accordance with the GCC documentation.
 
> 3. If we are cross-compiling then the user will have to specify the
>    plugin include directory via the CPPFLAGS configure variable.
  
Another way to express the same thing would be that the developer needs to specify the path to the plugin headers of exactly that GCC version he must have already built for 'host'. So why not use --with-gcc-plugin-dir within this context? Since ODB by itself is not a compiler, but a library to be used by gcc either on 'build' or 'host', there remain two scenarios:
 
1/ ODB programs need to be compilable on 'build' only, creating binaries on 'build' for use with 'host'. The plugin consequently installs into 'build':

.  GCC      compiles a plugin for GCC      using plugin headers from GCC
.     build                          build                              build
                      
2/ ODB programs need to be compilable on 'host' only, creating binaries on 'host' for use with 'host'. The plugin consequently installs into 'host':

.  GCC       compiles a plugin for GCC      using plugin headers from GCC         
.     build                           host                               host

 
> 4. If the plugin is installed into the GCC plugin dir, then the ODB
>    compiler driver will obtain the GCC's plugin dir at runtime,   
>    append the plugin name (odb.so) and pass this absolute path to
>    -fplugin. This way things will work consistently with GCC 4.5
>    (which doesn't support short plugin name) and later.

> Do you see any problems with this plan?

Except for installing the plugin below /usr/libexec, which I feel would not really be needed anymore. Is there a remaining use case? Without an installed gcc or with an installed gcc without plugin support, installing odb.so anywhere does not make much sense.
 

Hugo