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

[Boris Kolpackov]

Hi Hugo,

Hugo.Mildenberger at web.de <Hugo.Mildenberger at web.de> writes:

> 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

Good catch! It is the same story on Fedora (but not on Debian, where
libexec is not used).

I don't see any harm in checking if either $libdir or $libexecdir is
a prefix of `gcc --print-file-name=plugin` in the 2.b test.

 
> > 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? 

Yes, I suppose we can add the include/ sub-directory of this directory
to the search paths automatically.


> 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.

For example, someone may want to install multiple versions of ODB
into some non-default location (e.g., /opt/odb-2.1 and /opt/odb-2.2)
In this case, installing the plugin into the GCC's directory will
override the previous installation.

Generally, I don't think it is correct to install the plugin into
the GCC's directory unless both GCC and ODB are installed into the
same prefix or the user explicitly instructed us to do so. Think
about installing ODB into /usr/local and installing plugin into
/usr/lib/... -- does not feel right.

Boris