Subject: Re: [ecasound] Still cannot get ecawave to work under Redhat 7.1
From: Kai Vehmanen (k@eca.cx)
Date: Fri Jul 13 2001 - 00:15:17 EEST
On Thu, 12 Jul 2001 fabrizio.gennari@philips.com 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 http://www.distrowatch.com/ 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.
-- http://www.eca.cx Audio software for Linux!-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Fri Jul 13 2001 - 00:18:55 EEST