Re: [ecasound] Still cannot get ecawave to work under Redhat 7.1

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

Subject: Re: [ecasound] Still cannot get ecawave to work under Redhat 7.1
From: Kai Vehmanen (
Date: Fri Jul 13 2001 - 00:15:17 EEST

On Thu, 12 Jul 2001 wrote:

> I tried the ecawave-0.4.0 RPM on a machine running Redhat 7.1 with no
> luck. The message "extension "RENDER" missing on display :0.0" appears
> I compiled again, but using the newer gcc-2.96. The result was better:
> It seems that the "dynamic_cast" called by
> QEOpenFileDialog::format_test fails. But why does it fail? And why
> such a different behaviour between compilers? Maybe it is libstdc++'s
> fault? I am using the one coming with Redhat 7.1.

Executive summary: :)

Make sure that you have both ecasound (libecasound) and ecawave compiled
with the new compiler (and libs). Just recompiling ecawave is not enough,
because ecawave uses libecasound to do all the real work.

The longer version:

Here's a brief summary of components ecasound and ecawave
rely on:

package rh6.x rh7.x
glibc 2.1.x 2.2.x
ncurses 4.x 5.x (?)
libstdc++ 2.9.x
qt 2.2.x 2.3.x
XFree86 3.3.x 4.x

XFree is needed because libqt-x11 relies on them. Compared to some
popular KDE and GNOME apps, this doesn't look so bad... but it's
quite a mess nevertheless.

First, here's just two specific distro releases. Just a quick look at
the comparison chart at shows that these
redhat distros are just the start.

Then we have the C++ compatibility issue. The C++ language itself is
standardized. Same goes for the standard library (libstdc++). But problems
arise when we realize that:

1) The C++ ABI (ie. the application binary interface, the
   actual compilation results) is not standardized. Binaries
   (libraries/programs) built with compilers (or different
   versions of the same compiler) that don't share a common
   ABI, _cannot_ be mixed. And as it happen, all the following
   have differnet ABIs:
        - egcs 1.1.2 (redhat 5.2 and various others)
        - gcc 2.95.2 (redhat 6.0 -- " --)
        - gcc 2.96 (redhat 7.x, and at least mandrake 7.0)
        - gcc 3.x (hopefully will stabilize the gcc C++ ABI)
   ... so C++ code compiled with these compiler cannot
   be mixed.

   The binary ecasoud RPM's available at ecasound's web site
   are compiled with gcc 2.95.2. If you have a system, which
   has libstdc++, libqt or some other ecasound component
   recompiled with another compiler (from the above list),
   the resulting application will not work.

2) Library binary compatibility. Any changes to binary
   compatibility in the above list of required libs
   will prevent precompiled ecasound RPMs from working.
   For instance binary built against ncurses 5.x won't
   work with ncurses 4.x, but the reverse should be ok.

3) Source level compatibility. Any source-level
   compatibility changes will make it impossible to
   recompile ecasound. For instance, it's not possible
   to compile current ecasound with the new 3.x
   (source level changes in libstdc++-devel ... and
   there might be more problems ahead).

4) Other differences between distros. This the problem
   space LSB (Linux standards base) tries to solve, ie.
   where to install packages, where to find pre-installed
   packages, what packages should be always available,
   what package manager to use (deb, rpm, etc), blah,
   blah, ...

... now in many cases the situation isn't this bad. The general rule is
people don't break interfaces (be it binary, source or other level of
compatibility) just for fun.

Additionally many Linux distributors provide compatibility packages for
running older binaries. As a side effect, it's has become very difficult
to list the exact systems with which your binaries are compatible. For
instance, you might be able to run current ecasound and ecawave binaries
on new Redhat and Mandrake systems if you install the correct
compat-libs.. but I just don't know whether it's possible or not, and if
yes, what packages need to be installed... so I have no choice but to
raise my hands and yell "I don't know!". ;)

... but yes, it's starting to look very tempting to stop supporting rpms
at all and leave this stuff to others. The best alternatives seem to be:

1) Use the source Luke! Distros are useful for installing a new
   system. You get a large, tested set of working software.
   However, for installing software not included in mainstream
   distros, compiling from source (straight CVS-access!) is really not
   that bad.

2) A working community that handles the contrib-tree (ie. software
   package outside the base system). I think Debian is the best
   example of this.

3) Select a distro that covers all software you are using.
   Unfortunately for many of us this is just too limited.

 Audio software for Linux!

-- To unsubscribe send message 'unsubscribe' in the body of the message to <>.

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

This archive was generated by hypermail 2b28 : Fri Jul 13 2001 - 00:18:55 EEST