When I tried LFS it was less of a good learning exercise than I thought it would be. The trouble is that the long series of steps required for bootstrapping the compiler, for instance, and getting each step exactly right becomes such a burden that you lack time or energy to read the documentation and source as you go and really understand what you're doing. There's no getting around the fact that a large amount of knowledge and work is latent in a GNU/Linux distribution (I would say larger than one person's mind, but I guess you can point to people who would prove that wrong, maybe). If you want to economize, you must pick your spots, which isn't possible if you have to do everything (hey, why stop at typing the commands, perhaps you'd learn even more if you typed in every line of C). You can fake it with a rote recipe, but the experience is less than optimal, I think. And as you're doing it, what machine are you using day to day? Best to use the machine you're doing your building experiments on to keep yourself honest in the exercise. For that you need the basics (web browser, emacs, X) in place immediately. Better to peal the onion from the outside.


This isn't true is it? I haven't been in the Linux world for awhile until recently installing Slackware, but on BSDs it's routine to have newer versions of gcc than the system compiler, e.g. to deal with C++ code bases that require newer features or whatever. If I'm not mistaken, FreeBSD's packages now have a mix of those compiled with gcc and CLANG/lvwm. Wouldn't most application libraries only interface with glibc at their lowest level, glibc interfacing with the system call layer (kernel interface)? Or even if not, how unstable is Linux's system call ABI? Does it change from version to version and is it in any way compiler dependent? What, you enter the kernel via some kind of interrupt or syscall instruction that jumps you to some offset with the code to run after changing privilege modes and preserving user state. What here would look different to the program compiled with gcc 4.8 vs. kernel compiled with 4.7 here? There's something funny with the kernel headers, IIRC, but how many programs use those?

I wholeheartedly agree. Dogfooding is, imo, a necessary component of any open source project. One of the reasons Linux, GCC, and many others have been so successful is because they are developed by the people who use them.

Though, I wouldn't put too much of a priority on making the X server work, unless it's a core feature of the distribution. One can always run the applications on one computer and run X on another to handle the UI.

Just when I'm thinking Slackware is already all I could ask for, Pat goes and floors me with new additions to "current"...

OpenCOBOL?!?! (Damn, I now wish I hadn't thrown away all those old COBOL programming books)

Tonight I'm going to party like it's 1984!!


(At my age, I don't need to tell prospective employers that my COBOL programming skills are "rusty.")

Thank you very much Pat!

I attended LinuxCon Europe last year and H. Peter Anvin's talk "Don't play dice with random numbers" in particular. One of the recommendations was to have rngd enabled and activated as earlier as possible in the boot process. rngd is currently not shipped with Slackware. Maybe it's worth adding it, but I haven't looked at the details.

I would like to see full multimedia working after install (some of the patents have expired even in US).
Second, in extra I would like to see build scripts for multilib gcc and glibc, and all the tool scripts for making compat32 pkgs.

Multilib is quite easy though, just run this command or set it as an alias as I do in the .bashrc I copy over on a fresh install.
You, of course, would change 'current' to your version. ;-)

I take it that you are blind then?

Eric

This tread is almost 2 years old, 2 versions and 30 pages long.
Some good suggestions have been implemented and new things are being suggested every now and then and as such, this thread is serving its purpose.
Perhaps some maintenance is in order though, as it is becoming hard to go over the posts.
As 14.1 is getting closer and will be ready in the future, perhaps it is time to start making a per version thread, where each such thread starts with a summarized post of what was suggested, and what went into the next (current) version.

I am not blind Eric. I am being responsible.

I am thanking you very much for putting the effort for providing multilib and the compat32 tools.

You provide ONLY the binaries for gcc-multilib and glibc-multilib but when questioned on how you compile them you evade by saying is a long process (which it is btw) and that I can compile the 2 components using the same binaries that none know how you build them. Slackware distribution comes with sources too and with slackbuilds for every software that we run and this makes it much more clean (or honest). I am not saying you are not honest: you need to prove it before I can use multilib in a production environment. I did offered my help but seen no reply.

We have not met, we do not know each other, we know just a nickname (that is very established in the community). A rhetoric question: what if I (an unknown person) would have made available the multilib gcc and libc would have people trusted me?
Nevertheless, I am using your multilib binaries back home where I have nothing to loose.

Alien Bob isn't just a nicknamed person. As far as I know he is part of the core Slackware team.

In fact, Eric was almost single-handedly responsible for the 64-bit version of Slackware. Who could be more qualified than him to handle the multilib stuff?

There's a great interview here: http://www.linux-mag.com/id/7502/

Furthermore, you can find his build scripts here:

http://slackware.com/~alien/multilib/source/

2 members found this post helpful.

He provided slackbuilds in the x86_64 release for all the packages. Why not for this too?


Have you look at least at the date of those slackbuilds or better have you tried to run them?

The one for 14.0 is from July 2012 and the -current one is from April 2013. Seems pretty recent to me. Am I missing something?

ryanpcmcquen it is clear to me that you do not know what I am talking about. I already said what you posted:

Explanation: in order to produce the multilib variant from the original ones multiple intermediate gcc and glibc must be produced. If you do not know how that intermediate was built then, the end product is questionable.

I do not know what your problem is syncBQ. I provide ALL the scripts that I use to create the multilib versions of gcc, glibc and the conversion tools to create the compat32 packages.
If your desire is to build a multilib glibc and gcc from scratch and fail doing so, that is your loss.

Have you ever tried compiling Slackware-current from scratch? I mean, REALLY from scratch. Good luck with it, I did that twice, once for my x86_64 port (which is now Slackware64) and then again for my ARM port. It is possible, but not a trivial business, and I DO NOT offer a recipe for from-scratch builds of Slackware either. Nor does Pat. Does that make hime as dishonest as I am in your eyes?

I build my next multilib packages using the previous package. You can do that too. You can try updating my gcc-static.SlackBuild if that fails to work for you on SLackware-current. I have been there, done that and do not feel the need to keep that script updated for kids like you.

If you are brave enough you install Slackware64 13.0, then bootstrap your first multilib packages on that using the scripts and the README I have available, and then keep upgrading all the way to Slackware-current, recompiling multilib packages as you go along. I have no interest in the outcome, good luck with it.

Eric

5 members found this post helpful.

Interesting .. I've always wondered about the slackware team's development methodology. Thank you for the insight, AlienBob.