[CF-Devel] Re: libtool with plugins

[Kurt Fitzner]

On 31-Aug-2002 Mark Wedel wrote:
>
     
      Kurt Fitzner wrote:
     
     
>
     
        As for libcross.a - why should it care - that is a static library, that is
     
     >
     
      linked in statically.  Same is true for libsocket.a for that matter. There
     
     >
     
      is really no reason to make those shared libraries, because the versions are
     
     >
     
      tied very closely to crossfire, and it is not like there will be more than
     
     >
     
      one process running on the system that may use those shared objects and thus
     
     >
     
      have some benefit of reduced memory.
     
     
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.

It may be that relative jumps are large enough by default on the x86 that the
compiler doesn't happen to use any absolute jumps in Linux.  On my HP, though,
gcc is putting in absolute jumps in libcross.a and the linking of python_plugin
barfs since libcross.a has non position-independant code in it. My guess is
that at some point even on Linux, some function will grow to be longer than a
page and your plugin linking will suddenly break. Your object files in a static
library can be compiled with -fPIC with very little performance hit.  After
all, in Linux if the linker isn't complaining now, then it's already PI code,
and adding the flag won't make a difference.  You can keep track of different
object files with libtool, if you like.  Compile the code without -fPIC
for your static library, and then use libtool with -fPIC to make it into .lo
PIC object files for the plugins.  Some projects do it this way.

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.

I'd suggest moving to shared code as much as possible.  It will add nothing to
the size, and ease problems down the road.

Incidentally, the python config library for HP wasn't compiled with -fPIC
either, so I have to recompile it too.  I haven't got a clue why the distro
for HP doesn't have shared libraries.  Bah.

        Kurt.