If I were to recompile & arch-optimize Slackware, where to begin?
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.
Yea, that can be confusing with the symlinking, but it works. Just a different way of doing it.
Look at my build script. That will make more sense to you. Either way, our doinst.sh file will translate it correctly (atleast it should) so that when the package it installed, the links aren't broken. I prefer to symlink relatively rather than absolute. So I cd into my package and step back directories for my symlink command, if you know what I mean...
Really, if you have questions like this, it wouldn't hurt to check my base directory. That's the main reason I have all that stuff there. Not really to use, but for reference.
By the way, your package making looks good.. Once you get past binutils, things will REALLY start to fly, so take heart..
When I was recemtly doing a recompile from scratch I was doing it on a running system and cannibalizing the existing stuff and also making packages to install to another partition. I found that the doinst.sh scripts would not properly create the links installing glibc using the ROOT variable from a running system.
The glibc doinst.sh scripts contain some logic that, in effect, figures out whether it is being run on a running system, or being installed by the package installer in the installation initrd.
My impression is that you may have the same sort of problems installing glibc in the chroot environment.
Here's how I fixed the scripts so they do the right thing if you are installing to another partition using installpkg from a running system, which also still works for updating running systems or using the installer:
Code:
# Install linuxthreads glibc libraries:
if [ -x /sbin/ldconfig -a -d /lib/incoming ]; then # swap on the fly
# First create copies of the incoming libraries:
( cd /lib/incoming
for file in * ; do
if [ ! -r ../${file}.incoming ]; then
cp -a $file ../${file}.incoming
fi
done
)
# Then switch to them all at once:
/sbin/ldconfig -l /lib/*.incoming 2> /dev/null
# Finally, rename them and clean up:
( cd /lib
for file in *.incoming ; do
rm -f `basename $file .incoming`
cp -a $file `basename $file .incoming`
/sbin/ldconfig -l `basename $file .incoming`
rm -f $file
done
##### remove incoming here -gilberts change
rm -rf incoming
)
else # no /lib/incoming in /? Then just copy the files into lib (and make links below):
( cd lib/incoming
for file in * ; do
cp -a $file ..
done
)
fi
##### Instead of here -gilbert
# rm -rf lib/incoming
# Done installing linuxthreads glibc libraries.
##### then later this:
# instead of checking for /sbin/ldconfig again
# check for incoming using a *relative* path
# if [ ! -x /sbin/ldconfig ]; then
if [ -d lib/incoming ]; then
# linuxthreads:
( cd lib ; rm -rf libnss_nis.so.2 )
( cd lib ; ln -sf libnss_nis-2.3.6.so libnss_nis.so.2 )
( cd lib ; rm -rf libm.so.6 )
Yea, normally that's how you have to do it. But using DIY,@diybuilders, were still using the glibc in /temptools at this point. So you can screw with /lib all you want with regards to new glibc files and nothing breaks. /lib IS efectively our /lib/incoming directory. Once you readjust the toolchain and start using the newly installed glibc in /lib and /usr/lib then you would have to imploy those methods to 'redo' glibc...
Typically, I don't mess with upgrading glibc on a running machine (thats why I don't use doinst.sh trickery). Kernel-headers and glibc are 2 packages that stay the same for the entire life of my system. If I wan't to upgrade, I'll build a new toolchain and do everything all over again from the ground up. Just how I prefer to do it. I usually leave binutils alone as well... My package base consists of just over 300 packages so, That's a pretty big commitment. About every year to a year and a half is when I rebuild. In this case I'm waiting on stable gcc-4.3 so I can use -march=core2...
I might just bump up one version to glibc-2.5 and hopefully a new FSF binutils will be out by then. Going bleeding edge all the way is a pretty bad idea IMO. Look at glibc-2.6... Lots of other packages right now need modification to work with it. Best to let those developers play catch up instead of me doing it for them...
FIrstly: Gilbert, I'm curious about your last post about the doinst.sh scripts not working properly. Would that explain why it seems that for no discernable reason, the following occurs:
1 - According do DIY, I build, package & install glibc.
2 - Next, build GCC (which works perfectly btw)
3 - 'make -k check' on the newly compiled GCC -- FAILS COMPLETELY!
On other occasions, I have followed the exact same steps, and the GCC 'make -k check' passes 100%.
Thing has been, to date I haven't gotten very far beyond making the new binutils in chroot before I really bork something and have inevitably started over, and repeatedly, I get varying results at this stage of the new gcc when 'making -k check' and it's baffling me.
I don't quite understand what your patch above fixes; could you kindly explain what the problem was, and how it is fixed??
I can't understand why, when glibc compiled and tested perfectly, and the linker tests and other sanity checks are all perfect, pointing to the new glibc/ldd/start etc, and then the new gcc compiles perfectly on top of it all, why then does the gcc 'make -k check' just scroll a million FAIL: messages down the screen till I stop it?
(I did compare the freshly installed kernel headers and their location, against my real system, and it appears pretty much the same, and it is the same kernel too..)
So, the last few days, I have been scripting all this, and have now a series of scripts and files from the starting point, up to this point right here, all working quite well. So have been busy but wanted to pop in and say "hey I'm still at it!" and also remind everyone to BACKUP EVERYTHING REGULARLY!!!!!
LOL, at 0900 this morning I fell victim to an errant "for i in /; do rm -fvr ${i}/*; done" and needless to say I was about to freak out --- It wiped my ENTIRE new system I am building, in about 2 seconds flat (we're talking about 750 MB here) --- but luckily, at 0700 my daily automatic system backup had occurred, so I only lost some VERY tiny cosmetic fiddlings I had been doing to my scripts, and about 5 minutes to restore the system. All good
Hey, did you hear me? REGULAR BACKUPS! GOOD FOR YOUR HEALTH!! Whew..
OK, see you'se after -- Jong, how was the camping?
I'm not sure whether you may be having problems having to do with the doinst.sh or not But I thought you might if using anything like the regular slackware doins.sh for glibc when installing under a chroot.
I didn't explain very well. The code I posted is not really a patch for the doinst.sh ,instead it's a snippet from the middle. You need to compare it manually with a standard doinst.sh to see the difference(which may be in more than one spot depending on version)
The point was, the Slackware doinst.sh for glibc only works properly if you are using the installation CD or are upgrading your running system. If you try to install glibc to a mounted installation partition from your regular running system(using ROOT=??) the doinst.sh will create the links in / and not in ROOT. My changes eliminated this problem.
You could check to see if this happening as that might be your problem.
Another hint, though, which might help. Most cross-build methods build binutils before gcc. Jong makes mention of a possible mix-up in the compile order for the first few packages and I think this may be the problem.
A general strategy looks something like this:
1. compile new glibc(1) with your old compiler and old binutils
2. compile new binutils(1) using old compiler, but linking against new glibc
3. compile new compiler(1) using new binutils(1) and old compiler, linking to new glibc(1).
4. recompile binutils(2) with new compiler(1), new binutils(1) and new glibc(1)
5 recompile compiler(2) using binutils(2), new compiler(1) and new glibc(1)
The basic round looks like this:
1. compile new glibc with your old compiler and old binutils
2. compile new binutils(1) using old compiler, but linking against new glibc
3. compile new compiler using new binutils and old compiler, linking to new glibc.
3. recompile binutils with new compiler
Code:
This is the very START of the whole process: Bash comes first ... binutils ... gcc ... glibc ... gcc-2 ... binutils-2 :
3.1. Bash-3.2 Pass 1
3.2. Make-3.81 Pass 1
3.3. Sed-4.1.5 Pass 1
3.4. Binutils Pass 1 (2.16.1 through 2.17.50.0.16)
3.5. GCC Pass 1 (3.4.6 through 4.2.0)
3.6. Linux-Kernel-Headers-2.6.21 (Optional)
3.7. Linux-Libc-Headers-2.6.12.0
3.8. Glibc (2.3.6 through 2.6)
3.9. Adjust Toolchain
3.10. GCC Pass 2 (3.4.6 through 4.2.0)
3.11. Binutils Pass 2 (2.16.1 through 2.17.50.0.16)
3.12. Gawk-3.1.5
[...]
And after a bunch of other stuff, ENTER CHROOT, and :
4.12. Glibc (2.3.6 through 2.6)
4.13. Readjust Toolchain
4.14. GCC (3.4.6 through 4.2.0)
4.15. Binutils (2.16.1 through 2.17.50.0.16)
So the chroot stage goes in the order that Gilbert just posted (the quote) except for there being no binutils pass in between 4.12 and 4.14.
Also, in CHROOT, I am using 'makepkg' to create the packages before installing them, so yes, I would think I AM using the standard doinst.sh generated by makepkg/pkgtool.
An interesting thing I have noticed, is that when I make my packages, I can use Konqueror or Ark to view/extract all/any one of them from my desktop if I want; with the exception of a packaged glibc. the glibc packages I make will explode with explodepkg, but Ark tells me 'invalid archive format' or 'corrupted archive format' or some such thing. The package will install (it seems) but without using pkgtool to explode it, I can't view/extract it.
For clarity, ALL OTHER packages act just like normal.
Something's amiss, but I will explode the glibc package I just made and compare the doinst.sh to the one you posted and get back to you.
Thanks!
Well. As far as 'logic' in the doinst.sh that makepkg put inside my glibc package, there is none. Just a list of Ash(bash?) lines that delete stuff and re-make symlinks of the stuff just deleted. Sort of like 'illogic' rather than 'logic', however... I don't see how I can/could/would apply the doinst.sh piece you posted earlier, to this situation.
Also, I'm not using 'Linux Headers', I'm using 2.6.21 headers.
Friggin weird thing, is ONE out of all the times I went thru this so far, has worked. Every other time, GCC will compile error free, but the make-check run flops completely.
It's scripted now, so I am/can doing the same routine each time.
I can't understand why, when glibc compiled and tested perfectly, and the linker tests and other sanity checks are all perfect, pointing to the new glibc/ldd/start etc, and then the new gcc compiles perfectly on top of it all, why then does the gcc 'make -k check' just scroll a million FAIL: messages down the screen till I stop it?
'-k' means, go on till i stop you ( as opposed to go on until there is an error)
Quote:
It's scripted now, so I am/can doing the same routine each time.
that reminds me of a simpsons epsiode where lisa wants to proof that bart is dumber than a rodent. one test: a tartlet on a buzzer; rodent tries to eat it, gets hurt, runs away. bart tries to eat it, gets buzzed, tries again,gets buzzed, tries again,...and so on. rodent 1: bart 0
Well well, aren't we funny tonight thank you for that.
Yes, I understand the -k option; however, on the one episode when this all WORKED, all sorts of good stuff was coming on the screen (you know, like tests running, etc, that sort of thing)... I'm fully aware of why it's SCROLLING loads of errors (the -k) the question is 'why are the errors HAPPENING', not 'why are they SCROLLING forever'
The fact that it's in script was supposed to indicate that what I'm doing is (supposedly) the same now as I was when it actually worked, NOT indicate that I'm being a silly Bart repeating the same mistakes over and over and wondering "Duh, whyzis hapning!?"
Anyhow, I'd been napping for several hours, till just now, so going for a fresh look..
Try looking for little things in your commands and compare them to DIY... Like making sure you still have a
/tmp/myspecs
file in place... Not sure what's going on actually. Maybe you could post your make check output to pastebin or somewhere so we can have a look see...
Camping was nice by the way.. Very refreshing to wake up to birds and wind blowing thru the trees verses cars honking and an annoying alarm clock... Didn't want to come back...
Anyhoo... There should be some sort of output clue as to why your getting errors... Make sure you redirect and pour thru it line by line. Especially the beginning..
You mean I need to keep that *&^%^& /tmp/myspecs file? Good grief..
Well, I've not been keeping it much beyond --- well,right around where the problems begin; I had been under the impression it was just to get the compiler kick-started for round three, but then, as it happened to be IN /tmp when I started needing the /tmp folder to build stuff, I had removed it.
I already have /tmp, /tmp2, and /tmp3 on the go -- maybe another is in order.
Thanks Jong, again! Will letcha know.
Glad you enjoyed the camping -- though as I live out in the boonies anyhow, it'd be nice for me to go to the city once in a while . I do love the owls, wildlife, relative quiet out here, but I belong in the city.. One day... I'll get back for good..
You mean I need to keep that *&^%^& /tmp/myspecs file? Good grief..
I had a sneaking suspicion... Look at the configure commands for gcc... Hopefully thats all it is... I employ a check for /tmp/myspecs in my gcc build script and assume it's a new chroot build if found...
The gcc we are using to compile the final gcc is obviously from /temptools and it'll use it's spec file with some bogus paths in it. The make will go over fine but without our new adjusted spec from the previous commands, the make check is testing against the wrong stuff... Once you install the final gcc, all paths/specs are correct for your final/core toolchain in /
I'll give you 10/10 for patience and persistence, GrapefruiTgirl. Don't think I could do it (even if I had the ability), think I'd go for a straight LFS.
P.S.
Still got everything crossed for you. Getting REALLY REALLY painful now!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
but wanted to pop in and say "hey I'm still at it!" and also remind everyone to BACKUP EVERYTHING REGULARLY!!!!!
and needless to say I was about to freak out --- It wiped my ENTIRE new system I am building, in about 2 seconds flat (we're talking about 750 MB here) --- but luckily, at 0700 my daily automatic system backup had occurred, so I only lost some VERY tiny cosmetic fiddlings I had been doing to my scripts, and about 5 minutes to restore the system. 
All good 
