/usr/lib/libopenal.so.0 missing from Intrepid

[Jonathan Harris]

Binary package hint: libopenal1
Version: 1:1.3.253-4ubuntu1

The libopenal1 binary package in Intrepid replaces the old libopenal0a binary package from Hardy, Gutsy etc. libopenal0a created /usr/lib/libopenal.so.0, but the new libopenal1 package does not (it creates /usr/lib/libopenal.so.1 instead).

This breaks some third-party binaries, eg X-Plane (http://www.x-plane.com/).

Suggested fix:
The libopenal1 binary package should create a symbolic link from /usr/lib/libopenal.so.0 to /usr/lib/libopenal.so.1

Alternative fix:
Retain the old libopenal0a binary package in Intrepid, in addition to the new libopenal1 binary package. And change the libopenal1 package so that it does not replace libopenal0 or libopenal0a.

[nullack (nullack)]

Moving status to confirmed.

nullack@PPP:/$ sudo find -name libopenal.s*
[sudo] password for nullack:
./usr/lib/libopenal.so.1
./usr/lib/libopenal.so
./usr/lib/libopenal.so.1.3.253
./usr/lib32/libopenal.so.1
./usr/lib32/libopenal.so.1.3.253
nullack@PPP:/$ sudo apt-cache policy libopenal1
libopenal1:
  Installed: 1:1.3.253-4ubuntu1
  Candidate: 1:1.3.253-4ubuntu1
  Version table:
 *** 1:1.3.253-4ubuntu1 0
        500 http://archive.ubuntu.com intrepid/universe Packages
        100 /var/lib/dpkg/status

[nullack (nullack)]

Marking as invalid. It has been explained that the ABI for OpenAL changed which necessitated the naming change. Packages in the Intrepid repos have been rebuilt for the new library. It is recommended that upstream projects not in the repos follow suit.

[Joshua Wise (joshua-joshuawise)]

What changed in this version of the ABI? This seems to me like it should be left open for the alternate fix (i.e., leaving an libopenal0a package around).

[StefanPotyra (sistpoty)]

Hi,

no, libopenal0a (as in the creative variant) is obsolete, and won't come back. The right thing is to recompile 3rd party applications against the openal-soft. In case for binary only stuff, it would imho be better to dlopen system libraries instead of linking against it anyways (or link statically against these). But this is s.th. we can't solve in Ubuntu.

-> marking as won't fix.

Cheers,
    Stefan.

[Paul Bransford (draeath)]

/usr/lib/libopenal.so.0 coexists perfectly well with /usr/lib/libopenal.so.1

There is no reason to remove this package completely. Simply putting the files there from an earlier Ubuntu version makes applications (that may be impossible to fix, as you well know) happy.

While we are at it, lets remove awesfx like Fedora did. That's obsolete as well... nevermind that it's still needed, as libopenal.so.0 still is.

[Ben Supnik (bsupnik)]

Hi Y'all,

Could someone please tell me what binary functionality has been changed/removed from libopenal with this change?

I understand that the implementation has been changed radically. But OpenAL is an API for general access to abstract sound hardware. So...what _can't_ I do with libopenal.so.1 that I _can_ do with libopenal.so.0?

- Are there any APIs whose names have changed, been removed, or whose arguments have shifted? If so, what?
- Did the method of translating an API to an ABI change with this DLL?
- Is it simply the case that there are OpenAL extensions that are now no longer present?

(In the last case, it would be wrong for apps to link to OpenAL extensions - they should clearly be accessed with dlsym or something like it.)

I ask for two reasons:
1. If an API or ABI really changed, then simply linking against libopenal.so.1 (or dlopening whatever is on the disk) will not be enough, because something is different.
2. We have users who are simply symlinking a fake libopenal.so.0 from libopenal.so.1 and they claim it works. We can update our current products, but not ones that are out of development, so we need to know if this work-around makes any sense.

If the conclusion of this bug is "ABI changed, apps must recompile", someone please post a link to whatever it is that changed!

/ben

[emarkay (mrk)]

This may be a dupe - or that one is a dupe to this: https://bugs.launchpad.net/bugs/323745

Confirming that the developers of third party programs need to change their code?

If so, is the "1" version a "Drop-in" for the ")" and all they have to do is rename their link in their code?

Regardless I will pass this along to the X-Plane folks

[Ákos Maróy (akos-maroy)]

what did the X-Plane people say? it seems that the latest X-Plane is still trying to load libopenal.so.0 ...

[Ben Supnik (bsupnik)]

Hi,

We have programmed the 930 beta of X-Plane to look for BOTH libopenal
.so.1 and .so.0, because half the distros we support have changed the
lib version and half have not.

We continue to want to know (and still have not been told) in what way
the ABI changed that warranted a reversioning of the library.

We are _not_ changing old versions of X-Plane that have been closed.
Our users often symlink openal to get around that. Since the simlink
works, it appears to us that there are not real binary ABI changes,
hence our asking what really changed.

cheers
Ben

Ákos Maróy wrote:
> what did the X-Plane people say? it seems that the latest X-Plane is
> still trying to load libopenal.so.0 ...
>

--
Scenery Home Page: http://scenery.x-plane.com/
Scenery blog: http://xplanescenery.blogspot.com/
Plugin SDK: http://www.xsquawkbox.net/xpsdk/
X-Plane Wiki: http://wiki.x-plane.com/
Scenery mailing list: <email address hidden>
Developer mailing list: <email address hidden>

[nullack (nullack)]

Akos to accurately descripe what X-Plane people say:

1. When I contacted Austin Meyer about this, he declared that "I did not know how busy he is"
2. He said he did'nt care if the bug I reported to him existed or not, since his Linux support guy falsely claimed there was no problem and he didnt want to spend the time to figure out who was right
3. He said he had far more important things to do than support Ubuntu

I have since received no emails about other bugs I have reported.

By contrast, the open source flight sim project has been a wonderful partner and has actively engaged on quality issues with running their app on Ubuntu.

[Joshua Wise (joshua-joshuawise)]

nullack,

There are two of us on the X-Plane team here watching this bug. I am one of the "Linux support guys"; I have received no e-mail from you, so I will assume that you talked to Ben, who posted earlier. Ben also knows, though, that there is in fact a problem.

We are actively working to make X-Plane work better under Linux, and so we're following this issue here. If you need support with X-Plane, please send an e-mail to Randy (not to Austin directly), at <email address hidden>; Austin is, in fact, very busy, and not actively engaged with Linux technical support. We'd like to engage our users and the Ubuntu community in making X-Plane a better product, but we can't do that unless issues are filed to us through the correct channels. (I digress, though; the Launchpad bug tracker for Ubuntu also isn't the correct forum for this!)

In any event, I still think that there should be no harm in shipping both versions (libopenal0a and libopenal1) in different packages, just as Ubuntu does for liblua, libqt, and I'm sure countless other libraries.

Thanks,
joshua

[Paul Bransford (draeath)]

I think it's important to note however, that this is NOT an Ubuntu-specific issue. Other distros are making the same migration (and are doing it the same sudden-transition way).

While I think that the only reasons to REPLACE one library with the other is few shared files in /etc, I think there is no reason why the old code cannot be patched to look at a different file(s).

There's two different ways this can be fixed:

1. Fix it on the distro/packaging side
2. Fix it on the application side

I vote that #1 is the proper solution. If libqt was dropped when libqt4 was added, I think there would be a lot more noise... but it's nearly the same problem. We need a graceful transition, not an all-or-nothing approach as is being implemented now.

That said, Pre 1.1 openal development has ceased. Applications still being worked on (like x-plane) should notice this and do what they need to do to keep current.

I'm not saying anyone is doing this, but lets try to avoid stonewalling. Being inflexible doesn't help anyone. If I could code worth anything, I would have a go at fixing the issue myself. I hope there is someone out there with the skills and motivation.

And, taking a probably naive view, I don't see how this is an issue on the application side itself. Unless there are dirty kludges involved, it shouldn't be very hard to find and adjust any calls to a given set of functions. Why is there such resistance to 'porting' the code to the new version? If it really is that hard, then I would say someone is doing something wrong. Take that with some salt, since I likely don't know what I'm talking about.

Now... bickering aside. Why is it specifically that the old library cannot be provided side-by-side? It makes no sense to me. Is it the config file conflict in /etc? As mentioned earlier, this (probably) should be something even I can fix. The specification to use that file is stored somewhere. Even MS 'notepad' can do a find/replace. I sincerely hope there's more to this than laziness or stubbornness.

[Ákos Maróy (akos-maroy)]

Thanks for all the swift resposnes.

Ben: while 930 Beta might look for both libraries, the X-Plane Updater itself only looks for .0 - so actually updating to 930 Beta is not possible without working around this via a symlink, for example

[Ben Supnik (bsupnik)]

Hi Everyone,

I am the other Linux guy...first, to be clear:

Regardless of what happens with any distro, we (LR) have altered our
OpenAL support to dynamically load either version of libopenal in our
master code - over time all "live" apps will end up supporting either
distro.

Maróy, the next cut of the installer (2.06) should fix this when it
comes out. It is actually a bit silly that the installer links to
libopenal.so.0 at all - this is a result of shared makefiles, not a
design requirement.

Draeath, you ask a good question here: why do we not just patch our apps
(or why are we making so much noise since we already have done the work
for the patch).

In our case there are a few issues:

1. If there really is an ABI change, there is a risk that our change (to
simply load either version of the lib) isn't correct. This is the
practical reason why I keep asking "what changed". (The impractical
reason is my own sense of wonder as a developer of binary apps that the
lib changed.)

2. Since X-Plane 8 is no longer being developed, "change the code" isn't
a very good solution for us. From our perspective as developers of a
binary application that is ported onto Linux, if apps stop working due
to later changes in standard APIs for some distros, it means an
additional cost of development (in that we have to be in "maintenance"
mod for an app for as long as distros are coming out).

(Compatibility problems like this do creep in on Mac/Win, but on a much
slower time scale.)

3. Other distros are making this change...unfortunately the total rate
of change across all distros is very uneven...we first started hearing
about this a while ago and there are still users running the sim who are
on distros that are not making this change (not to mention users who are
not updating their distros). The "shear" of having the change not come
uniformly means we had to do a "dynamic linking" solution - dropping
support for all distros still on libopenal.so.0 was not an option for us.

Thus I reiterate my initial point: openAL is (in theory) a standard -
like OpenGL, it should not be necessary to change the version of the .so
even if the underlying implementation is 100% changed. We link against
ATI and NV implementations of the GL without multiple .so versions,
because the API and ABI are standard. It seems to me that libOpenAL
should be in that category, so there should not be an app-perceivable
change from the creative to the new implementation!

cheers
Ben

Ákos Maróy wrote:
> Thanks for all the swift resposnes.
>
> Ben: while 930 Beta might look for both libraries, the X-Plane Updater
> itself only looks for .0 - so actually updating to 930 Beta is not
> possible without working around this via a symlink, for example
>

--
Scenery Home Page: http://scenery.x-plane.com/
Scenery blog: http://xplanescenery.blogspot.com/
Plugin SDK: http://www.xsquawkbox.net/xpsdk/
X-Plane Wiki: http://wiki.x-plane.com/
Scenery mailing list: <email address hidden>
Developer mailing list: <email address hidden>

[Alex Ruddick (alexrudd0)]

This broke Gish (http://www.chroniclogic.com/gish.htm) for me earlier today. Adding a symlink fixed it.

To me, as a user, this is a regression and a serious bug. I don't care at all how many symlinks I have in /usr/lib32. I care when Ubuntu's packaging breaks my software. Please re-open. It's a trivial fix.

[Ben Supnik (bsupnik)]

For what it's worth, no one ever posted a clear explanation of _why_ the .so major version was bumped to this bug.

Given that users continue to work around this by sym-linking, it certainly _appears_ that the ABI of OpenAL is unchanged.

Can anyone point to at least one routine in the ABI that was modified, added or removed?

[Jo Shields (directhex)]

The following exported symbols were removed between the final openal package, and first openal-soft package:

alBombOnError_LOKI
alBufferAppendData
alBufferAppendData_LOKI
alBufferAppendWriteData_LOKI
alBufferDataWithCallback_LOKI
alBufferi_LOKI
alBufferWriteData_LOKI
alCaptureDestroy_EXT
alCaptureGetData_EXT
alCaptureInit_EXT
alCaptureStart_EXT
alCaptureStop_EXT
alcGetAudioChannel_LOKI
alcSetAudioChannel_LOKI
alGenStreamingBuffers_LOKI
alReverbDelay_LOKI
alReverbScale_LOKI
alutLoadMP3_LOKI
alutLoadVorbis_LOKI

Clearly, whilst X-Plane might not use these symbols, the old LOKI Software games will - which is precisely why symlinking sonames is wrong.

[Kazade (kazade)]

Is it worth repackaging libopenal0 for more recent releases? Can libopenal0 and libopenal1 live alongside each other?

[Ben Supnik (bsupnik)]

Ah - thank you for the symbol list!

 From the decorations (and names) it looks these symbols are all OpenAL
extensions...except for alBufferAppendData, which appears to have been
(incorrectly?!?) exported as a non-decorated symbol too. One document
from 2001 referes to the "well-documented" alBufferAppendData, but it's
not in the 1.1 spec, not even as a dropped symbol.

Anyway, I can't deny that, to the extent that there might be an
(undocumented and now deprecated?) core function in OpenAL, that that
would warrant a .so version name change.

I don't think the other symbols with decoration should warrant a soname
change; like OpenGL, OpenAL extension discovery should be done at
runtime to cope with renderers that don't provide all extensions;
changing the major version because a particular extension was dropped
would punish apps that correctly check extensions at runtime.

cheers
Ben

--
Scenery Home Page: http://scenery.x-plane.com/
Scenery blog: http://xplanescenery.blogspot.com/
Plugin SDK: http://www.xsquawkbox.net/xpsdk/
X-Plane Wiki: http://wiki.x-plane.com/
Scenery mailing list: <email address hidden>
Developer mailing list: <email address hidden>

[Paul Bransford (draeath)]

Yes, they can. I see no reason why libopenal.so.0 and libopenal.so.1
cannot both exist. Some minor patching may be required for
configuration file paths (I believe the libraries both use the same
path/files in /etc but have different expectations about the contents
of them)

directhex, you seem far more familiar with them than I. Are there any
reasons why my suggestion is impractical/impossible?

[vubang maxwell (serge-homic)]

The ABI of OpenAL is unchanged as users continue to work around this by sym-linking.
<a href="http://www.squidoo.com/fly-sim">flight simulator</a>

[Ákos Maróy (akos-maroy)]

yeah, it's a standoff: app developers refuse to link to the new shared object name, as the ABI didn't change. the distro makers refuse to maintain the old name. thus it's us, the users, how are left to do the symlinking manually :(

[Ben Supnik (bsupnik)]

It's not really a stand-off; we (LR, the company that makes X-Plane)
have patched X-Plane to dynamically detect either libopenal.so.0 or 1 so
that we will run without user mods on any distribution (including older
distros that haven't made this change).

It is only the older LR products that are no longer patched or modified
that require sim-linking. We don't feel great about this, but we also
can't crack open every legacy version of X-Plane any time a new
distribution changes a binary API.

[Ákos Maróy (akos-maroy)]

Ben,

Didn't know about this patch in X-Plane. Good to know now :)

Akos

[Ákos Maróy (akos-maroy)]

Ben,

One note: the X-Plane Linux DVD installer still depends on libopenal.so.0, at least the one I have downloaded a while ago - on the site, I can't find a DVD installer download anymore, and I don't have the Linux DVD installer on my DVD.

Akos

[Ben Supnik (bsupnik)]

I believe the OpenAL dependency was removed from the DVD installer with
the 2.05 installer. Unfortunately, this does nothing for already
pressed DVDs, but then that's only fixable by maintaining binary
compatibility at the distro level. Users can download the latest DVD
installer from the net and use it to unpack the contents of their older DVD.

[Ákos Maróy (akos-maroy)]

I have an older DVD installer - but where would I download a newer version from? on the x-plane.com site, I only see the demo & the updater, but not the DVD installer, for X-Plane v9: http://x-plane.com/pg_downloads.html

[Ben Supnik (bsupnik)]

http://wiki.x-plane.com/DVD_Installers

[Ákos Maróy (akos-maroy)]

oh. I see. good to know :)

[Robert Jaemmrich (mail-robert-jaemmrich)]

I'm running X-Plane 10.03 Beta 10 on Ubuntu Oneiric 64 here.

A X-Plane MessageBox states that "We could not locate an load OpenAL" while strace shows

open("/usr/lib32/libopenal.so", O_RDONLY) = 13
read(13, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340k\0\0\0\0\0\0"..., 512) = 512
close(13)
(...)
open("/usr/lib/libopenal.so", O_RDONLY) = 13
read(13, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340k\0\0\0\0\0\0"..., 512) = 512
close(13)

Any workaround is very appreciated. :-)