Re: [ecasound] ecasound-2.4.6.1 tries to open wrong LADSPA plugins files and hangs

--- On Sat, 8/16/08, Kai Vehmanen <kvehmanen@email-addr-hidden> wrote:

[snip]
> I could change the code, but I don't know how. I really
> don't want to
> hardcode known plugin filename extension types to ecasound.
> Ecasound can
> be run on any POSIXish systems (not just Linux, OS X and
> Win32), so making
> this type of assumptions can cause nasty side-effects for
> some users.
>

Well, audacity somehow knows the extension, and it works under Linux,
Mac, Windows.

There can be a compromise - for the three above systems ecasound uses
filtering, i.e. it looks for DLLs with known extension, for other systems
it just tries to open.

Actually, according to

http://en.wikipedia.org/wiki/Library_(computer_science)#Dynamic_linking :

"
The term DLL is mostly used on Windows and OS/2 products. On Unix and Unix-like platforms, the term shared library or shared object is more commonly used; consequently, the most common filename extension for shared library files is .so, usually followed by another dot and a version number.
".

So, probably, if you do it specifically right for Windows and for MacOS,
and for other cases you'll just assume .so, you won't get
complaints:

http://en.wikipedia.org/wiki/Library_(computer_science)#Dynamic_linking :

"
    * GNU/Linux, Solaris and other System V Release 4 derivatives, and BSD variants

    libfoo.a and libfoo.so files are placed in directories like /lib, /usr/lib or /usr/local/lib. The filenames always start with lib, and end with .a (archive, static library) or .so (shared object, dynamically linked library), with an optional interface number. For example libfoo.so.2 is the second major interface revision of the dynamically linked library libfoo. Old Unix versions would use major and minor library revision numbers (libfoo.so.1.2) while contemporary Unixes will only use major revision numbers (libfoo.so.1). Dynamically loaded libraries are placed in /usr/libexec and similar directories. The .la files sometimes found in the library directories are libtool archives, not usable by the system as such.

    * Mac OS X and upwards

    The system inherits static library conventions from BSD, with the library being in a .a file, and can use .so-style dynamically-linked libraries (with the .dylib suffix instead). Most libraries in Mac OS X, however, are "frameworks", placed inside of special directories called "bundles", which wrap the library's required files and metadata. For example a library called "My Neat Library" would be implemented in a bundle called "My Neat Library.framework".

    * Microsoft Windows

    *.DLL files are dynamically linkable libraries. Other file name patterns may be used for specific purpose DLLs, e.g. *.OCX for OCX control libraries. The interface revisions are either encoded in the files, or abstracted away using COM-object interfaces. Depending on how they are compiled, *.LIB files can be either static libraries or representations of dynamically linkable libraries needed only during compilation, known as "Import Libraries". Unlike in the UNIX world, where different file extensions are used, when linking against .LIB file in Windows one must first know if it is a regular static library or an import library. In the latter case, a .DLL file must be present at runtime.
".

If you want to make it bullet-proof, allow user to override default
DLL extension from command line, so even if your guess WRT .so is not
correct, user will have a possibility to override your guess.

...

I think GNU autotools should somehow take care of this, otherwise how
does 'make install' know which DLLs to copy ? So probably you can use
info already present in autoconf macros - if I understand it correctly.

Thanks,
  Sergei.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Sat Aug 16 16:15:02 2008