[SOLVED] Compiling Slackware from source. Running multiple slackbuilds in their subdirectory
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.
Compiling Slackware from source. Running multiple slackbuilds in their subdirectory
I'm having trouble running each *.SlackBuild from their corresponding subdirectory. Basically I copied the sources directory from the Slackware DVD (13.1) into the home folder /home/holering/slackware-from-source/source/ . I wan't to run every SlackBuild script starting from the source directory and let the compiling begin all on it's own without me having to cd into each subdirectory (there's actually 2 subdirectory levels) and doing sh ./*.SlackBuild. This is one example I've tried but it didn't work and I'm not experienced much with this yet:
for file in $(find ./ -iname "*.SlackBuild"); do sh ./"${file}"; done;
however I need to cd into the subdirectory/directory containing the *.SlackBuild file first and then | sh ./*.SlackBuild or sh ./"${file}". There are two subdirectory levels
/home/holering/slackware-from-source/source/foldername/packagename/*.SlackBuild
For those of you wondering I've already changed my flags accordingly in each *.SlackBuild. For those of you interested here's what I used
EDIT: Look further at my newer post-example
There are other parts of the slackbuild I'd like to edit if possible so that the package names will come out as | packagename-prescott.txz instead of packagename-i486.txz and the like (noarch, i686 etc). It also seems not good to change the architecture type to prescott from i486 cause then things will seem to get broken.
Last edited by Holering; 08-22-2010 at 05:30 AM.
Reason: inferior example to new post
I suck at scripting, but you might take a look at how the KDE slackbuild works. Essentially it is a single slackbuild, with slackbuilds for all the parts, and an options file to specify some global parameters. Also a note, there was a little invented controversy recently about slackware not neccessarily building completely from the source, since slackware doesn't update every package with each release, some of the slackbuilds might need patching to build. Please do report back on your success. This sounds quite interesting.
The PATH nonsense is only there because /etc/profile likes to throw . at the end of the PATH variable and find doesn't like that with the -execdir option even when command paths are explicit. Of course you could also use a script (XGizzmo's looks like it should work, though quoting may be necessary for directory paths with spaces).
There are system packages that you probably shouldn't build though (or at least don't install) -- glibc, gcc, kernel headers (which doesn't even have a SlackBuild anyway), etc. which would require multiple passes and would have to be done before compiling the rest.
for build_dir in $(find -iname "*.SlackBuild")
do
cd $(dirname $build_dir)
sh ./$(basename $build_dir)
cd -
done
This one worked! Many thanks! To xeelema: when I do it that way I get a *.SlackBuild is not a directory. Many thanks anyways for responding rather than not. Oh yeah and cross compiling is a pain. I borrowed my parents e6550 cpu which is underclocked on my motherboard due to very low multi (I maxed out my fsb stability) but still way faster than my overclocked celeron D 330j @ 3.33ghz!.
To T3Slider: So far on my currently running system I've done | compile-install latest glibc ; compile-install latest binutils ; compile-install gcc compiler (same one on SlackDVD {4.4.4}) ; recompile-install binutils ; recompile-install gcc compiler ; done. This was before using XGizzmo's script.
Took so long for gcc to compile and then doing it over again is atrocious!
So all I did was make a new text file compile-all with the following
#!/bin/bash
for build_dir in $(find -iname "*.SlackBuild")
do
cd $(dirname $build_dir)
sh ./$(basename $build_dir)
cd -
done
made it executable. Dropped it in the "a" folder just to test and it's still going as I type! /tmp folder is filling up with all the packages. So far so good!
Maybe sometime later I can write a simple tutorial on recompiling Slackware from source once I successfully do mine! Thanks much
Edit just in case : I hope nobody uses my first post example of changing FLAGS in all *.SlackBuilds. I ended up with this.
I believe that covers all cpu specific flags in every SlackBuild (at least it better!). If there's a leaner way to do this it'd be good to know one.
'-print' is find's default action, sed can take multiple commands, and regexes can match multiple things (I believe the 'alternative' matching '(foo|bar)' requires a GNU sed with the -r flag or escaped special characters) and that reduces it to this (untested):
'-print' is find's default action, sed can take multiple commands, and regexes can match multiple things (I believe the 'alternative' matching '(foo|bar)' requires a GNU sed with the -r flag or escaped special characters) and that reduces it to this (untested):
-- Oh, and the g flags are likely unnecessary but don't hurt anything.
That looks slick I'll have to try that. So much compiling it's ridiculous! I thought Gentoo was pain but this is the ultimate Beast! It's totally perverse! Talk about total brain meltdown... Once you get a basic slackware installed you're totally on your own as well. I wish I had money for a new lga775 cpu (e5300 is what I want). I'm totally broke though...
That looks slick I'll have to try that. So much compiling it's ridiculous! I thought Gentoo was pain but this is the ultimate Beast! It's totally perverse! Talk about total brain meltdown...
Well, while you're free to rebuild it from source, Slack is actually meant to be a binary distro and most people are extremely happy with its default performance.
Quote:
Originally Posted by Holering
Once you get a basic slackware installed you're totally on your own as well.
Not sure what you mean here. Slack has a helpful community here and on freenode (and the upper 10% of a.o.l.s.). If you mean in terms of adding stuff to Slack, there's SBo (and sbopkg) to make the task of adding most software most people need pretty easy and automatic. But maybe you mean you're "on your own" about something else?
Also a note, there was a little invented controversy recently about slackware not necessarily building completely from the source, since slackware doesn't update every package with each release, some of the slackbuilds might need patching to build.
I remember that discussion. However, I thought that with Slackware 13 being offered for the first time in both 32-bit and 64-bit forms, all of the packages got recompiled.
The 64-bit packages, of course, had to be compiled for the first time, and I thought I read that the 32-bit packages were recompiled at the same time.
I remember that discussion. However, I thought that with Slackware 13 being offered for the first time in both 32-bit and 64-bit forms, all of the packages got recompiled.
The 64-bit packages, of course, had to be compiled for the first time, and I thought I read that the 32-bit packages were recompiled at the same time.
Regards,
That sounds plausible, although I kinda got the impression that there might be more to it than just running the slackbuilds. In any case it's not guaranteed to "just" work.
I remember that discussion. However, I thought that with Slackware 13 being offered for the first time in both 32-bit and 64-bit forms, all of the packages got recompiled.
The 64-bit packages, of course, had to be compiled for the first time, and I thought I read that the 32-bit packages were recompiled at the same time.
Regards,
Correct. Slackware64 has been compiled from scratch (using a barebones CLFS environment containing a 64-bit kernel, gcc, glibc binutils and some other stuff to bootstrap from).
While I was updating SlackBuilds for the 64-bit recompilation, several packages got a version bump. All these version bumps were applied by Pat in the 32-bit Slackware tree, so that by the time we released the first public version of slackware64 there were no version differences between 32-bit and 64-bit anymore.
Now, we are past 13.1 and indeed, several packages have not been recompiled since 13.0 was released. That means you may run into a package which will not cleanly re-compile on Slackware 13.1. It will need patching or a version bump to overcome that problem.
it is encouraging me to try and accomplish the same thing, but with armedslack, since the default armedslack kernel did not work on my neo freerunner (phone with arm4 processor); and if I can get slack on the freerunner, then I will try on nexus one... could I run android in virtualbox? hmm...
Now, we are past 13.1 and indeed, several packages have not been recompiled since 13.0 was released. That means you may run into a package which will not cleanly re-compile on Slackware 13.1. It will need patching or a version bump to overcome that problem.
Eric, thank you very much for the insite! I greatly appreciate how both Pat and yourself continue to churn out a quality distro.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.