How to compile Slackware 10.1 packages for the 64-bit Architecture?
 

Hello,

First of all I am not considering Slamd64. It seems to be buggy and personally I have faced many problems during and after the installation. Some of them:
- Segmentation Fault when trying to install kernel-source
- Unable to mount the second CD after the installer finished package installation from the first CD.
- Unable to install lilo. I had to do it myself using expert mode.
- No sound after install
- lsmod outputs only 3-5 modules which is weird.

Back to main topic, How can I compile Slackware packages for the 64-bit architecture? Currently I have SuSE 9.3 Prof 64-bit and Slackware 10.1.

Re: How to compile Slackware 10.1 packages for the 64-bit Architecture?
 

Good question! I think it would be best to start with a minimal install (just everything to boot and to be able to compile) of a relatively unintrusive distribution, like the Debian AMD64 port. Then install pkgtools, and build the Slack glibc, gcc, etc. and all tools from a/ needed to bootstrap a minimal system. You can then continue with the rest using this minimal system.

Since you are then already compiling on an x86-64 system, it should nog be necessary to add any extra flags to gcc. (maybe you want -fPIC)

Re: Re: How to compile Slackware 10.1 packages for the 64-bit Architecture?
 

Could you give me an advise on what need to be compiled first and in which order? I am not that much familiar with pkgtool and other core packages. I am planning to use SlackBuild scripts to guide me but I am not sure if that is right way to go. BTW, I am going to use SuSE since I have it installed for the 64-bit architecture.

I think it is best to use the order in the Linux From Scratch book as a guideline:

http://www.linuxfromscratch.org/lfs/read.html

Maybe you can even follow that (but be aware of 32-bit specifics) to get a self-hosted system.

Here is what I am going to do now: I will follow the order from the LFS project, use SlackBuild scripts and use the 64-bit gcc from SuSE.
Please correct me if I am wrong.

Hello,

Does it really make a difference if I build the packages in any order?

I was thinking about the order in which packages need to be installed and one thing came to my mind. I am using SuSE as my build environment and SlackBuild scripts to build the packages. Once a package is built, it has no affect on other packages. In fact, SuSE packages are going to affect my installation not the packages I am going to build for slackware.

Please correct me if I am wrong.

Well if you're going to start with a very minimalistic system, you'll probably have to build packages with unsatisfied reqs (libraries missing etc). So to build these you have to make sure you built and installed the required packages first.

I wouldn't compile everything on a full Suse, because I doubt you'll end up with binary compatible packages (they'll be linked against the libs from your Suse, and possibly rely on other Suse specifics).

How can I avoid this? Does that mean I have to prepare an environment similar to LFS?

Any help please

Having had experience with toolchains and building Slackware-64 from scratch (before switching to Slamd64, I might add), I'd like to add some of my own comments and also to address the following issues you had:

This is a known bug on forums.slamd64.com - Fred Emmott knows about it, but can't reproduce it to fix it. I, and others, are still looking into it. The work around is to have your partition table made (using a working Slackware 10.1 CD, for example) before you put the Slamd64 CD in.

I'm not sure about this one, to be honest (I didn't install anything from the second CD in the installer), but if it caused you problems you should be able to mount the CD from command line after you've installed the base packages and simply run installpkg on whatever packages you need.

Did it work after that? I think probably it did.

You should probably run alsaconf and may even have to recompile your kernel to get the correct modules sorted out.

If your system has only found 3-5 modules that relate to your hardware ...

All of these appear to me to be trivial, fixable problems. Building your own distribution (which is what you're suggesting) is not a trivial issue. You cannot merely rerun the slackBuild scripts from within SuSE and expect them to work in a 64-bit version of Slackware, there are other issues involved - not least of which is the toolchain (gcc, glibc, kernel headers and binutils - collectively) and something very different between Slack & SuSE: the startup scripts!

Having tried what you are trying to do, I wish you luck, but I would spend the time trying to help fix Slamd64 bugs than starting again because you found Slamd64 to be "buggy".

- Piete.

piete,

thank you for the time you spent to reply to my post. I wish you could help me with the following:

Could you please give me some guide lines?

Are you saying that I need to partitoin to be compiled before hand.

What happens is that Slamd64 asks me to insert the second cd and click continue. However, no matter how many times I insert the cd it always gives the following error, not exact message:
umount: unable to mount device /dev/hdc

On slackware, I usually run alsamixer and alsactl store as root. but with Slamd64 the sound modules are not installed.

I installed SuSE 9.3 64-bit on the same machine and it has 40+ modules. Samething goes for Slackware.

And that is a great change to learn more about Linux.

What should I do then?

Ok, I can help fixing known bugs and developing a distro as well. Is "buggy" the wrong word to use?

No. On my machines this workaround does not solve any problems. The segmentation faults during the installation are caused by a kernel bug. I have posted the patch for this bug on the Slamd64 forum and at other places. I saw that slamd64-current now uses kernel 2.6.12, so this should be solved in -current.

I still find it quite odd that a kernel bug with a fairly trivial fix is not corrected (because it requires a kernel patch), but on the other hand something very experimental like reiserfs4 is just thrown in. Time will tell, but it remains to be seen whether Slamd64 carries on the tradition of stability of (the official) Slackware Linux.

Ah, thankyou for that clarification, GlowGlow - I'd been under the impression it was some other issue: now I can stop spreading falsities!

I don't think Slamd64 is going to be as stable as Slackware by virtue of the fact it's running on much newer and much more experimental hardware (the x86_64 architecture), which is unfortunate, but the fact it is a working 64-bit Slackware distribution is A Good Thing© in my eyes, and can (and most likely will) serve many others by providing a starting platform to branch Slackware onto the x86_64 architecture. That's not to say it isn't possible to have stability, but the novelty of newstuff hasn't worn off yet, and programmers haven't really spent the time they have with x86 to burn in the x86_64 architecture. In time, it's very possibly that Slamd64 will be as stable on x86_64 as Slackware is on x86 - but that wasn't the question you asked, I realise, and I agree - only time will tell.

To Basel,

I would advise you spend every waking hour reading the LFS manual and learning how Linux is put together. Start by moving around on the same architecture (Debian's PURE64 release might help you there) with a mono-arch system (ie, only runs one type of binaries) and eventually build up to a bi-arch system (like SuSE uses), or if you prefer, stick with the mono-arch methology and go with a chroot environment. to run your x86 binaries. If you don't understand something, whang the phrase in google and see what comes up. Learn learn and learn - but do your homework. I could write out a long winded explanation of what I did, including a step-by-step guide, but you wouldn't learn anything, and you wouldn't understand the steps necessary to get there ...

With regards to your queries:

* You need to use some other boot disks to write your partition table and format your swapspace before trying to install Slamd64. As GlowGlow pointed out, this may not be enough and in this case you will need to put Slamd64 -current on CD and boot from that.
* Is /dev/hdc the same cd drive you booted from? Do you have two CD drives? I suspect you'll find that putting the second disk in your other drive will make it work (magic!).
* I'm at somewhat of a loss with the alsa stuff - all I can think of is you don't have something installed, or configured properly, but everything that springs to mind is stuff that is only possible to configure after an install, and not during. I'd need more information to help you solve this one - so probably best start a user-support thread in the slamd64.com if you want help with this.

Finally, I was merely implying that your own distro is going to have 10,000 times as many bugs in as Slamd64 and starting from scratch isn't going to solve them. Fixing some Slamd64 bugs might be a good starting point to learning more about the system as a whole, too.

I think buggy is the perfect word to use =)

- Piete.

Thanks Piete for your comments and I appreciate the time you spent replying to my inqueries. I have one more question, not related to Slackware, if you can help me.

Does building a Linux distribution require a special environment?

I am plannning to build LFS under Slackware 10.1 on my old machine. I have downloaded LFS 6.1 books and its related packages.

BTW, reading is not a problem for me. Any resources you suggest are most welcomed.

There's nothing out of the ordinary required, environmentally, for building a distro:

You need at least 2 partitions: 1 for your host distro and one for your LFS build.

Basically you start with an existing environment (the host distro), build a self-hosted toolchain (LFS explains in painful detail how to do this), then using the new toolchain, you assemble the start points for your new distro on the second partition. Then you chroot into the new place, run the setup scripts and start compiling the rest of your system from the ground up.

That's the excessively short version, of course.

Just some pieces of advice, I think, in closing:

* Make sure your host gcc, glibc & binutils versions are very similar to the versions in LFS ... see note below.
* Stick to LFS *EXACTLY* - version numbers are very important, especially at the beginning. If you deviate, you will probably need different patches and other messy things. Keep It Simple.
* Learn how to make partition backups (partition image - the program is partimage) and do so fairly regularly, so if you make some mistake and hose either your host or your carefully built LFS partitions you can easily and painlessly restore them.
* Have another PC handy for reference while you're building your LFS system!

Unfortunatly I have no internet at home yet, which means my long list of compilation resources isn't readily available to paste here, still, they were all found by extensive googling and cross linking! Go forth and absorb!

- Piete.

Thanks Piete for your help.