I am quite aware that dlopen happens at run time, linking at compile time. 
When I said "linker name" I was thinking of both. Also aware that 
"interface" in this context is binary interface.

What I didn't is how this scheme of versioned names works with the Lua 
interface. However, I ran into this at:

http://memebeam.org/john/debian/lua5.1/examples/binary_module/README:

Library naming
--------------
Given a Lua module "foo_bar", the base name for the library files should
be "liblua-foo_bar".  The "lib" prefix is a requirement of libtool, and
allows you to use the -l option of the linker as in "-llua-foo_bar".  The
"lua-" part, besides letting us know that the library is related to Lua,
by way of the dash charcter affects the module open function which require
will try to use when it dynamically loads the module.  Since everything
before the dash is ignored, the open function will simply be
"luaopen_foo_bar".  An added benefit of the "lua-" prefix is that it
discourages use of "Lua" in the module name itself.  Note that in order
for require to locate the library files, "liblua-?.so" patterns have been
added to the default CPATH.

So, SONAME should be

liblua5.1-csnd.so.5.1

But, perhaps I'm still missing something, but when installed, there would 
still need to be a symlink:

liblua5.1-csnd.so

in order for Lua's "require" loader to dlopen the interface.

Perhaps the confusion arises because Csound's Lua interface shared library 
is both (a) a plugin to be dlopened by Lua, and (b) linked with the Lua 
library itself.

Regards,
Mike


----- Original Message ----- 
From: "Felipe Sateler" 

To: 
Sent: Wednesday, August 22, 2007 1:21 AM
Subject: Re: [Cs-dev] format not recognized


> 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
> https://lists.sourceforge.net/lists/listinfo/csound-devel 


-------------------------------------------------------------------------
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