Bug 181989 - output of openal-config --libs does not contain -pthread
output of openal-config --libs does not contain -pthread
Product: Fedora
Classification: Fedora
Component: openal (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Andreas Bierfert
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2006-02-18 08:00 EST by Joni Yrjana
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-27 07:10:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Joni Yrjana 2006-02-18 08:00:13 EST
Description of problem:
The program "openal-config" with the option "--libs" does not contain "-pthread"
causing linking to fail.

Version-Release number of selected component (if applicable):

How reproducible:
Every time.

Steps to Reproduce:
1. cat > o.c
#include <AL/al.h>
int main(void)
  ALuint s;
  alGenSources(1, &s);
  return 0;
2. gcc $(openal-config --cflags) -c o.c -o o.o
3. gcc $(openal-config --libs) o.o -o o
Actual results:
Fails to link with the following errors:
/usr/lib/gcc/i386-redhat-linux/4.0.2/../../../libopenal.so: undefined reference
to `pthread_create'
/usr/lib/gcc/i386-redhat-linux/4.0.2/../../../libopenal.so: undefined reference
to `pthread_mutex_trylock'
/usr/lib/gcc/i386-redhat-linux/4.0.2/../../../libopenal.so: undefined reference
to `pthread_join'
collect2: ld returned 1 exit status

Expected results:
Successful linking.

Additional info:
Adding -pthread to the gcc linking options fixes it, like this:
$ gcc $(openal-config --libs) -pthread o.o -o o
Comment 1 Andreas Bierfert 2006-02-20 02:56:28 EST
I know about this issue and I reported it upstream. Please use pkg-config for
now till it is fixed.

[09:00 AM][awjb@alkaid ~]$ pkg-config --libs openal
-lopenal -lpthread  
Comment 2 Andreas Bierfert 2006-02-26 05:24:34 EST
Fixed and pushed.
Comment 3 Hans de Goede 2006-02-26 15:06:39 EST

This fix has the nice side affect of bumping the .so version, next time please
check for something like this before pushing a change. It might even be an idea
to issue an other update undoing this since the new .so version undoubtly means
that upstream plans on making abi changes, which means that we will have an
unstable abi for a while which will _not_ be caught by the .so versioning since
you're using CVS with no abi guarantees as such, hence its a bad idea to use CVS.

Also see bug 183133 and bug 183134 I'll but 183134 on hold untill I hear from
you and request the same for 183133 .
Comment 4 Ville Skyttä 2006-02-26 15:21:33 EST
Changing sonames *must* be announced beforehand on -maintainers and not be done
at all without a _very_ good reason for released distro versions.  This one was
pushed all the way even back to FC3.  I'm inclined to just remove the update
from the repositories.  Comments?
Comment 5 Philip Heuer 2006-02-26 16:08:27 EST
This fix allows torcs to be compiled against openal again. Unfortunately, this
version also introduces some changes that hurt the sound quality in torcs.

Torcs did not have these sound quality issues with the 20060204cvs version, but
torcs could not compile with this version (see bug 179614 for details).
Comment 6 Rex Dieter 2006-02-26 17:40:01 EST
IMHO, the "proper" fix would have been to make sure the libopenal.so shared lib
contained no undefined references (ie, link the shared lib against -lpthread). 
Then there'd be no need to pull in the extra lib(s) for client apps.
Comment 7 Andreas Bierfert 2006-02-27 03:43:37 EST
Hm, sorry folks... the bump in .so was due to broken libtool versioning on older
versions. I forgot to check for this as this was just discussed on the openal
mailinglist because debian maintainers wanted the versioning to follow a clear
path (to exactly avoid situations like this) and thought upstream did not think
to much about this. As to my knowledge the bump in .so is not caused by any ABI
changes and just a _fix_ for broken .so versioning before... so go ahead and

As to what Rex said: I will see if I can convince upstream about this. Good to
know that at least torcs compiles again now.

Comment 8 Hans de Goede 2006-02-27 04:11:21 EST
Are you _sure_ that this .so bump is only because of some dark libtool issues
and nothing else? Upstream might take the chance todo some abi changes now they
have the chance. They are free todo so untill they do an official release with
the new .so-name. I would rather see that you roll back to the previous version
as an update especially since torcs seems to suffer from audio quality
regression. The torcs build problems can be fixed in another way.
Comment 9 Andreas Bierfert 2006-02-27 04:23:40 EST
I guess I can do that if you folks think that this is the best solution until
upstream is done fiddeling.

Will do so asap.
Comment 10 Hans de Goede 2006-02-27 04:25:38 EST
Comment 11 Andreas Bierfert 2006-02-27 07:10:35 EST
Sorry again... :/ 

Fixed and pushed.

Note You need to log in before you can comment on or make changes to this bug.