Hi folks,

I just ordered a new i5-750 box and will be installing Slackware64 13.0 on it. I've been using Slackware since 8.x, but I've never ventured into 64 bit OSes before. Anything in particular that I should be prepared for other than the multilib stuff which seems to be well-documented?

Thanks,
Matt

Not really. The rest of it is pretty much the same. When you use slackbuilds from SBo, just remember to use ARCH=x86_64.

The only thing different I can think of is you need to run your SlackBuilds like this:
ARCH=x86_64 ./PRGNAM.SlackBuild

Most things will now build on a 64-Bit system and the SlackBuilds have been updated. If you can use Slackware, you probably won't have any trouble using Slackware64.

That's what I was hoping to hear! I'm sure there will be some hardware-related hiccups as I try to get everything working, but that's half the fun of a new box I assume I could just slap that ARCH=x86_64 in my .bashrc so I'd never have to remember it.

If you are a KDE user consider upgrading to current or vbatts packages for KDE 4.3.1 or using another desktop. The KDE included in Slackware 13.0 is, in my opinion, a bit "rough and ready", though it can be improved by turning off akonadi and nepomuk and replacing kwin with the openbox window manager.

samac

Here's the problem with that: ARCH gets started with bash, set for 64-bit. Then you run the SlackBuild script, and ARCH is redefined in the subshell and now it's back to 32. What I do is use a function I've defined in .bash_profile to tailor all build scripts, just gotta remember to run it on each one.

You have to export it or else the SlackBuild script won't be able to use it.
So your .bashrc should have:

I do it system wide:
Of course local_setup.sh is executable.

If you use slackpkg, be careful to select a 64 bits mirror in /etc/slackpkg/mirrors

If you install sbopkg for SlackBuilds, it will detect that you're running x86_64 automatically.

http://www.sbopkg.org/

Regarding multilib, there is an annoying problem when compiling programs from source.
Many of the build scripts will look for libraries in /usr/lib, and try to compile against them. This usually leads to configure errors due to missing libraries, or compile errors regarding mainly to pointer casting, although other kind of errors may occur.

My quick 'n' dirty solution, knowing that only a few programs actually rely on that folder (the wicd I compiled 'cause the one that came with slackware have a few issues and wine) was to temporarily rename /usr/lib to something else. Sometimes the config scripts are hard coded with the /usr/lib path, so just touching the environment variables is not enough.

I had a lot of failed compiles before really taking a look at the errors and realize the real cause.

I ran into that also, here's an example:

--- bitlbee-1.2.4/configure.orig 2009-10-17 11:26:46.000000000 -0400
+++ bitlbee-1.2.4/configure 2009-12-17 13:56:41.160985447 -0500
@@ -19,7 +19,7 @@
pidfile='/var/run/bitlbee.pid'
ipcsocket='/var/run/bitlbee.sock'
pcdir='$prefix/lib/pkgconfig'
-systemlibdirs="/lib /usr/lib /usr/local/lib"
+systemlibdirs="/lib64 /usr/lib64 /lib /usr/lib /usr/local/lib"

msn=1
jabber=1

its easy to fix the 64 bit build, but then producing a 32 bit build on a machine with lib64 would be busted. I guess maybe some conditional patching based on $ARCH is the practical workaround.

Wouldn't that only be an issue if you were compiling a 32 bit program for a 64 bit environment or am I missing something?

I've heard reports of less than happy things with that version of KDE. Are the -current versions drop-in replacements or will that mess other things up? I suppose it would be foolish to ask if Slack 13.1 would be on the horizon for just such an update . . .

No they are most definitely not drop in replacements you will have to upgrade to current completely. I believe there the vbatts KDE will drop straight in. Here is a link on how to do it http://www.linuxquestions.org/questi...vbatts-778684/

samac

Be careful not to get a speeding ticket! It is fast.