[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