Bug 181989 - output of openal-config --libs does not contain -pthread
Summary: output of openal-config --libs does not contain -pthread
Alias: None
Product: Fedora
Classification: Fedora
Component: openal
Version: 4
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Andreas Bierfert
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2006-02-18 13:00 UTC by Joni Yrjana
Modified: 2007-11-30 22:11 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-02-27 12:10:35 UTC

Attachments (Terms of Use)

Description Joni Yrjana 2006-02-18 13:00:13 UTC
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 07:56:28 UTC
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 10:24:34 UTC
Fixed and pushed.

Comment 3 Hans de Goede 2006-02-26 20:06:39 UTC

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 20:21:33 UTC
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 21:08:27 UTC
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 22:40:01 UTC
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 08:43:37 UTC
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 09:11:21 UTC
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 09:23:40 UTC
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 09:25:38 UTC

Comment 11 Andreas Bierfert 2006-02-27 12:10:35 UTC
Sorry again... :/ 

Fixed and pushed.

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