[ovs-dev] [PATCH] Use libtool for lib creation and allow building shared libs

[Helmut Schaa]

On Fri, Dec 6, 2013 at 8:04 PM, Ben Pfaff <blp at nicira.com> wrote:
> On Fri, Dec 06, 2013 at 08:24:03AM -0800, Jarno Rajahalme wrote:
>>
>> On Dec 6, 2013, at 1:59 AM, Helmut Schaa <helmut.schaa at googlemail.com> wrote:
>>
>> > On Wed, Nov 27, 2013 at 10:35 AM, Helmut Schaa
>> > <helmut.schaa at googlemail.com> wrote:
>> >> Currently openvswitch builds all libraries static only. However,
>> >> libopenvswitch is linked into nearly all openvswitch executables
>> >> making it hardly possible to run openvswitch on embedded devices
>> >> (for example running OpenWrt).
>> >>
>> >> Convert openvswitch to use libtool for building its internal libs.
>> >> This allows "--enable-shared" and "--enable-static" as configure
>> >> arguments. Default is "--disable-shared" thus keeping the current
>> >> behavior with the only change that static libs are installed by
>> >> "make install".
>> >
>> > Any comments on this patch?
>> >
>> FWIW I like this. There would need to be some thought on versioning
>> and binary compatibility of the libraries, though. This must not lead
>> to a situation where we need to start second guessing about
>> refactoring OVS code (removing functions, changing function
>> prototypes, changing data types, etc.) due to compatibility problems
>> with potential 3rd party programs that may be linked with the same
>> shared libraries. Also, when OVS is upgraded we should be able to run
>> two versions at the same time. If this is not done carefully, OVS
>> upgrades may start breaking running systems.
>
> There's that kind of issue, yes.  I think it's minimized if the default
> is to build and link statically only.  (I had not realized that option
> was available with libtool, although it makes sense that it is.)
>
> In the long term I think it's worthwhile to consider having OVS produce
> (and use internally?) shared libraries with a stable ABI.  I've had one
> request for such a library, and I think that others would find it useful
> too even if they have not asked me for it.  That's a much bigger job
> than this patch, of course, but something like this could be a stepping
> stone along the way.

Another option for reducing the binary size of OVS is to build everything
into a single multicall executable. However, that makes it harder to split
OVS into meaningful packages.

Helmut