| Michael Gogins wrote:
> OK, thanks for the information, you've obviously learned more about this
> stuff than I have. Which is great, and it helps me try to catch up. I
> _think_ I now understand the difference between:
>
> -- The SONAME, which encodes the version number of the interface.
>
> -- The "real name", which is the name of the actual shared library name,
> and which encodes the version number of the release.
>
> -- The "linker name", which is what dlopen or the OS loader use to open
> the library, and which is created for ldconfig.
Not really. You are correct on SONAME (although I'd add that it's the
*binary* interface or ABI, not source interface or API) and real name, but
the linker name is used at link-time (link-time as in compile-time, not
runtime linking). Thus a typical shared library would usually ship 1 file
under /usr/lib, plus 2 symlinks to it:
libname.so.X.Y[.Z] -> the real name
libname.so.X -> the soname (a symlink to the real lib)
libname.so -> the linker name (a symlink to any of the two above)
Usually, you dlopen a *file*, not a library (although the file must be a
library, of course). This means there is no linker magic going on here
(such as finding the library matching the SONAME). So the only thing you
are interested is the real name of the library you will dlopen. On the
other hand, these libraries are usually plugins so most of the time their
ABI is determined by the program dlopen'ing it, thus eliminating the need
of a versioned SONAME[1].
It may be important to note that currently csound has SONAME == real name:
in the above example, X (the SOVERSION) is 5.1, and there are no Y or Z.
This means there isn't a symlink actually, it is just one file. There may
be reasons for why this is not good, see [2]
>
> The interface version should be the same for both the Csound shared
> library and the Lua interface shared library, and just as I said before,
> there is no real reason that they cannot both be the same file. However,
> if the SONAMEs must differ, then the Lua interface SONAME should be:
>
> liblua5.1-csnd.so.5.1
>
> The real filename should be:
>
> liblua5.1-csnd.so.5.1.6 or maybe liblua5.1.2-csnd.so.5.1.6
The first one. AFAICS, switching from 5.x to 5.(x+1) will break things,
while going from 5.x.y to 5.x.(y+1) will not.
>
> And the linker symlink should be:
>
> csnd.so
This is the dlopen symlink. It is not the same: the linker works at
compile-time, dlopen works at run-time.
>
> It is purely a coincidence that the Lua interface version and the Csound
> interface version are both 5.1!
Well, I've been having some thoughts on the SOVERSION scheme, and I'm not
really convinced by it: SConstruct says
# library version is CS_VERSION.CS_APIVERSION
Does APIVERSION guarantee binary compatibility? The API can stay the same,
but the ABI can change[2]. On the other hand, the API can change, while the
ABI is maintained (adding functions, for example, doesn't break the ABI).
I'd suggest the following versioning scheme: ABIVERSION.APIVERSION, where
ABIVERSION=5.1 (the current, since compatibility has not been broken), and
APIVERSION=1 (since this is the current API version). Next time the ABI is
broken, a switch to a commonly used versioning system[3] may be a good idea
(and doesn't require much work, either).
[1] As far as I have understood, at least.
[2] The programming library how-to might be a useful read:
http://tldp.org/HOWTO/Program-Library-HOWTO/
[3] Libtool is usually used to create shared libraries, so it's versioning
scheme is very common
http://www.nondot.org/sabre/Mirrored/libtool-2.1a/libtool_6.html
--
Felipe Sateler
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net |