[ovs-dev] [PATCH] Build: shared libraries and versioning

Ben Pfaff blp at nicira.com
Wed Oct 22 23:49:01 UTC 2014


[adding back ovs-dev]

On Wed, Oct 22, 2014 at 04:38:48PM -0600, Scott Mann wrote:
> On Wed, Oct 22, 2014 at 3:35 PM, Ben Pfaff <blp at nicira.com> wrote:
> 
> > On Tue, Oct 21, 2014 at 04:02:53PM -0600, Scott Mann wrote:
> > > These changes cause shared libraries to be built by default. In
> > > particular, lib/libopenvwitch.so, lib/libsflow.so,
> > > ofproto/libofproto.so, and ovsdb/libovsdb.so will be built. Original
> > > behavior of building static objects excusively may be accomplished by
> > > providing the --disable-shared argument to configure.
> > >
> > > Additionally, versioning is introduced to each of the libraries objects
> > > paving the way for APIs to be built around them. A detailed comment
> > > outlining the rules for changing a version number is provided in
> > > configure.ac. Note that at this time, the version number is set to
> > > 1.0.0, no API is specified yet, and there are no requirements to maintain
> > > any sort of compatibility in any of the libraries.
> > >
> > > Signed-off-by: Scott Mann <smann at noironetworks.com>
> >
> > Thanks for the patch.  I have a few comments.
> >
> > I would rather default to not building shared libraries.  Can you
> > explain why it is better to build shared libraries by default?
> 
> Good question. It seemed a natural progression to me for what I
> am doing, but perhaps not everyone else. I'll reverse the behavior.

The reason that it bothers me is that, if I recall correctly, turning
on building shared libraries actually causes every source file to be
built twice, roughly doubling compile time.  That's not a big deal
when building for a distribution, etc., but it slows the dev cycle,
which is a big deal for me.  I guess I could always provide the right
"configure" flag to disable shared libraries, and maybe I should; I
don't know what is considered "best practice".

> > >  /* Creates and initializes a global instance of a module named MODULE.
> > */
> > >  #define VLOG_DEFINE_MODULE(MODULE)
> > \
> > > -        VLOG_DEFINE_MODULE__(MODULE)
> > \
> > > -        OVS_CONSTRUCTOR(init_##MODULE) {
> > \
> > > -                list_insert(&vlog_modules, &VLM_##MODULE.list);
> >  \
> > > +    VLOG_DEFINE_MODULE__(MODULE)
> > \
> > > +    OVS_CONSTRUCTOR(init_##MODULE) {
> > \
> >
> > I think that there deserves to be a comment here to explain why a
> > module with the given name might already exist.  (Actually, I'm not
> > even sure why myself.)  If it's a problem with possibly inserting the
> > same module twice, then it would probably be better to check whether
> > the module's 'list' pointers are null.  On the other hand, if the
> > problem is two different modules with the same name, then we have a
> > bigger problem: it will become impossible to change the log levels,
> > etc., of the module that does not get inserted.
> 
> It is a problem with inserting the same module twice, but I did not
> think of checking the module's list pointer - I'll make that
> change. As for the cause, the constructor is called each time the
> shared object is loaded, which appears to occur more than once when
> running the test suite, although I have not investigated why. If
> that is surprising, I could look into it. Of course, the static
> objects are "loaded" once, so the constructor is only called before
> main().  Is this a reasonable explanation? Or does it warrant
> further investigation?

I'm a little nervous about this, because sometimes this kind of thing
means that somehow one is linking against a single library in two
different ways.  That tends to show up worst on non-ELF platforms.
For example, with the Mach-O shared library format used on Mac OS X,
when you link against a single object in two different ways (for
example, one from a shared library, one directly), you get two copies
of the object in memory and they interact badly.  ELF normally does
better than this, so that you would get only a single copy, but there
are all kinds of failure modes in this area that make me suspicious.

Here's a couple of examples of the kind of thing that causes a crash
on Mac OS X, from a different project that I also contribute to:
http://git.savannah.gnu.org/cgit/pspp.git/commit/?id=d32245378988468e419654b9fe06fef066adfda1
http://git.savannah.gnu.org/cgit/pspp.git/commit/?id=4afd608d61b469b07f6c149e87ba25fabef9909e

I seem to recall that there was a related bug a while back when we
added the existing shared library support.  I spent some time looking
through the mailing list and the Git history, though, and I couldn't
find it.



More information about the dev mailing list