Worsel:

1: maybe could you try these new files included: just put them in an empty $LFS directory and execute: ./sfsinit.sh (it should be compatible with x86_64, to be tested)
2: no patch needed
3: didn't hit "^C" to complete the boot
4: no more errors with ifconfig.

Nota:
The sfsinit contains also the patches.
No more ch6prep: included in sfsbuild1.sh
You may have soon two options: slackware and dlackware (not complete for the time being)

new update.
Should be compatible with slackware and dlackware.
Should build on x86 and x86_64.

Nobodino,

I just tried your new scripts. Sfsbuild1.sh quits when it tries to build jadetex.
The following error message appears:

It's too late to try again tonight, but in the two previous versions, applying the
"jadetexbuild.patch" allowed it to continue. I still don't understand why you are
not having the same problem, but that's life. . . .

Worsel

could you provide the patch for jadetex, I could include it in case x86_64?

tetex is a two pass building,
insert : "source /etc/profile/tetex.sh" just before ". $CWD/jadetex.build" in the tetex.SlackBuild

Slackware from Scratch and X11
 

Thought I had already sent a copy, but can't find it. So much for my memory. . .:cry:
The patch is attached.

Redownload sfsbuild1.txt there was a bug in.

Haven't you tried modifying tetex.SlackBuild as I suggested (add 'source /etc/profile.d/tetex.sh' before the line '$CWD/jadetex.build ? tetex builds in two pass.

Okay, I'll try again. Here it is.

No, I haven't tried that. The patch worked, so I just used it. Will look into your suggestion.

Worsel:
ok, your patch works, my suggestion doesn't. I just this morning in a x86_64 slackware system.

Nobodino,

I had some problems with booting the kernel after building with your scripts.
The problem seemed to be resolved when I patched sfsinit.sh.

The attached patchfile shows what I did. Look at lines 317 through 367.

Carrying on further, I attempted to build X.

Problem 1: The documentation is missing from the source. I scanned the ChangeLogs but
found no mention of this. Is it really gone, Pat, or is it mishap?

Problem 2: The patch, llvmSB.patch did not take and I built 1 1/2 llvm's before I noticed
the second one was being built with gcc also. It's after midnight here so I will look into
it tomorrow or tuesday.

Advice for the day: Do not, repeat Do not start tarring a large directory while building llvm :)

Nobodino,

Disregard the patch for sfsinit.sh that I sent on 4-30. I was, apparently, not careful enough when
cleaning up after trouble-shooting and got an erroneous result.

The reasons it wouldn't boot was because "make oldconfig" went through without a hitch, instead of asking
if I wanted various things. This meant that the local version value was "" instead of "-smp". The kernel
couldn't find the modules. :(

Lines 35-42 in the attached file are what I did to correct it. Don't know why the configure process didn't
work right the first time, but the configure files are different for 32 and 64 bit.

Worsel

Worsel:

could you test these new versions:
- change $LFS to $SFS as in your scripts
- just adapt to your $PATH
- remove all personal settings
- created the kernel.SlackBuild64 for x86_64
- builds cleanly on x86
- nota : 2 tools directories : tools and tools_64

nota2: I'll adapt sfsinit.sh with your new patch for kernel.SlackBuild, and see if works ok.

Nobodino,

Have you been having any trouble with autoconf, automake, m4, and libtool?

When I finish your previous script, these still refer to /tools/bin, which has been
deleted. When I recompile them, they work properly. I have been unable to
find a reason for this behavior. It could be in your script or in the ch5 build,
or something off in my computer. That really narrows it down :confused:

Worsel

make a short build list which stops after gettext building, and build "at hand" the first culprit "libtool" and compare its building with the script with only libtool, and progress until you find or not the culprit?

this time this kernel.SlackBuild works on both environment x86 and x86_64 (just tested this morning), and even in non chroot environment:test it outside $SFS to see the result.

Nobodino,

Your latest sfsinit.sh and sfsbuild1.sh seem to work as advertised. I didn't try the
dlackware part. Except for the problem outlined below, everything seemed to be ok.

Still having trouble with autoconf, etc. Most of the ones giving me trouble (perhaps all of them)
are scripts. Instead of the first line in the script being "#! /bin/whatever" it is "#! /tools/bin/whatever".
Doesn't matter if it's a perl, python, or sh script.

It doesn't show up until I try to compile X. The only way I can cure it is to run sfsbuild1.sh, the rebuild the
offending packages.

Guess I'll work on it tomorrow. It's almost midnight here and I need my beauty sleep.

Worsel

Nobodino,

I did notice one thing on your scripts. The kernel build place the modules in /lib/modules but also
puts a duplicate directory in /lib. I couldn't see where your script was the cause, so maybe the
problem is in the SlackBuild.

I've narrowed down my problem. Don't know why yet, but I know what is affected. The following packages
are built with "/lib/tools/bin/whatever" built in:

I can cure them by deleting the tools directory and recompiling the packages
in the order shown. Since we're using nearly identical scripts, (My last build
was with your latest using slackware-current dated 2016-05-05), I'm curious as
to why you aren't having the same problem. By the way, it doesn't show up
until one tries to build X.

Worsel

Could you test the building of x86_64 with this build1_s.list.

If your LFS is too new (gzip >1.6, makepkg doesn't like very much: weird messages, same thing for findutils if >4.4.2).

To build a x86_64 system, I had to modify slightly the order of packages, and to build twice some packages to be able to boot.
Concerning the kernel, I've not solved the problem for the time being, but I've two ideas to solve it.

Your latest build1_s.list built ok, or, maybe better stated, ran to completion.

Actually, glibc built this time without "/tools/bin/" imbedded in xtrace, but
now find (from findutils) and binutils had to be recompiled at the beginning of
the list from my last sending.

I haven't tried compiling X yet. Will try it tomorrow.

Was able to build X all the way through xfce in Nobodino's lists.
The base system was built by Nobodino's sfsbuild1.sh on a 64 bit system.
The sources where slackware64-current, synced 20160505.

Some problems encountered:

1. Had to move xtrans up before xpby and libFS in the build list

2. libva-intel-driver needs "--without-wayland" added to the configure
parameters. Haven't made a patch for this yet.

3. p2c was not changed to p2c-1.22 in Nobodino's script.

4. Tix failed to build. Complained it couldn't find /usr/include/tclInt.h
which was there in plain sight.

5. The rcsSB patch failed to apply, even though it was in Nobodino's script.
Haven't looked into this one yet.

6. A full gcc build (ada, c, c++, fortran, go, java, lto, objc) failed.
The #@$%& thing worked last time I tried it.

Anyway, both blackbox and xfce seemed to work normally. Going to take a
few days off of this now. Got things to do. You know : balance the checkbook,
play with the grandkids, woo the girlfriend, etc.

a new update to the scripts for building "slackware from scratch", the four configurations have been tested on x86/x86_64 with slackware/dlackware, they build and boot correctly.
The kernels are now real packages.
Everything about kernels (headers, modules and kernel) has been moved from sfsinit.sh to sfsbuild1.sh, it's cleaner.
Worsel: concerning the rcs patch, a typo changed the "rcs" in "rsc", that's why it didn't work I looked forward a long time before I found it.

Now I can go on for the second part, build x11/xfce...

sfsinit updated with the patch for libva-intel-driver.

by changing the destination of "others" directory, it got wiped before being used.
This version has the new patch, and "others" is usable for building x11.

Worsel: one step forward

Your problems 1/, 2/, 4/ and 5/ should be solved with this.
It builds up to blackbox with the build2_s.list. Only tested on x86 and slackware, not for dlackware.
Don't forget to exit chroot environment and run ./chroot1.sh to have plain $PATH before building x11.

You can delete /tools directory before building X11, it' not necessary anymore.

error: in chroot1.sh: change the first line to '#!/bin/sh' and not '#!/bin.sh' :)

new updates:
- builds up to xfce on slackware and dlackware and both architectures x86 and x86_64.

To be tested by someone else.

the build3_s.list and build3_d.list are not the latest working ones (several errors)
Replace with the enclosed ones.

Nobodino,

You might want to check the last entry to the attached diff file.
I haven't actually tested it yet. Haven't had enough time. Will get
to it in a day or three.

Also attached is the latest version of the LFS ch5 build for Slackware.
Eliminated the programs "dejagnu" and "check". It seems to work here.

Nobodino,

Question: Are the pre_elflibs and post_elflib routines in sfsbuild1.sh necessary
for building on x86_64? I can't seem to find any reference to them in the source
files, but admit I may have missed something.

If they are needed, then the packages in /home need to be different:
installpkg cxxlibs-6.0.18-x86_64-1.txz vs installpkg cxxlibs-6.0.18-i486-1.txz, etc.

Keep up the good work,

Worsel

you're right, I forgot to manage the case of x86_64 for pre_elf and post_elf.
For the time being, I'm trying to solve the new dep. for ghostscript which are not stabilized.

A new update:
- pre_elflibs and post_elflibs are ok for x86_64 now
- gcc can now be built completely
- builds without any hiccup.

Nobodino,

In sfsbuild1.sh, under "# BUILD package treatment", shouldn't the xfce entry be
"cd /slacksrc/$SRCDIR/$PACKNAME && chmod +x xfce-build-all.sh && ./xfce-build-all.sh" instead of
"cd /slacksrc/$SRCDIR/$DIRNAME && chmod +x xfce-build-all.sh && ./xfce-build-all.sh"?

Haven't run it that far yet. It builds build1_s.list stuff just fine, except I still have the
problem of "/tools/bin/{perl,sh,bash}" being hard coded into some of the programs, forcing me to
recompile them after deleting the tools directory. Well, I'll find the answer eventually.

for xfce: $PACKNAME=$DIRNAME

for the rest? No answer for now:
- could you describe what's wrong exactly?
- which programs are involved?

Ran the latest sfsinit.sh and sfsbuild1.sh.

Added a new gcc.SlackBuild. A patch to create it is attached. It differs from the old
SlackBuild in that it is complete in itself. Give it an argument and it only compiles
c, c++, and fortran. Run without an argument and it tries to compile everything.

Aside from my usual problems (see next reply), the following things went wrong:

1) The llvm patch seems wrong. It leaves us compiling llvm with gcc twice, instead of
compiling with clang the second time. Attached is a copy of the original patch.

2) Xfce looks for the build script in xfce/xfce. Removed the extra xfce.

A patch for these is attached.

The problems I've been having are mostly related to references to /tools/bin are
hardcoded into the files after build1_s.list is run.

In addition, on the last build, find would not work. No matter what I looked for
it returned "File not found." When I recompiled it I also had to recompile bash,
can't remember why. Memo to self: Keep better notes.

After the compile, if I go to /usr/bin and 'grep "tools/bin", this is what I get:

These can be corrected by recompiling the following programs:
Since you don't seem to be having this problem, I assume it is coming from
the ch5 build, but I can't seem to find anything wrong there.

Any ideas would be appreciated.

The messages with grep "tools/bin *" are the same here. I'll look into it.
Don't bother with chapter 5.

1/ llvm builds fine , on the second pass, it's "build1" which is used (so llvm.SlackBuild.old)

Here is something solving your problems with (grep 'tools/bin' *) not empty.
Not the smartest manner, but it works.
The remaining message should go with the gcc-all build.

I'll keep looking for a more elegant solution.
However, it is possible there is none.

Just finished running sfsbuild1_s.list. Everything
looks good right now.

Thanks.

gcc_build and gcc_build64 have to be modified due to your new gccSB.patch.
See the enclosed file.

Okay, just finished building xfce using the latest sfsbuild1.sh & sfsinit.sh

Had to rebuild findutils and bash again. Findutils to continue after build1_s.list,
because it gave error messages instead of finding files. Bash worked all the way
until building gcc-all, then the program couldn't find gnat.

Must apologize again. The last gcc.SlackBuild patch I sent was the wrong one. The correct one
is attached, along with diff files for sfsbuild1 & sfsinit. As usual, ignore pathnames.

I am following this thread with a lot of interest.
I read through most scripts and I wonder why some packages are installed/build. It seems to me a few are not needed.
Some examples: rpm and rp2tgz might be usefull but I don't think these are needed to build other packages.
bin (probably needed)
help2man (probably for docs/man)
slacktrack (needed for linuxdoc-tools which is needed for docs)
tetex and tetex-doc and ed (probably to build some docs)
mc and thus slang/slang1 (I do not need mc)
some internationalization and libs like dmapi, libidn
mm
svgalib
lvm2 for a desktop install?
ncftp and lftp
dhcp and dhcpcd

Probably a few more and they could probably be removed if you do not install all docs and thus edit a lot of slackbuilds.
libpthread-stubs can be removed if you add a sed to some configure files.

ap: linuxdoc-tools: need slacktrack, itstool, unzip, libxml2, libxslt, python, tetex, rpm2tgz, rpm, diffutils, cpio, intltool

If one of these packages is missing, linudoc-tools won't build.
I made the lists by compiling by hand each package, searching for the dependancies by trying and trying again until I had something working.
The initial aim of this was to build Slackware from scratch with the minimum modifications to the slackbuilds, unless circular dependancy or bugs.
It's possible to build a "working system" by pass-passing a lot of docs by modifying the slackbuilds, that's what I'd done first, but I didn't like that way of working.
So it's why it is as it is now.

Thanks, very clear! Using stock slackbuild feels better.
What about dhcp AND dhcpcd, lftp AND ncftp?

Have you tested the obscure X packages like lndir, ggcmakedep, ... none are listed in BLFS for example.
BLFS removes the libpthreadstubs dependency and what other packages need llvm apart from mesa (and that is optional).

read the memo enclosed. You will better understand how it was built.
At the very beginning (two years from now), everything was built at hand, one package after one, until I got something close an equivalent "LFS" able to build everything, and able to access internet (the reason for the last packages).
Then I tried to automatize it with the help of JEG, until you see as it is now

I've managed to shrink drastically the first part of sfs building, the functionality is not the same: 67 packages instead of more than 180.
It can boot, but need 'tools' to go on building sfs.
Hendrickxm: you can test it with build0_s.list instead of build1_s.list and patch kmod.SlackBuild with what is enclosed in the new memo.

Thanks, excellent documentation. Your work is greatly appreciated.

Slackware from Scratch 14.1
 

As an experiment I am trying to recompile slackware 14.1 instead.
Using a very minimal chroot I tried to rebuild almost all packages, excluding specific/exotic stuff and the toolchain.
Why is this useful? Not really sure, but I was intrigued with stripslack and LFS. So the idea was to have a LFS-like system, capable of recompiling itself. My goal is to have a very minimal slackware-based system. Using unmodified slackbuilds where possible. So this is the list:
The packages I did not compile:
I added openssl-solibs and wget to be able to download some stuff inside my chroot.
I was able to compile openssl and wget as well. Openssl needed a modified patch from BLFS.
Some other stuff I tried to add and succeeded:
Sysvinit-scripts and functions I am not gonna try to compile.

The next step is trying to build X and a bootable system, all will still be done inside the chroot.

It would be interesting to see if I can rebuild all these packages with the slackware-current toolchain, but I am in no hurry.

Kept on building after gcc-all, using the attached build7.list.

Ran into some problems:

> efibootmgr would not compile
> elilo would not compile -- needs efibootmgr.
> mkinitrd would not compile -- error: busybox_unstripped failed
> reiserfs progs did not build.
> ispell failed to build
> libmad failed to build.
> madplay, normalize did not build -- reason: need libmad
> mpg123 build failed -- reason: missing audio modules

I'm still working on the first four, but have attached patches for
libmad and mpg123. Would appreciate any patches for the first four.

I'll uncomment the failed items in the list when I find solutions.
gvim is not a problem. The build script I'm using builds both vim
and gvim when it encounters vim.

isapnptools is not used on x86_64.

Slackware-current from binaries rebuild
 

I tried to install a small chroot with slackware-current binaries that could compile itself.
Here is what I came up with:
I did rebuild a few packages to remove a few linked libraries.
glibc was linked against libpng and something else
e2fsprogs against fuse
grep against pcre
perl is built with only XML-Parser
gettext-tools and pkg-config was linked with glib2
groff was linked against Xorg-libs
util-linux against eudev and python
wget with libidn

I would love to remove links against libsigsegv, gc, libffi, libunistring, libtermcap. Most of all removing guile would be awesome, what a slow build.
There is no eudev, sysV, kbd, kmod, bc, kernel, so booting is not possible. But I thought it would be nice to see if a small chroot could rebuild itself. Basically it is a LFS ch6 without bootstuff and extras needed to rebuild itself using mostly slackware buildscripts.
I did not rebuild gcc-*, binutils, bin, etc, devs, libtool, zlib, kernel-headers, linuxdoc-tools, aaa-*, mpfr, mpc, gmp, pkgtools because either part of toolchain, slackware related or too exotic.
packages with s0 are rebuilds with possibly modded buildscript.

I wanted to stay with 14.1 but my touchscreen/touchpad does not work on my laptop on 14.1 and current does.

EDIT: I managed to remove the guile and gc dependencies by going back to make-4.0. I also removed libunistring by compiling gettext-tools with --with-included-libunistring.
I am using cruxports4slack to build a few specific packages with Pkgfiles from Nutyx/LFS. Kbd with the slackware buildscript fails because of exotic translations.
Gperf, eudev --disable-introspection, sysV, sysklogd, man, man-pages, binutils, libtool (through specific buildscript so no need for help2man), kbd (specific buildscript), binutils, zlib, gmp, mpfr, mpc, they all compile. I will rebuild further and try to trim it down some more. A lot of stuff has been added compared to 14.1.

new version:
- introduced a bare version with build0_s.list (no need of 'tools' to go on, but no internet): self sufficient to build slackware (81 packages to build)
- introduced build4_s.list to build almost everything except kde: some packages resist (qt-gstreamer, akonadi, gv,..)
- solved the problem for: efibootmgr (add efivar 0.23+patch and bump version 0.12), reiserfprogs (bump version 3.6.25), isapnptools (bump version 1.27), ispell (bump version 3.4..00), mkinitrd, libmad (patch), madplay, mpg123...
- add a lot of patches to build broken packages
- no more weird message when : grep 'tools/bin' * in /usr/bin, even with build0_s.list

That's all folks!

Nobodino,

Sorry to take so long, but I've been busy. Just finished testing your last scripts.
Initial build with build1_s.list went fine, except "bin/tools" showed up in bison
and flex binaries. Rebuilt them and everything appears to be fine.

Keep up the good work!

Worsel aka J. E. Garrott Sr