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.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I can see the difference between adding libstdc+++ to aaa_elflibs and adding glew to aaa_elflibs. Can't you? If an extra glew symlink is needed or desired, then that symlink belongs in the glew package itself.
I don't see how the symlinks would help in any case. AIUI, it's the SONAME in the library that is the problem. The symlinks only affect the build time linker, and at runtime ld.so only cares about loading a library with a matchimg SONAME to that used by the linker at build time: it could find it in libbananasyrup.so for all it cares.
As for whether old obsolete versions of libraries should be included in aaa_elflibs or their corresponding package, I guess that depends on what the purpose of aaa_elflibs is? Is it to provide obsolete libraries, or to be a mechanism for making sure that vital system libraries aren't removed. At the moment, it seems to be performing both roles, and I'm not sure that is the cleanest approach.
In this particular situation though? What is Pat expected to do? If he adds 1.10, what about 1.11, or 1.12? Is he supposed to keep adding more and more of these old library versions to aaa_elflibs as new ones are released just on the off-chance that someone wants to run a 3rd party pre-compiled binary that was built against one of them?
The underlying problem here is that the libGLEW devs aren't maintaining a stable ABI.
The underlying problem is that the games are proprietary meaning users can not recompile or patch them, unfortunately fixing that for even one game is a lot of work and then you will still find games where the dev's are willing to change the license, but unable due to other licenses they must obey (Like if they used a proprietary compiler)...
As far as Slackware is concerned, I think the best two choices are to provide the missing old libraries as they are reported in a package such as aaa_elflibs or to ignore the issue and let users solve it for themselves.
In that case, I'd just build glew 1.10 with ./configure and make, then copy the resulting .so file into the game directory, then make sure the game's launcher sets the LD_PATH so that it loads libraries from the game directory. I had to do something like that (different library, and they've since fixed it) to get the last version of Grid Cartographer to run.
I am a typical Slackware user, aren't I? :P
Robby is correct that this is a bug in the game. The developers need to start bundling that library with the game.
If I wanted it system-wide (and I don't see why I would), I'd build a "glew110" package. But I consider this a game-specific issue and I'd prefer a game-specific fix.
Allowing everyone to connect to your X is not good. "-nolisten tcp" should be used by default.
A way to disable listening to TCP without changing startx is to use xserverrc. If a xserverrc file exists, startx will honor it. So you can create an executable file named /etc/X11/xinit/xserverrc and put any option you want there. For example, mine has the following
It *is* used by default, which is why you don't need to explicitly specify it any more.
One of the updates removed this option and X began to listen on port 6000. I had to manually add this option to startx.
Thanks everyone for checking this out.
Allowing everyone to connect to your X is not good. "-nolisten tcp" should be used by default.
Our BDFL has always agreed with disallowing XDMCP connections by default.
Quote:
One of the updates removed this option and X began to listen on port 6000. I had to manually add this option to startx.
Thanks everyone for checking this out.
I would like to point out that Slackware is shipped with these defaults:
1. /etc/kde/kdm/kdmrc
Code:
[Xdmcp]
# Whether KDM should listen to incoming XDMCP requests.
# Default is true
Enable=false
2. /etc/X11/xdm/xdm-config
Code:
! SECURITY: do not listen for XDMCP or Chooser requests
! Comment out this line if you want to manage X terminals with xdm
DisplayManager.requestPort: 0
Our BDFL has always agreed with disallowing XDMCP connections by default.
I would like to point out that Slackware is shipped with these defaults:
1. /etc/kde/kdm/kdmrc
Code:
[Xdmcp]
# Whether KDM should listen to incoming XDMCP requests.
# Default is true
Enable=false
2. /etc/X11/xdm/xdm-config
Code:
! SECURITY: do not listen for XDMCP or Chooser requests
! Comment out this line if you want to manage X terminals with xdm
DisplayManager.requestPort: 0
Ok, got it. Thank you for the thorough explanation.
I was freaked out, when saw that netstat's output. I have iptables rules applied, but more security is better.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
I have iptables rules applied, but more security is better.
