[CF-Devel] Re: libtool with plugins

[Mark Wedel]

Kurt Fitzner wrote:
>
     
      On 31-Aug-2002 Mark Wedel wrote:
     
     
>
     
     
     >
     
      You may want to make it into a shared library for the benefit of the plugins. 
     
     >
     
      The issue is that plugins are using the same code in libcross.a.  Since they
     
     >
     
      -are- shared libraries, at the very least, the libcross.a component object
     
     >
     
      files will have to be built using -fPIC. You can put position-independant code
     
     >
     
      object files in a static library.  You just can't put non-position-independant
     
     >
     
      code in a shared.
     
     
  I'd have to look at the plugin code, but I'm not 100% positive that it 
confines it calls to only the stuff in libcross.

  Hypothetically, if it made a callback to a function that is located in in the 
server directory, what may happen down the road?

  My impression of the static libraries was that they were really just a 
convenient way to gather a bunch of .o files together, and linkin in a static 
library really isn't any different than if you had just passed all the .o files 
directly to the linker.


>
     
      However, that somewhat defeats the purpose of a plugin.  Plugins should be
     
     >
     
      able to be fairly independant of the main program.  If you do the above, then
     
     >
     
      every time you change code in common, you will have to recompile every plugin.
     
     >
     
      If you switch libcross.a to a shared object, this will most of the time be
     
     >
     
      avoided.  Unless, of course, there are interface changes in the common code. 
     
     >
     
      It also has the added benefit of being able to distribute plugins
     
     >
     
      independantly of the main program.  All you need are the libcross.a headers
     
     >
     
      somewhere, and you can compile plugins outside the main source.
     
     
  As of now, the plugins are _very_ dependent on the code.  The plugins access 
some areas of the object structure directly - if the object layout changes, the 
plugin must be recompiled.

  There was actually a bug here for a while in that the plugin wasn't getting 
the dependencies done, so something would change some area like the object, the 
plugin wasn't getting recompiled, and then doing bad things.

  I know the idea is/was originally that there could be multiple plugins, and 
shared objects was the most reasonable way to do that (as the dynamic loader 
could look and see what features the plugin is providing).

>
     
     
     >
     
      I'd suggest moving to shared code as much as possible.  It will add nothing to
     
     >
     
      the size, and ease problems down the road.
     
     
  I'll take a look at this.