[Pkg-oss4-maintainers] Help (voodoo, really) needed [Re: failed i386 build of iceweasel 11.0~b1-2]

[Mike Hommey]

On Fri, Feb 17, 2012 at 07:28:49PM +0000, Ben Hutchings wrote:
> On Fri, Feb 17, 2012 at 07:41:03PM +0100, Mike Hommey wrote:
> > On Fri, Feb 17, 2012 at 06:08:59PM +0000, Ben Hutchings wrote:
> > > On Fri, Feb 17, 2012 at 07:00:32PM +0100, Mike Hommey wrote:
> > > > On Fri, Feb 17, 2012 at 06:40:28PM +0100, Samuel Thibault wrote:
> > > > > Mike Hommey, le Fri 17 Feb 2012 18:36:56 +0100, a écrit :
> > > > > > On Fri, Feb 17, 2012 at 06:23:00PM +0100, Samuel Thibault wrote:
> > > > > > > Mike Hommey, le Fri 17 Feb 2012 18:09:37 +0100, a écrit :
> > > > > > > > > sydney_audio_alsa.c:504:5: error: void value not ignored as it ought to be
> > > > > > > > 
> > > > > > > > Would anyone have a clue as to what the hell is happening?
> > > > > > > 
> > > > > > > Unpacking liboss4-salsa-dev (from .../liboss4-salsa-dev_4.2-build2005-2_armel.deb) ...
> > > > > > > Selecting previously unselected package libtinfo-dev.
> > > > > > > 
> > > > > > > I don't know why the buildds preferred liboss4-salsa-dev over
> > > > > > > libasound2-dev.
> > > > > > > 
> > > > > > > In my previous packaging of oss4's alsa-over-OSS emulation, I had only
> > > > > > > enabled the -dev in the non-linux archs.  In the current packaging, it's
> > > > > > > enabled in all of them.  I've now restricted it in oss4 too. Oss4
> > > > > > > packagers, any opinion against it?
> > > > > > 
> > > > > > Oh, so OSS4 provides an Alsa API that is not compatible with Alsa's.
> > > > > 
> > > > > It *is* compatible.  With an older version of the API, which used void
> > > > > there.
> > > > 
> > > > So, it's compatible with an API that is older than Alsa v1.0.10rc1,
> > > > released 7 years ago. What is surprising, however, is that Alsa didn't
> > > > change its soname for the resulting ABI change...
> > > 
> > > It's a compatible change; at least I don't know of a C architecture
> > > ABI where replacing a void return type with int would be incompatible.
> > 
> > The problem comes when you run something that uses the int variant and
> > expects a sound result, against the version that returns a void, which
> > in practice probably means returning the first argument on a lot of
> > architectures, if the register is not overwritten in the function body.
> > That's not exactly what i'd call compatibility.
> 
> Well neither is the absence of new functions in old libraries.  But
> that's why we have shlibs and symbol files.  Of course, if the minimum
> version for that symbol has not been set to the version changing the
> return type then that is a bug.

We have shlibs and symbols file to work around the problem in Debian. On
absolute terms, the change is still binary incompatible, and should be
handled properly, with symbol versions or soname change. Neither of
which was done in libasound, for that matter.

Mike