This seems very strange.

Only very minor changes in public-facing things have changed in 0.9.23.. An additional define was added to pulse/volume.h but that shouldn't change anything with regards to ABI.

Some of the build instructions where changed slightly but again I wouldn't have thought these changes in particular would cause a binary compatibility issue and I know various places where 0.9.23 has been a drop in replacement without any issues.

Regardless, there is certainly not any intention of ABI incompatibility (we go out of our way to ensure this is not the case as so many components on a system link to libpulse, changing it would be a royal pain), so not bumping the major version is very much intended.

What can sometimes happen however is that applications become "overlinked" on your system. e.g.

[colin@jimmy pulseaudio (master-volume3)]$ objdump -p `which pactl`| grep libpulsecommon
  NEEDED               libpulsecommon-0.98.so
[colin@jimmy pulseaudio (master-volume3)]$ objdump -p `which mplayer`| grep libpulsecommon

(for pactl, this is intended that it overlinks to libpulsecommon as it's part of the PA build process) but any other app that links to libpulsecommon directly (ldd will report indirect linking here) is broken.

I suspect you may have such apps on your system which leads to a rebuild being necessary.

We do not guarantee ABI on libpulsecommon, but libpulse itself should be the only thing to link to this (other than the deliberately overlinked binaries shipped with pa itself - like pactl in the above example)


So my initial guess would be a general overlinking problem in your distro on the whole, which thus requires recompiles when PA version is bumped. But this is not directly a problem of PA, but rather how the other packages are built.

You've not mentioned what distro you are using, so I cannot comment further.

"but any other app that links to libpulsecommon directly (ldd will report indirect linking here) is broken."

Ah, there we are: gnome-shell is linked to libpulsecommon on my system, as also is gnome-sound-applet.

/usr/lib/libpulse.la, libpulse-browse.la, /usr/lib/libpulse-mainloop-glib.la and /usr/lib/libpulse-simple.la each list /usr/lib/libpulsecommon-0.9.22.la as a dependency, maybe that is the source of the overlinking, in which case presumably libtool is at fault somewhere.

"You've not mentioned what distro you are using, so I cannot comment further"

I mentioned that the distribution is slackware 13.37.  Additional gnome packages are built from pristine tarballs (quite similar to gsb, although I do not use gsb).  libtool is at version 2.4.

Hmm, yeah, perhaps the .la files are causing problems here. Not sure if that's something we can fix at our end but I'll certainly look into it.

At least this is a (relatively) localised issue rather than a full blown ABI problem :)

Sorry I missed that you said slackware... I blame lack of caffeine :D

Just to correct one point in case it helps your investigations.  objdump shows that gnome-shell is directly linked to libpulsecommon:

$ objdump -p /usr/bin/gnome-shell | grep pulse
NEEDED               libpulse-mainloop-glib.so.0
NEEDED               libpulse.so.0
NEEDED               libpulsecommon-0.9.22.so

However I was wrong about gnome-sound-applet: that one is not (it is only indirectly linked).  On a cursory look I have not managed to find any other gnome binaries directly linked to libpulsecommon - no other binaries in /usr/bin or /usr/libexec apart from pulseaudio's own are directly linked to pulsecommon, nor are any libraries in /usr/lib apart from the pulseaudio libraries.

This is not of course exhaustive - there are plenty of other binaries and libraries in the system - but it might lead one to believe that the problem is with the gnome-shell package.  However, on looking at its configure.ac and the automake files I can't see anything obviously wrong.  If you can find anything there I'll file a gnome-shell bug.

I have reinstalled pulseaudio-0.9.23 and recompiled gnome-shell.  Although most things work once I recompile gnome-shell, I still get the odd program which has difficulty loading libraries dynamically.  In particular a gtk+-3 program which doesn't use pulseaudion reports that it cannot find libgcc_s.so.1 in order to call pthread_cancel, and aborts when the call to pthread_cancel is made.  I have to revert to pulseaudio-0.9.22 to get the program to behave normally, and recompiling it doesn't help.

So something odd is still going on with pulseaudio.

(In reply to comment #5)
> So something odd is still going on with pulseaudio.

I really do suspect this is an indirect problem. Perhaps the GTK app is using libcanberra (e.g. via the canberra gtk module) and it in turn is linked strangely against pulseaudio's libpulsecommon? I suspect you can find out which ones are causing the problem by stepping through the libs and loaded in the app and finding the problem.

I really don't think the primary problem is with libpulse itself, but I'll ask around and see if any other users are having problems with an in-place upgrade. I'll even upgrade a distro I have kicking around with a 0.9.23 and see if it has any problems (no gnome-3 there but that shouldn't affect any testing with regards to ABI testing).

"Perhaps the GTK app is using libcanberra (e.g. via the canberra gtk module) and it in turn is linked strangely against pulseaudio's libpulsecommon?"

Spot on, although it is libcanberra's pulseaudio module rather than its gtk module.  I recompiled libcanberra, the problem disappears and:

$ objdump -p /usr/lib/libcanberra-0.28/libcanberra-pulse.so | grep pulse

gives:

  NEEDED               libpulse.so.0
  NEEDED               libpulsecommon-0.9.23.so

So libcanberra as well as gnome-shell is also improperly linking with libpulsecommon on my system.  Since libcanberra is I believe also one of Lennart's projects, if it is not a libtool-2.4 issue then one of his projects does not like another one.

Anyway, if any other gnome users are experiencing the same issue and happen to read this bug report, the problem appears to be resolved, pro tem, by recompiling libcanberra and gnome-shell whenever pulseaudio is upgraded.

(In reply to comment #7)
> "Perhaps the GTK app is using libcanberra (e.g. via the canberra gtk module)
> and it in turn is linked strangely against pulseaudio's libpulsecommon?"
> 
> Spot on, although it is libcanberra's pulseaudio module rather than its gtk
> module.  I recompiled libcanberra, the problem disappears and:
> 
> $ objdump -p /usr/lib/libcanberra-0.28/libcanberra-pulse.so | grep pulse
> 
> gives:
> 
>   NEEDED               libpulse.so.0
>   NEEDED               libpulsecommon-0.9.23.so
> 
> So libcanberra as well as gnome-shell is also improperly linking with
> libpulsecommon on my system.  Since libcanberra is I believe also one of
> Lennart's projects, if it is not a libtool-2.4 issue then one of his projects
> does not like another one.

I don't think this is a problem specific to upstream but rather how it's compiled at a distro level. e.g. on my system here (where we take particular care to avoid overlinking generally):

[colin@jimmy libcanberra]$ objdump -p /usr/lib64/libcanberra-0.28/libcanberra-pulse.so | grep pulse
/usr/lib64/libcanberra-0.28/libcanberra-pulse.so:     file format elf64-x86-64
  NEEDED               libpulse.so.0
  SONAME               libcanberra-pulse.so
  required from libpulse.so.0:

So as you can see I do not suffer from the same problem here. I really think this is something you need to take up with the slackware guys with regards to general goals to reduce overlinking.

"So as you can see I do not suffer from the same problem here. I really think this is something you need to take up with the slackware guys with regards to general goals to reduce overlinking."

Is your distribution debian?  On debian, I have read this: http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html .  The three solutions for overlinking offered there are (i) to get the *.pc files right in the library which is being overlinked against, which I deduce you think to be already correct for pulseaudio; (ii) to get the packaging of the code which uses the library right, by avoiding non-standard config tools and if need be linking with -Wl,--as-needed, which I deduce you think is correct right now for libcanberra at least (viewing libcanberra as the user code); and (iii) to fix libtool, in particular so that it will distinguish between static and shared linking requirements.

It is curious though that only libcanberra and gnome-shell appear to exhibit this problem, amongst the other candidates having pulseaudio dependencies (such as gnome-sound-applet, gnome-mplayer and the alsa and gstreamer plugins for pulse), but presumably that is something to do with the inner workings of libtool.

The conclusion to this seems to be that if ABI compatibility between releases for pulseaudio is wanted, a patched libtool must be used.  slackware avoids patching tarballs unless there is a clear bug or security issue which needs to be dealt with.  I doubt an obscure overlinking point with pulseaudio, libcanberra and gnome-shell, none of which are shipped by slackware, is going to bring about patching of libtool, but who knows.

Anyway I think this has gone as far as it can and I am grateful for your assistance.

Closing based on comments above.