SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Anyone know why Slackware 13 ships with glxinfo as a symlink to glinfo, rather than actually providing glxinfo? The information glxinfo provides is much more helpful than the information from glinfo and, frankly, it seems like bad package management to create such a link, rather the shipping the actual binary.
Have you asked Pat? These questions may or may not get answered by someone
on the Slackware core team. More likely a lot of guesses from others. Maybe
email Pat and get it "straight from the horse's mouth," as the saying goes.
Yeah, there's been some discussion on #ati, #radeon, and #slackware on Freenode. It appears, from the slackbuild, that Pat noticed one of them was deprecated and dropped it (thanks to ccfreak2k for noticing that and pointing it out). Only it really looks like he dropped the wrong one :-) I'm e-mailing him now.
Several days ago I contacted Pat about the issue. He said the development team was aware of the change. He did not say whether he would change anything with the next round of Current.
In my case, XBMC would not start because the software was trying to extract information from the traditional glxinfo command (specifically looking for GL support).
I extracted the glxinfo command from 12.2 (x/mesa-7.0.3 package), broke the newer sym link, and then installed the older glxinfo. XBMC then started with no complaints.
It's not clear what you are referencing. Perhaps you can edit your link
and put the post rather than a page.
I'm pretty sure he's making reference to this post:
Quote:
Oh, and glxinfo output is very different now. The mesa demos (of which glxinfo is one) were reworked completely -- some were dropped, some were added, and some were rewritten -- all of them now use libGLEW, which is why glew had to be added. What used to be "glxinfo" is no longer present -- instead, there's something called "glinfo" which may or may not be intended as the replacement, but at the time I was building all of this, that wasn't important, so I just installed glinfo as glxinfo in the package.
Anyways I'm glad I found this thread. I was wondering about this too.
Regardless of whether glxinfo should or shouldn't be included in Slackware due to it's now deprecated status, I dislike the idea of the symlink. One command simply shouldn't pretend to be another, it's ugly. Better to have a 'command not found' than weird parsing errors from scripts that were expecting one format of output and got another.
Pat explained to me that he had been told that glxinfo was dropped by upstream and that, in fact, it would no longer build. I pointed out that wasn't the case, it's still present and still builds by default (with no extra arguments to ./configure). It is not installed by default any more, but I'm not sure when that changed. He said he'd rectify the situation in future releases and even went so far as to apologize for the omission.
Sat Sep 19 16:48:50 CDT 2009
patches/packages/mesa-7.5-i486-2.txz: Rebuilt.
Fixed install script to add glxinfo and other programs that were part
of previous Mesa patches. I was under the impression that these no longer
built, and had been deprecated upstream. Thanks to Adam Kirchhoff for
setting me straight on that.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
