Hi Jaroslav,
At Thu, 19 Sep 2002 17:29:48 +0200 (CEST),
Jaroslav Kysela wrote:
Hi all,
your almost all negative messages persuaded me to wait awhile with
new function prototypes. Here is the result:
thanks for quick reaction.
the new library works fine with the old applications.
On Fri, 20 Sep 2002, Takashi Iwai wrote:
your almost all negative messages persuaded me to wait awhile with
new function prototypes. Here is the result:
thanks for quick reaction.
the new library works fine with the old applications.
Btw; with ld from binutils-2.9.5.0.22-6 (rh62) I
On Fri, 20 Sep 2002, Kai Vehmanen wrote:
On Fri, 20 Sep 2002, Takashi Iwai wrote:
your almost all negative messages persuaded me to wait awhile with
new function prototypes. Here is the result:
thanks for quick reaction.
the new library works fine with the old applications.
Jaroslav Kysela [EMAIL PROTECTED] writes:
your almost all negative messages persuaded me to wait awhile with
new function prototypes.
Thanks for listening, Jaroslav. :-)
I intended my comments to be negative only in the narrow sense
(let's don't do this), and not in the broader
On Wed, 18 Sep 2002, Chris Rankin wrote:
Does this mean that the alsa-lib needs to be updated in CVS to be -rc4?
I am trying to compile xine and wine from CVS as well as ALSA, and this
doesn't work because alsa-utils needs the new headers but xine and wine
currently need the old ones. I
On 17 Sep 2002, Jack O'Quin wrote:
Is this a Release-Critical bug fix?
If not, I think source- and binary-incompatible changes are highly
inappropriate right now. A release candidate is supposed to
*stabilize* the interface and implementation. Making an incompatible
change between rc3
At Tue, 17 Sep 2002 14:58:42 +0200 (CEST),
Jaroslav Kysela wrote:
Hi all,
I've made a simple cleanup which unifies all snd_pcm_hw_params_*
functions. The first set of changes are in CVS a few days, but some
developers pointed that the backwards compatibility is a right thing.
On Wednesday 18 September 2002 10:36, Takashi Iwai wrote:
using the versioned symbols is a good idea. it should go into
libasound.so.3 to avoid the further confliction.
I don't know about anyone else but I'm really confused.
All I know is that JACK CVS doesn't build out of the box with ALSA
At Wed, 18 Sep 2002 10:46:42 +0100,
Richard Bown wrote:
On Wednesday 18 September 2002 10:36, Takashi Iwai wrote:
using the versioned symbols is a good idea. it should go into
libasound.so.3 to avoid the further confliction.
I don't know about anyone else but I'm really confused.
--- Jaroslav Kysela [EMAIL PROTECTED] wrote: On Wed,
18 Sep 2002, Chris Rankin wrote:
Note: If
SND_COMPATIBILITY_BUILD_RC3 is defined,
then applications need to fall back to 0.9.0rc3 API
as well.
So maybe we could have a --with-compat-rc3 option for
alsa-utils as well? Regardless of which
On Wed, 18 Sep 2002, [iso-8859-1] Chris Rankin wrote:
--- Jaroslav Kysela [EMAIL PROTECTED] wrote: On Wed,
18 Sep 2002, Chris Rankin wrote:
Note: If
SND_COMPATIBILITY_BUILD_RC3 is defined,
then applications need to fall back to 0.9.0rc3 API
as well.
So maybe we could have a
On Wed, Sep 18, 2002 at 01:02:35PM +0100, Chris Rankin wrote:
So maybe we could have a --with-compat-rc3 option for
alsa-utils as well?
I don't think there has been any other changes. Just use rc3 alsa-utils.
And I doubt that wine and xine will get updated before
-rc4 is released.
(Unless
Jaroslav Kysela wrote:
autoconfiguration code to alsa.m4. My suggestion is to use /opt/alsa/rc3
directory for this job. Comments?
/opt is redhat only, debian systems do not have it.
tim
---
This SF.NET email is sponsored by: AMD - Your
1) build library with --with-compat-rc3 and place it to some
other directory
3) build library without --with-compat-rc3, place it to
/usr/lib as usuall
4) build alsa-utils and newer applications
5) build older applications with compatible library compiled
with --with-compat-rc3
Old and
Tim Goetze [EMAIL PROTECTED] writes:
autoconfiguration code to alsa.m4. My suggestion is to use
/opt/alsa/rc3 directory for this job. Comments?
/opt is redhat only, debian systems do not have it.
err, even if i dislike it, /opt is defined by the fhs
anyway, api incompatibles libraries
this is the /usr/share/aclocal/alsa.m4 job to provide right linking
flags depending of the library
ah. typical autoconf confusion here.
autoconf looks in only ONE directory by default for *.m4 files. if it
was installed from a package, it probably looks in
/usr/share/aclocal. if it was
On Tue, 17 Sep 2002, Jaroslav Kysela wrote:
After some thoughs, I think that this sort of cleanups is good for
implementing at any time. It doesn't break the implementation (in the
sense of behaviour), but it makes that older code is not compilable.
Fortunately, any C programmer can
Thierry Vignaud wrote:
Tim Goetze [EMAIL PROTECTED] writes:
autoconfiguration code to alsa.m4. My suggestion is to use
/opt/alsa/rc3 directory for this job. Comments?
/opt is redhat only, debian systems do not have it.
err, even if i dislike it, /opt is defined by the fhs
anyway, api
At Wed, 18 Sep 2002 14:21:44 +0200 (CEST),
Jaroslav Kysela wrote:
On Wed, 18 Sep 2002, [iso-8859-1] Chris Rankin wrote:
--- Jaroslav Kysela [EMAIL PROTECTED] wrote: On Wed,
18 Sep 2002, Chris Rankin wrote:
Note: If
SND_COMPATIBILITY_BUILD_RC3 is defined,
then applications
On Wednesday 18 September 2002 15:50, Tim Goetze wrote:
anyway, i agree with paul that pkg-config should be used instead,
which offers a lot more flexibility.
That's as maybe but it's non-standard still isn't it? Another dependency
in a complicated world. I think it's too soon.
However,
anyway, i agree with paul that pkg-config should be used instead,
which offers a lot more flexibility.
That's as maybe but it's non-standard still isn't it? Another dependency
in a complicated world. I think it's too soon.
its part of all distributions at this point. its about as standard
Tim Goetze wrote:
now that i think about it some more, i feel compelled to add:
this dance around the 0.9.0 version seems ridiculous to me. the
logical consequence of API changes is bumping the version number,
and not hiding it in a 'nano' version increment.
sorry for the harsh words,
On Wednesday 18 September 2002 16:18, Paul Davis wrote:
its part of all distributions at this point. its about as standard as
autoconf.
While it may be part of the distros it's not always installed as default.
My SuSE 8.0 DVD has it on but I still had to fish it out.
While we're at it - did I
Jaroslav,
I must respectfully point out that your response proves that there
*is* a problem. This solution is *compicated*. You're a smart guy.
You probably feel you understand all its implications. Perhaps you
do. But, most ALSA users and developers *do not* and *will not*.
I am sorry to
At Wed, 18 Sep 2002 09:49:55 -0400,
Paul Davis wrote:
at the very least, move to pkgconfig so that apps can find the alsa
libs easily.
i put alsa.pc in alsa-lib. please check whether it's ok.
one related question is -
is there any problem to keep alsa.m4 file? or should it be removed
and
On Wed, Sep 18, 2002 at 06:51:11PM +0200, Takashi Iwai wrote:
one related question is -
is there any problem to keep alsa.m4 file? or should it be removed
and force people to move to pkg-config from AC macros?
Removing alsa.m4 is probably the best way to speed up adoption of
pkg-config
Note: If
SND_COMPATIBILITY_BUILD_RC3 is defined,
then applications need to fall back to 0.9.0rc3 API
as well.
So maybe we could have a --with-compat-rc3 option for
alsa-utils as well? Regardless of which alsa-lib I
build, I always need to be able to build alsa-utils.
And I
--- Jaroslav Kysela [EMAIL PROTECTED] wrote: On Wed,
18 Sep 2002, [iso-8859-1] Chris Rankin
wrote:
It seems, that you're not understand the
compatibility.
That's possible - or maybe the existing
compatibility is woefully inadequate for the scale
of the problem?
The applications that I am
--- Chris Rankin [EMAIL PROTECTED] wrote: ---
Jaroslav Kysela [EMAIL PROTECTED] wrote: On
The possible solutions from my perspective are:
- I install BOTH libraries, each with full headers
(somehow)
Oh yes, and the compatibility version has to go in
/usr because that's where the rest of
On Tue, 17 Sep 2002, Jaroslav Kysela wrote:
1) New versioned library is libasound.so.3, so that older applications
uses older libasound.so.2.
Hmm, the 'Versions' ld script doesn't seem to be in CVS, and as a result,
linking alsa-lib currently fails. Have I missed something?
--
On Tue, 17 Sep 2002, Kai Vehmanen wrote:
On Tue, 17 Sep 2002, Jaroslav Kysela wrote:
1) New versioned library is libasound.so.3, so that older applications
uses older libasound.so.2.
Hmm, the 'Versions' ld script doesn't seem to be in CVS, and as a result,
linking alsa-lib
Does this mean that the alsa-lib needs to be updated in CVS to be -rc4?
I am trying to compile xine and wine from CVS as well as ALSA, and this
doesn't work because alsa-utils needs the new headers but xine and wine
currently need the old ones. I imagine that the xine and wine people can
Is this a Release-Critical bug fix?
If not, I think source- and binary-incompatible changes are highly
inappropriate right now. A release candidate is supposed to
*stabilize* the interface and implementation. Making an incompatible
change between rc3 and rc4 looks like a big step backwards.
33 matches
Mail list logo
