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.
As I mentioned in this thread, maybe it is time to consider adding FS specifically for SSDs, such as F2FS, JFFS2, others for those who want to install Slackware on an SSD using a FS specifically for NAND devices.
A collection of stability fixes here across glamor, Xwayland, input, and Prime support. Also a security fix for CVE-2017-2624, a timing attack which can brute-force MIT-MAGIC-COOKIE authentication. Everybody is encouraged to upgrade. Thanks to all who contributed fixes!
Maybe it would be a good idea to remove libmsn? Windows Live Messenger was discontinued in April 2013 (except China, where it ended in October 2014). Judging from libmsn website, the project seems to be dormant: the last commit was made in 2011-11-25. Does this library still serve any purpose?
Based on this topic, it seems that on 64bit systems, /etc/ld.so.conf points to the wrong directory for the /usr/x86_64-slackware-linux/lib64 entry, because there is no lib64 directory under /usr/x86_64-slackware-linux/, only lib.
There are two potential fixes I see for this, one being to modify etc.SlackBuild to somehow adjust the sed line that changes all the lib dirs to lib64 to somehow exclude this one, or to adjust binutils.SlackBuild to change that directory to lib64 on 64bit machines. I think the latter is quite a bit easier, so I threw together a quick patch for the SlackBuild.
Code:
diff --git a/binutils.SlackBuild b/binutils.SlackBuild
index 41fa980..6d46e9b 100755
--- a/binutils.SlackBuild
+++ b/binutils.SlackBuild
@@ -167,7 +167,7 @@ make install DESTDIR=$PKG || exit 1
# Move ldscripts to /usr/lib${LIBDIRSUFFIX}, and then put symlinks in place
mv $PKG/usr/${TARGET}/lib/ldscripts $PKG/usr/lib${LIBDIRSUFFIX}
( cd $PKG/usr/${TARGET}
- ln -s /usr/lib${LIBDIRSUFFIX}/ldscripts lib/ldscripts
+ ln -s /usr/lib${LIBDIRSUFFIX}/ldscripts lib${LIBDIRSUFFIX}/ldscripts
for FILE in ar as ld ld.bfd ld.gold nm objcopy objdump ranlib strip ; do
if [ -r "/usr/bin/$FILE" ]; then
rm -f bin/$FILE
It likely isn't a big deal as there doesn't seem to be anything residing in there other than a symlink for ldscripts that points to /usr/lib${LIBDIRSUFFIX}/ldscripts/, but it probably wouldn't hurt to make sure ld.so.conf points to the correct directory anyway
Adding an option in eliloconfig to use something other than the default "Slackware" would be a nice feature. This would enable distinct UEFI NVRAM entries to select from when booting. Perhaps like "test" or something similiar.
Just a thought
I know you can boot other installations from your elilo.conf file, but this would allow a recovery if your Slackware entry gets hosed up.
Thanks
John
Last edited by AlleyTrotter; 03-05-2017 at 08:47 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
SSD ready FS support for installation
