Subject: Re: [ecasound] ecasound-2.1dev2 quirks
From: Kai Vehmanen (k_AT_eca.cx)
Date: Tue Oct 16 2001 - 20:37:36 EEST
On Tue, 16 Oct 2001, John S. Denker wrote:
> 1) When compiling ecasound-2.1dev2, compilation failed when trying to
> #include alsa/asoundlib.h
> Suggestion: Perhaps the ./configure script could check for this quirk and
> deal with it?????
Yup, this was changed very recently (ALSA 0.9beta8 I think). But as this
only affects beta and CVS versions of ALSA, I don't think adding
configure magic to ecasound is worth it. If you use the last stable
version of ALSA (0.5.x), ecasound will work without problems (picks
asoundlib.h from sys/asoundlib.h).
> 2) I managed to do a successful make. I did _not_ do a "make install";
> instead I tried running /usr/src/ecasound-2.1dev2/ecasound/ecasound
> directly. It almost worked. However, I got the following load-time error:
> lt-ecasound: error while loading shared libraries:
> /usr/src/ecasound-2.1dev2/libecasound/.libs/libecasound.so.8: undefined
> symbol: __14ATOMIC_INTEGERi
> Suggestion: It is really nice to be able to run ecasound versions without
> doing a "make install". (We are talking about a pre-alpha developmental
Welcome to the wonderful world of cross-platform dynamic linking. ;)
But, but, as a general rule you should always run "make install" (this
"finalizes" the shared libraries). But you don't need to overwrite your
old working configuration. Just do:
...this will install libraries to /usr/local/ecasound-dev/bin, libraries
to .../ecasound-dev/lib, and so on. Nothing goes outside the
prefix-directory. And when you want to get rid of the development stuff,
just delete the ../ecasound-dev directory, or possibly
Both will work. And the good thing is that the same procedure works not
just with ecasound, but with all linux/unix apps using the
autoconf/automake/libtool trio. And the prefix-dir doesn't have to be
under /usr/local - you can install apps under you /home directory if you
want. So compiling&installing apps from sources is not that painful
afterall, if you just know the few necessary tricks. ;)
> Wow, what an uniformative error message. A colleague of mine tracked this
> down. Here is his report:
> >The ATOMIC_INTEGER class is defined in the kvutils library,
> >and is referenced by the libecasound library.
> >ecasound is a shell script that creates .libs/lt-ecasound
> >at runtime if needed and runs it.
> >The shell script contains a very long link line whose
> >options I'm unfamiliar with, but deduce that they aren't
> >sufficient to tell lt-ecasound to search
> >/usr/src/ecasound-2.1dev2/kvutils/.libs upon subsequent
> >dynamic linking.
This is true. All the above stuff relates to the libtool system, which
takes care of the dynamic linking. It's complex because it's designed to
be cross-platform, and dynamic linking happens to be an area, where there
are lots of differences between different unix platforms. But as a
positive side, using libtool makes it possible to compile ecasound under a
wide variety of linux distros, and other unix variants (like freebsd and
-- http://www.eca.cx Audio software for Linux!
-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request_AT_wakkanet.fi>.
This archive was generated by hypermail 2b28 : Tue Oct 16 2001 - 20:34:34 EEST