To revive this dormant-but-not-dead subject:

I too just wanted to say that I too have more than a passing interest in the ideas of Shingoshi, as far as using slackpkg or slapt-get or whatever to 'upgrade' Slackware-32 to some sort of 64-bit system. Very interesting!

The reason: It's with great interest that I read of the pending release of Slackware64. I use Slackware-11 comparably to how a MS user uses WinXX, i.e. it's my only OS 99% of the time, and since it HAS been my only OS 99% of the time ever since I switched to Linux from Win several years ago, understandably I have done so much personalizing, customizing, configuring, etc.. that I dread having to start from scratch again when I install Slackware64-stable (or any other OS for that matter).

I have a DVD of Bluewhite64-12.0 that I got because I wanted to see what if any differences I would see if I were running some sort of 64bit OS on my Core-2 E2160 MSI P6N-SLI machine. I have barely even touched the installation, or even booted it, since I installed it and rebuilt the kernel and played with it on the first day, because as I said, my Slackware 11 installation is my 'darling' and I love it. I tried BW64 because I felt/believed it would be the closest comparison to my Slackware 11 system (and please let's NOT re-start the discussion again about just how close/similar it is!!! Do that elsewhere.).

However, as for what difference(s) if any I detected running BW64 vs Slackware-32?? I don't care what anyone says, or claims, or blogs about on the internet, or what the statistics say; the 64bit OS was generally FASTER, no question. It booted faster, responded faster, the desktop was way snappier, etc..

All that said, I have been using Slackware long enough to know that it's 100% worth paying for, 100% worth supporting, and when Slackware64-stable is released, I will be BUYING the official box package from PV/Slackware.com with the Slackbook and all the trimmings. And if I absolutely must start from mostly-scratch as far as personalizing my system and rebuilding all my out-of-tree packages again for the new system, well then so be it. It will be worth it in the end.

Slackware kicks butt!

PS - I'd love to do some testing of Slackware64-current but it'd be pointless for me to start: My dial-up connection is <28.8k (&^%%^$$%#&^&*) so it takes about 1-2 weeks to download a CD .ISO and using Git, I'd have to clone the tree 24-7 to keep it -current. I'll wait till it's released -stable and BUY IT

Sasha

PPS - I don't/didn't intend to hijack this thread, but maybe I got carried away

I also want you to be absolutely certain, you don't need to start from scratch. I have now upgraded two separate systems live from a running Slackware installation. And while others have complained vociferously, I still prefer the Bluewhite64 ia32-packages over Slamd64's. The reason is as I've stated before, simple security. You can never accidentally overwrite your compatibility layer with 64-bit libraries. Bluewhite64 installs ALL of it's 32-bit libraries into /lib32 and /usr/lib32. They are therefore absolutely segregated.

All that having been said, let's move on to the hard work involved. Actually, there is no hard work involved. And that's been precisely my point all along. Using this link (http://www.linuxquestions.org/questi...57#post3549657) as your starting point, the progress will be effortless. As I've said, make sure you start by installing the Bluewhite64 packages FIRST. They will have no effect on your installed system. In fact, if for any reason you killed your Slackware glibc, you would have Bluewhite64's to fall back on. That is precisely what happens during the upgrade from 32-bit to 64-bit. The installed Slackware glibc is overwritten by the new 64-bit glibc. If you don't have another 32-bit glibc in place to finish the installation, the upgrade would fail.

Now since I know that as soon as this is posted, there will likely be an outpouring of criticism over my endorsement of Bluewhite64 packages, let me make something absolutely clear:
1.) Slackware64 doesn't have it's own 32-bit compatibility layer.
2.) It is being suggested to use the layer from Slamd64 instead.
3.) That amounts to an unofficial endorsement of the prior work of Slamd64.
4.) Contrary to what has been suggested, there is no evidence Slackware64 will ever be multilib. My reasoning is based on the fact that Fred Emmott recompiled his packages using a Slackware64 system for use on the same. That's nice. Except no one has answered whether that situation will continue into the future. And that brings up other points of consideration:
1.) Is Slamd64 going to remain developed and distributed. If so, it begs the question, "why have two 64-bit systems, if both are going to be identical? If they're not going to be identical, Slackware64 is not going to be multilib. Plain and simple as that.
2.) If the Slamd64 compatibility packages are going to continue to be compiled on Slackware64 (because it will not be multilib), why would anyone who wants a native multilib system prefer Slackware64 over Slamd64? If those packages are compiled on Slackware64, they obviously must also work for a native Slamd64 system as well. And since Slamd64 is already a STABLE and RELEASED MULTILIB system, there's no reason not to use it in it's entirety.

And here's another very good reason for having the Bluewhite64 32-bit packages. It would be possible (with some additional steps) to compile the packages required to boot BOTH a 32-bit and 64-bit computer from a single system. This is something that I will be doing in the near future. I will be compiling and packaging all of the applications that normally comprise the 32-bit compatibility layer, into single packages containing the 64-bit packages as well. It's called Biarch. The point is, that you won't need to track separate packages for both systems. Imagine having both (32-bit and 64-bit) versions of Wine in a single package. So all of the packages that Slamd64 (and Bluewhite64) now provides individually and separate from their 64-bit counterparts, would instead be installed simultaneously with the 64-bit packages. I'm working now on creating a tool to move all of the 32-bit libraries over to /lib32 and /usr/lib32.

There really is no reason to complain about doing this with all of the large hard drives currently available to users. Users of removable disk systems, can freely transfer from 32-bit to 64-bit processors and back, as often and as effortlessly as they choose. Being able to boot either architecture without issue could be valuable to a lot of people. It is again for this reason why I personally advocate for the Bluewhite64 filesystem. Of course, anyone can always use the SlackBuilds for the Bluewhite64 compatibility packages (or change the names and directories within the SlackBuilds for Slackware), and compile them on their present Slackware system. In fact, I'll suggest right now that even gcc be compiled using /lib32 and /usr/lib32 while your present Slackware system is in place. They can then be installed and used later as required. Then no one would have any basis of complaint. You can respond by simply saying, "But I am using Slackware packages!"

And we'll find out now whether those people who previously derided me for my comments, have actually blocked my posts or not. However, if anyone else has found my comments useful, please give me a thumbs up. It will likely show how many people are actually agreeing with my preferred method of doing things here.

Shingoshi

I appreciate the input, Shingoshi, but I should clarify something which I may have omitted: I don't necessarily *want* a multilib system; I want a 64bit system!

While I appreciate and take an interest in this upgrade method, and it probably does work just fine when done carefully, I think it could lead to confusion if not for me than for others who try it.
Then again, if it DOES work, it should be a relatively painless but TIME CONSUMING task of removing/replacing all the BW64 stuff in the system, with the Slackware64 stuff; otherwise, I feel that there would be traces of 3 operating systems in here: Slackware-32, Slackware-64, and BW64, which I would like even less!

LOL, lots of angles to look at it from, but ultimately I will be waiting for Slackware64-stable to be released before examining seriously all the options/methods of upgrading my Slack-11 OS to Slack64, if that can ultimately be done cleanly... This might mean I will need DVDs of Slack-12.x as well, so I can incrementally upgrade.. However, I'm not made of money (far from it) and my dial-up connection as mentioned elsewhere is horribly slow, so again, I need to wait and see what I can get from the Slackware store when the time comes, and consider my options.

I really don't feel like mixing a bunch of BW64 stuff into my Slack-11 system and winding up with a spaghetti-distro.

Thanks,

Sasha

The only packages you would have installed from Bluewhite64, would be installed in directories (/lib32 and /usr/lib32) that Slackware(64) doesn't use. So there is no need for concern there at all. Secondly, the package names are all prefaced with ia32-$NAME. So again there's no means for confusion. And even if you don't necessarily want a multilib system, having a package like what I described above for Wine would be really advantageous. Especially for people like you who don't want to run Windows.

Shingoshi

I don't want or 'need' to use Windows, nor do I use WINE, or any VM stuff, or any M$ software at all, so it kinda seems like a moot point, in my case anyhow..

It's all good(ish) if someone DOES think they'll use WINE or some other thing like that, but not for me.

I think I have adequate time to think about it all anyhow, between now and the Slack64 stable release

Sasha

I agree with GrapefruiTgirl, in that I'll wait on SW64 stable before trying it.

I would prefer a "pure" Slackware64 install, instead of SW32, SW64-current, and Slamd64/Whatever else combo.

While I can understand wanting to jump on the 64 bit bandwagon, it's just not worked out yet, thus the '-current' moniker. To me, '-current' is the same as 'beta', and I prefer to have the full-fledged release. So complaining, asking questions about it, or just plain making workarounds, while useful, may NOT be even necessary when Stable is released.

So, to avoid heartburn/frustration/going postal, I'll just wait for Stable.

But TO GET BACK TO THE OP:

A 'biarch' glibc might be a way to go...We'll just have to wait and see...

The wait won't be much longer. Pkgtools-13.0 has just been released.

Although I think maybe the kernel description needs to be changed. Because this can't be true. Unless someone can tell my how many 64-bit cpus are uniprocessors:
Shingoshi

Edit: Well, now that they got the kernel packages recompiled with the correct slack-desc, I guess they'll release aaa_elflibs next.