Alsa-lib 1.0 library's api is binary compatible w/ the older versions- the compilation however has a new api that is the default defined when included, unless you define 2 symbols prior to include alsa/asoundlib.h to use the old api. Using the old api doesn't break anything, so that's not an issue. The default being the new api however breaks all apps that use the old api w/out those definitions... Reproducible: Always Steps to Reproduce: 1. emerge >=media-libs/alsa-libs-1.0 2. emerge kde-base/arts Actual Results: Compilation failed due to the new api. Expected Results: Source should define the necessary definitions to get the old api, and compile successfully... This basically breaks all previous apps compilation against alsa-lib. Kind of bad. Easy to fix though.
Created attachment 21911 [details] alsa-lib eclass that contains a general find/sed fix This class is two functions- alsa-lib_fix_includes()- this can be passed multiple directories- performs a recursive find for sourcefiles/headers that have <alsa/asoundlib.h> to patch, using sed to fix the includes. alsa-lib_src_unpack() - exported function, calls base_src_unpack and calls alsa-lib_fix_includes
Created attachment 21912 [details] quick scan through ${PORTDIR} for packages/versions that likely are nailed by this. Not guranteed to be accurate- some of the newer sources may already be doing the define.
imo we should patch rather than make an eclass
I agree, patches are better, and I fully expect this to be obsoleted by newer versions of the packages that are afflicted at some point. The thing is, users are already running into this breakage. And that's a crapload of patches to create on short notice (granted they are one liners, but multiple-versions) I went the eclass route since it's the quickest way to fix the problem till either we have all the patches needed for each version we wish to fix, or upstream maintainers release a new version w/ the fix (thus forcing all users to that possibly untested version).
qa'ish issue, so cc'ing spider on this one as well.
*** Bug 35522 has been marked as a duplicate of this bug. ***
This lib should not be unmasked until xawdecode-1.8.2 is unmasked- 1.8.2 includes a configure fix for the >=alsa-lib-0.9.x This fix can probably be back ported, or just wait until it's unmasked.
Hokay... I've gone through all ebuilds that have media-libs/alsa-lib as a dependency, as of 10/23/04. Patches have been submitted, so the bulk of this issue should *hopefully* be handled. I'd expect a few to pop up here and there since I was checking stable packages only, but hopefully most of it is handled.
Side note, the fix should be like this- #include <alsa/version.h> #if SND_LIB_MAJOR==1 # define ALSA_PCM_OLD_HW_PARAMS_API #endif #include <alsa/asoundlib.h> Note the lack of ALSA_PCM_NEW_HW_PARAMS_API; torbenh caught that (thanks again).
Brian, how many of these packages have the fix in stable? I'd like to push for getting alsa-1 stable sometime around mid March to mid April.
When I originally went through and patched all of this, if the package was stable at all for x86, I patched the max stable version. Otherwise, I patched the max unstable version. To be honest, I'm not really how much of it is in stable or not, since I was patching quite a few packages. I can go hunting through and check up on it though.
i know you're busy, but if you could try to get these fixes into stable over the next month or so, that'd be great...
Ohk- since I don't feel like being bitten by the 'we unmasked a new version, and it died against alsa-lib' I'm going to extend the patches through each version. For the most part, we can use the same patch (thank you patch fuzznyess). I'll start on it next week, appending which packages have been completely checked out to this bug.
