{"action":"created","issue":{"url":"https://api.github.com/repos/libjpeg-turbo/libjpeg-turbo/issues/88","repository_url":"https://api.github.com/repos/libjpeg-turbo/libjpeg-turbo","labels_url":"https://api.github.com/repos/libjpeg-turbo/libjpeg-turbo/issues/88/labels{/name}","comments_url":"https://api.github.com/repos/libjpeg-turbo/libjpeg-turbo/issues/88/comments","events_url":"https://api.github.com/repos/libjpeg-turbo/libjpeg-turbo/issues/88/events","html_url":"https://github.com/libjpeg-turbo/libjpeg-turbo/issues/88","id":164033724,"number":88,"title":"PowerPC without altivec causes crash (e.g. G3)","user":{"login":"rmottola","id":12441935,"avatar_url":"https://avatars.githubusercontent.com/u/12441935?v=3","gravatar_id":"","url":"https://api.github.com/users/rmottola","html_url":"https://github.com/rmottola","followers_url":"https://api.github.com/users/rmottola/followers","following_url":"https://api.github.com/users/rmottola/following{/other_user}","gists_url":"https://api.github.com/users/rmottola/gists{/gist_id}","starred_url":"https://api.github.com/users/rmottola/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rmottola/subscriptions","organizations_url":"https://api.github.com/users/rmottola/orgs","repos_url":"https://api.github.com/users/rmottola/repos","events_url":"https://api.github.com/users/rmottola/events{/privacy}","received_events_url":"https://api.github.com/users/rmottola/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/libjpeg-turbo/libjpeg-turbo/labels/bug","name":"bug","color":"fc2929"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":16,"created_at":"2016-07-06T09:22:38Z","updated_at":"2016-07-07T00:27:41Z","closed_at":null,"body":"As referenced in the Debian mailing list  [thread](https://lists.debian.org/debian-powerpc/2016/07/msg00000.html) Using the library on G3 or other powerpc processors without AltiVec causes illegal instructions.\r\n\r\nSetting JSIMD_FORCENONE=1 fixes the issue, meaning processor feature autodetection is not implemented on PPC or anyway not working."},"comment":{"url":"https://api.github.com/repos/libjpeg-turbo/libjpeg-turbo/issues/comments/230946705","html_url":"https://github.com/libjpeg-turbo/libjpeg-turbo/issues/88#issuecomment-230946705","issue_url":"https://api.github.com/repos/libjpeg-turbo/libjpeg-turbo/issues/88","id":230946705,"user":{"login":"ssvb","id":78642,"avatar_url":"https://avatars.githubusercontent.com/u/78642?v=3","gravatar_id":"","url":"https://api.github.com/users/ssvb","html_url":"https://github.com/ssvb","followers_url":"https://api.github.com/users/ssvb/followers","following_url":"https://api.github.com/users/ssvb/following{/other_user}","gists_url":"https://api.github.com/users/ssvb/gists{/gist_id}","starred_url":"https://api.github.com/users/ssvb/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ssvb/subscriptions","organizations_url":"https://api.github.com/users/ssvb/orgs","repos_url":"https://api.github.com/users/ssvb/repos","events_url":"https://api.github.com/users/ssvb/events{/privacy}","received_events_url":"https://api.github.com/users/ssvb/received_events","type":"User","site_admin":false},"created_at":"2016-07-07T00:27:41Z","updated_at":"2016-07-07T00:27:41Z","body":"@lsorense \r\n\r\n> If qemu had a bug in the auxv emulation, that would have caused other things to break too, so I don't think that is relevant. That's just a bug and fixed long ago it would seem.\r\n\r\nWell, the point is that neither ``/proc/self/auxv`` nor ``/proc/cpuinfo`` parsing is pretty. But the ``/proc/self/auxv`` method used to actually cause very real problems for the very real users (here is a valgrind bugreport - https://bugs.kde.org/show_bug.cgi?id=253519), while the ``/proc/cpuinfo`` method always worked fine. In my opinion the choice between these two methods is very obvious. As @dcommander said, there is no point fixing something that is not broken. And regarding text files in general, there are also such things as ``XML``, ``JSON``, etc.\r\n\r\nAs for the emulator \"bugs\", it means that they need to intercept the ``/proc/self/auxv`` read operations and fixup them on the fly instead of just providing transparent access to the host file system. This is an \"ugly\" thing from their point of view and you can't really blame them for being a bit reluctant to fix this crap. And we had at least QEMU and Valgrind both having problems with this.\r\n\r\n@dcommander \r\n\r\n> And everyone please give the performance FUD a rest, OK? This interface is read exactly once during the execution of libjpeg-turbo, and in reality, it is less than 2 kilobytes of data. The same technique is being used quite successfully on a variety of relatively slow mobile devices.\r\n\r\nIf some application links a few dozens of various multimedia libraries and each one of them does such stunts for the CPU runtime features detection at start, then the application startup time might be affected a little bit. I believe that Mozilla had some patch for implementing their own runtime CPU features detection code and then patching every third-party library in their source tree to use this common code. Now I don't see anything like this in a more recent Mozilla code, so they have probably decided that it is not worth the efforts and abandoned this idea :-)\r\n\r\nAlso ``/proc`` might be sometimes not mounted (for example in chroot), and this causes troubles for both ``/proc/self/auxv`` and ``/proc/cpuinfo`` methods. Too bad that the glibc developers have introduced the dedicated ``getauxval()`` function so late."}}
{"actor":{"display_login":"ssvb"}}