FS#39597 - [TeamViewer9] lib32-glibc problem with Intel haswell processors
Attached to Project:
Community Packages
Opened by Prabu (prabuselva) - Sunday, 23 March 2014, 07:30 GMT
Last edited by Jan Alexander Steffens (heftig) - Sunday, 04 May 2014, 15:06 GMT
Opened by Prabu (prabuselva) - Sunday, 23 March 2014, 07:30 GMT
Last edited by Jan Alexander Steffens (heftig) - Sunday, 04 May 2014, 15:06 GMT
|
Details
Description:
It seems that the lib32-glibc is compiled with --enable-lock-ellision flag in PKGBUILD. This flag has problems with Intel 4th Gen Haswell processors. Because of this, I was unable to use the latest Teamviewer9 in my system. Also the Anjuta crashes often with pthread_mutex lock problem. If --enable-lock-ellision is not much significant, then I suggest it to be removed from the configure cmd in the PKGBUILD. Compiling the glibc library without that flag resolved all the startup issues with Teamviewer9 and Anjuta. This Problem has been experienced by few people as discussed in the forum https://bbs.archlinux.org/viewtopic.php?id=175878 Additional info: * package version(s) - lib32-glibc-2.19-3.tar.gz * config and/or log files etc. Steps to reproduce: 1) All the below steps need to be performed only in Intel 4th Generation Processor(Haswell Architecture)**. 2) Use the package in the Arch community repository. Try to Start Teamviewer 9. It will never show up. 3) Also start Anjuta and try to build a hello world autotools project. It will crash when the autogen package tries to configure the package Solution: 1) As Holoduke mentioned in the above forum, I recompiled the lib32-glibc without the enable-lock-ellision flags. Now all the problems seems to be resolved. 2) My recompiled version of lib32-glibc can be downloaded from https://copy.com/qSIobMy1K8aD 3) I compiled using the same PKGBUILD from community repo but removed the enable-lock-ellision flag from the build configuration. |
This task depends upon
Closed by Jan Alexander Steffens (heftig)
Sunday, 04 May 2014, 15:06 GMT
Reason for closing: Upstream
Additional comments about closing: Not our bug
Sunday, 04 May 2014, 15:06 GMT
Reason for closing: Upstream
Additional comments about closing: Not our bug
yeah I know it is not glibc issue. This is my first bug post in Archlinux bug tracking system. Can you guide me on how to report this issue to the package maintainer of lib32-glibc. So that future updates of this package may not break my system again. I have provided the steps for reproducing the crash. Should I need to provide more details about the crash?
If --enable-lock-ellision should not be removed from the lib32-glibc PKGBUILD, please close this as ie. "upstream".