[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,

  Boris Kolpackov <boris at codesynthesis.com> wrote:

  >h> I gather that the installer has to set "--with-gcc-plugin-dir" in order
  >h> make use of this feature.
  > 
  > No, if GCC and ODB prefixes match (which will most definitely be the case
  > in your situation), then ODB will install the plugin into the GCC directory
  > automatically. If you specify --with-gcc-plugin-dir, then you force ODB
  > to install the plugin into the GCC directory regardless of the prefix.

It actually did not work that way. Without setting "--with-gcc-plugin-dir", the odb.so plugin was not installed in $(gcc --print-file-name=plugin) but somewhere below "/usr/libexec/odb" (if I remember the directory correctly). I've not yet looked further into the details, why that fails, because I assumed it to be intended behaviour. Can you point me where to look specifically?   
 

  >h> Yet, in order to make this change fully functional, I also need to tie
  >h> the ODB installer to a Gentoo slot (a major ODB version, for all practical
  >h> means), because else Portage removes the "old" version while installing
  >h> the recompiled package. However, when emulating slots manually, I can
  >h> now switch back and forth between compilers.
  > 
  > I am not sure I 100% understand what you mean by this but I think I
  > disagree. You don't need slots for the ODB compiler itself. You just
  > need to install a separate ODB plugin for each supported version of
  > GCC and single /usr/bin/odb will load the right one depending on the
  > version of GCC that is currently in effect.

  Well, the problem is that Portage holds a list of all files installed by any installed package. Before a package gets reinstalled, all files contained in this list are removed (except for directories and files modified by other packages). A package not defining a slot will get assigned to slot 0 by default, so any newly installed version will replace the previously installed one. This is why I think a separate package for the plugin would be a good idea.

  > >   b> On a related note, this got me thinking that if one wants to support
  > >   b> multiple versions of GCC, then the ODB compiler will probably have
  > >   b> to be split into two packages: the ODB compiler driver (/usr/bin/odb
  > >   b> plus documentation) and ODB plugin (odb.so, one for each GCC version).
  > > 
  >h> This is what I naively assumed to be given in the first place, that the 
  >h> GCC plugin actually was independent from the compiler driver.
  > 
  > It is. More precisely, the ODB compiler driver does not depend on the GCC
  > version. So you can have multiple plugins (one for each version of GCC
  > installed) and a single driver (/usr/bin/odb) and it will all work
  > automatically. I.e., you can do:
  > 
  > odb -x g++-4.5 ... # Load plugin for GCC 4.5
  > odb -x g++-4.6 ... # Load plugin for GCC 4.6
  > odb -x g++-4.7 ... # Load plugin for GCC 4.7
  > 

Good news. 

  >h> Yet I still think that if you want to have different ODB (plugin/compiler)
  >h> versions installed in parallel, you actually need to encode at least the
  >h> plugin version into the plugin file name.
  > 
  > Yes, if one day we decide we want to support this, we can do that. 

I understood that the need to support several ODB versions in parallel was your main concern within the context of this thread. It was not my objective then, but I was able to see the potential benefit of being able to switch both between the ODB-versions and the GCC-version.

  > Though it sounds to me like the same approach that you will use to save/restore 
  > /usr/bin/odb can also be used to save/restore odb.so.

Alas, Portage will not do that on her own. I had to write an ODB module for the "eselect" utility, which would be tasked with stashing away files and changing symbolic links. Once implemented, it would be possible to switch between ODB-versions too, to wit:

$ eselect odb list
  2.2 *                      odb-2.2.1
  2.3			     odb-2.3.5_pre1  
  2.4                        odb-2.4.1

$ eselect odb set 2.4


I'm a bit unsure which ODB related packages exactly would need to be managed. Can you, e.g., sensibly use any database back-end library with a more recent compiler driver? 


Hugo