Re: [ecasound] Porting ecasound to FreeBSD 4.2 (take 2)

New Message Reply Date view Thread view Subject view Author view Other groups

Subject: Re: [ecasound] Porting ecasound to FreeBSD 4.2 (take 2)
From: Kai Vehmanen (kaiv@wakkanet.fi)
Date: Wed Dec 20 2000 - 11:07:20 EET


On Mon, 18 Dec 2000, Anarcat wrote:

> Well, in fact, there *would* be something. I (as a new/dumb user) am
> disoriented by the usage message displayed when starting ecasound as
> just "ecasound". I think it should go interactive right there, with an
> help message.

Hmm, this doesn't sound bad at all. Does anyone have any good reasons
against this being the default behaviour?

> I could also be nice to have some kind of reference there on all the
> commands documented in the man pages. Even if it's just a small
> listing.

You mean online help in the interactive-mode? There's already ecasound(5)
and ecasound-iam(5) man pages available. I keep those always up-to-date,
so they are a good reference. But you can't access directly from
interactive mode.

> -b:1024 -sr:44100 -n:test -i:/dev/dsp
[...]
> ecasound ('h' for help)> -i:/dev/audio
> Segmentation fault (core dumped)

How about "aio-add-input /dev/audio"? Another good trick in testing is to
use "null" and "rtnull" instead of /dev/dsp and /dev/audio during testing.
This is a good way to determine whether the problem is specifically in the
soundcard handling (null and rtnull should work in all circumstances).

> I would have to recompile with debugging symbols, but only if you tell
> me it's worth it (and how to do it, d$/&*$mn libtool :).

Well, beforehand it's difficult to say whether it's worth it. :) Anyway,
it's easy to do, just "./configure --enable-debug ; make ; make install".
That's about it. You'll get a separate set of executables (ecasound_debug,
ecaplay_debug, etc) that you can use for debugging. I usually have both
optimized and debug versions compiled. If I have problems with the
optimized version, I can immediately try to reproduce the problem with
_debug version. Makes the test'n'debug procedure quite a bit faster.

> In the file libecasound/eca-object-map.cpp:23 , the #include <regex.h>
> directive is used without the necessary #include <sys/types.h>. (man
> regex(3): http://www.freebsd.org/cgi/man.cgi?regex).

Ok, regex(3) page on my machine doesn't mention anything about types.h,
but checking the header file itself makes this clear... "POSIX says that
<sys/types.h> must be included (by the caller) before <regex.h>.". Ok,
fixed.

> Problem 2 (linking, again):
[...]
> c++ -shared ecasoundc.lo -lecasound -L../kvutils/.libs -lkvutils -lhistory -lreadline -lc_r -lm -lc -Wl,-soname -Wl,libecasoundc.so.0 -o .libs/libecasoundc.so.0
> /usr/libexec/elf/ld: cannot find -lecasound]

This is a bug (not at all freebsd-specific). libecasoundc (C impl. of the
ECI API) has to be linked against libecasound (the main C++ library), but
the problem is that on a clean machine, no version of libecasound is yet
installed. Obviously all people who have tested the latest devel-versions
(including me), have had an older version of libecasound around, so the
bug hasn't been found before. This is now fixed. The correct compiler line
would be:

c++ -shared ecasoundc.lo -L../libecasound/.libs -lecasound -L../kvutils/.libs -lkvutils -lhistory -lreadline -lc_r -lm -lc -Wl,-soname -Wl,libecasoundc.so.0 -o .libs/libecasoundc.so.0

... so we use the -L to tell the linker where the compiled (but not yet
installed) libecasound is. The actual fix goes to libecasoundc/Makefile.am

-ecasound_libs = -lecasound_debug
+ecasound_libs = -L$(top_builddir)/libecasound/.libs -lecasound_debug

-ecasound_libs = -lecasound
+ecasound_libs = -L$(top_builddir)/libecasound/.libs -lecasound

-- 
 . http://www.eca.cx ... [ audio software for linux ] /\ . 
 . http://www.eca.cx/sculpscape [ my armchair-tunes mp3/ra/wav ]

-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.


New Message Reply Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Dec 20 2000 - 10:34:00 EET