On Fri, Dec 6, 2013 at 8:04 PM, Ben Pfaff <b...@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.sc...@googlemail.com> wrote: >> >> > On Wed, Nov 27, 2013 at 10:35 AM, Helmut Schaa >> > <helmut.sc...@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 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
