[Live-devel] shared library

Tue Dec 11 10:06:29 PST 2012

Am Samstag, den 08.12.2012, 19:31 -0800 schrieb Ross Finlayson:
> > > I'm not planning any changes to the 'build system' itself.  I
> > > would
> > > hope, however, that things like shared libraries could be
> > > accommodated
> > > by using a different "config.*" file - e.g., perhaps named
> > > something
> > > like "config.linux-with-shared-libraries" or
> > > "config.debian-with-shared-libraries" - and then using the exiting
> > > "genMakefiles" tool.  So that's the approach that I would pursue
> > > first.
> > 
> > Adding shared library support requires adding an additional make
> > target
> > that builds the additional .so files, because we want to keep the
> > static
> > library. This cannot be done by just adding some variables to
> > config.linux-with-shared-libraries.
> 
> 
> OK, fair enough.  So here's what I'll do.  If you send me a
> "config.linux-with-shared-libraries" file that uses the existing build
> system to build *just* shared libraries - even though that's not what
> you want - then I'll add it to the distribution.  But I'll also use it
> to see if I can upgrade the build system (e.g., upgrade the
> "genMakefiles" tool and/or the "Makefile.head"/"Makefile.tail" files)
> to support a new "config.linux-with-static-and-shared-libraries" file
> that will build both static and shared libraries.

Okay. Attached is my first try. It builds the libraries fine, but fails
then to build the testProgs. The name of the library needs to be
available for the link option (see patch for the Makefile.tail files).
The *_VERSION_* should be put to their corresponding libraries and
maintained as discussed below.

> > > (And as for the suggestion of switching to using 'CMake', see
> > > <http://lists.live555.com/pipermail/live-devel/2012-July/015600.html>)
> > 
> > Thanks for the pointer. Can you point me to the latest proposed
> > revision
> > of cmake config files?
> 
> 
> I don't think any such things exist, because - as far as I know -
> nobody is actually using CMake to build our code.  Anyway, as I noted
> in my July email message, CMake is a non-starter, unless/until it can
> work with FreeBSD and also Windows with MS Visual Studio v5.0.

I found a two year old cmake file [1]. Supporting FreeBSD with CMake
should be no big issue. CMake can generate project files for Visual
Studio 6 and later [2]. So there will probably no support for Visual
Studio 5.

[1] http://lists.live555.com/pipermail/live-devel/2010-June/012311.html
[2] http://www.cmake.org/cmake/help/v2.8.10/cmake.html#section_Generators

> > >  (The only 'dynamic link' that I hope you put in Debian
> > > distributions
> > > is a 'link' to the URL "http://www.live555.com/liveMedia/", so
> > > that
> > > people can download the latest version of the code; the only
> > > version
> > > that we support :-)
> > 
> > The homepage field of the liblivemedia package points to
> > http://www.live555.com. Should I change it to point to the URL
> > mentioned
> > above?
> 
> 
> Yes, please.

Done in our git repository:
http://anonscm.debian.org/gitweb/?p=pkg-multimedia/liblivemedia.git;a=commitdiff;h=7d6cb366

> > > But of course, you're welcome to try building shared libraries if
> > > you
> > > wish.
> > 
> > I cannot do it properly without your help. Are you willing to
> > maintain
> > one variable with the SONAME version.
> 
> 
> OK, I could do this.  What would this variable look like (i.e.,
> defined in a C/C++ source file)?  Or do you mean that the variable
> would be defined in the Makefiles (rather than as a symbol in the
> library)?

The SONAME version will be one variable (or three if you split it into
current, revision, and age) for each library in the Makefiles.

> > #  3. If the library source code has changed at all since the last
> > update, then
> > #     increment revision (`c:r:a' becomes `c:r+1:a').
> > #  4. If any interfaces have been added, removed, or changed since
> > the last update,
> > #     increment current, and set revision to 0.
> > #  5. If any interfaces have been added since the last public
> > release, then increment
> > #     age.
> > #  6. If any interfaces have been removed since the last public
> > release, then set age
> > #     to 0.
> 
> 
> These 'rules' seem very confusing, because the conditions that they
> describe can overlap.  Example.  If the current string is "c:r:a", and
> a new interface is added (but with no other changes), then does the
> new string become:
> - "c:r+1:a" (rule 3), or
> - "c+1:0:a" (rule 4), or
> - "c:r:a+1" (rule 5), or
> - "c+1:0:a+1" (rules 4 and 5) ???

They are meant to be processed step by step.

> It seems to me that the rules would be less confusing if, instead,
> they explained what happens in the following (non-overlapping!)
> situations:
> 1/ The code changes, but without any change to the API (i.e.,
> interfaces).

Just increment the revision: c:r+1:a

> 2/ At least one interface changes, or is removed (i.e., so that
> existing code that uses the library would likely be incompatible with
> the new version).

Increment current, reset others: c+1:0:0

> 3/ One or more interfaces were added, but no existing interfaces were
> changed or removed (i.e., so that existing code that uses the library
> might still remain compatible with the new version).

Increment current and age: c+1:0:a+1

This versioning schema is from libtool. I found a few more detailed
explanation blogposts/articles/documentation:

https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
https://blog.flameeyes.eu/2009/04/shared-object-version
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
http://www.freesoftwaremagazine.com/articles/building_shared_libraries_once_using_autotools

-- 
Benjamin Drung
Debian & Ubuntu Developer
-------------- next part --------------
libliveMedia_VERSION_CURRENT=0
libliveMedia_VERSION_REVISION=0
libliveMedia_VERSION_AGE=0

libBasicUsageEnvironment_VERSION_CURRENT=0
libBasicUsageEnvironment_VERSION_REVISION=0
libBasicUsageEnvironment_VERSION_AGE=0

libUsageEnvironment_VERSION_CURRENT=0
libUsageEnvironment_VERSION_REVISION=0
libUsageEnvironment_VERSION_AGE=0

libgroupsock_VERSION_CURRENT=0
libgroupsock_VERSION_REVISION=0
libgroupsock_VERSION_AGE=0

COMPILE_OPTS =		$(INCLUDES) -I. -O2 -DSOCKLEN_T=socklen_t -D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64 -fPIC
C =			c
C_COMPILER =		cc
C_FLAGS =		$(COMPILE_OPTS)
CPP =			cpp
CPLUSPLUS_COMPILER =	c++
CPLUSPLUS_FLAGS =	$(COMPILE_OPTS) -Wall -DBSD=1
OBJ =			o
LINK =			c++ -o
LINK_OPTS =		-L.
CONSOLE_LINK_OPTS =	$(LINK_OPTS)
LIBRARY_LINK =		gcc -o 
LIBRARY_LINK_OPTS =	-shared -Wl,-soname,$(NAME).so.$(shell expr $($(NAME)_VERSION_CURRENT) - $($(NAME)_VERSION_AGE))
LIB_SUFFIX =			so.$(shell expr $($(NAME)_VERSION_CURRENT) - $($(NAME)_VERSION_AGE)).$($(NAME)_VERSION_AGE).$($(NAME)_VERSION_REVISION)
LIBS_FOR_CONSOLE_APPLICATION =
LIBS_FOR_GUI_APPLICATION =
EXE =
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile-mods.patch
Type: text/x-patch
Size: 1471 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121211/4d7fb712/attachment.bin>