Building Binary LFS
I have searched LQ any thread/post relating to what I am inquiring about, but couldn't find. If there're any such thread/post, let me know.
OK, what I am thinking about is building the LFS packages (gcc, glibc, binutils and etc) in binary format (like Slackware's .tgz) and install (untar) it on a partition. Is this possible? |
I would just build the base LFS system and then install
the need programs for .tgz package management.......... this is the easiest way........ |
Yes, you can. I just finished with the 6.0 book using makepkg the whole way through. It's VERY slick. Made a hint of sorts to submit to the LFS hints. The only one they have concerning Slackwares pkgtools is ancient. Needs some final tweaking/formating but for the most part, it's done. I guess I'll post it here for now. As long as you download all the required packages listed below into /sources/pkgtool, you can copy/paste all the commands. I went thru it a few times just to make sure you could copy/paste or make a script from the commands.
Using the latest Slackware pkgtool with LFS 6.0: I got pkgtools up and running imediately after Chapter 6, Populating /dev. I wanted every single package on my system to be documented under the pkgtool list. That means I used the command of "make install DESTDIR=/tmp/packagename" and then did a "makepkg packagename.tgz" and finally an "installpkg packagename.tgz" for every package. Very time consuming but well worth the effort. :-) A few packages won't conform to the DESTDIR switch but can be dealt with one way or another. eg - make install prefix=/tmp/packagename, or as a last result for the 2 or 3 packages that flat out refuse to install elsewhere, edit the make file or do a pre-run with ./configure --prefix=/tmp/test; make; make install. Then do a "make clean" and build/install normally, then hand move everything to a build directory. Make sure everything gets placed where it should be. Like I say, Theres only really 2 packages that do this. Not a big deal really. All these instructions assume that you will be making a pkgtool binary out of the source code below. It's the easiest way to work it right now. And if you want to build another system, you'll have all the work done already with pkgtools. First download all of the following items into /sources/pkgtool. ----------- ftp://ftp.slackware.com/pub/slackwar...ce/a/pkgtools/ explodepkg.8 installpkg.8 makepkg.8 pkgtool.8 removepkg.8 upgradepkg.8 slack-desc _pkgtools.tar.gz dialog-0.9b-20031207.tar.gz dialog.textbox.noarrows.diff.gz ftp://ftp.slackware.com/pub/slackwar.../source/a/tar/ tar-1.13.tar.gz bzip2-tar.diff.gz ----------- What better explanation than the commands themselves? I removed a few things from the package such as xwmconfig and makebootdisk. Code:
mkdir -p /sources/pkgtool-build Code:
sed -i '1,8d' install/doinst.sh "Floppy" "Install packages from floppy disks" \ "Setup" "Choose Slackware installation scripts to run again" \ You can also remove the associated: if [ "$REPLY" = "<REMOVEDOPTION>" ]; then blah blah exit fi parts from the script as well. It won't do any harm leaving it there though. If you want to, you can also change the main title to say something other than "Slackware Package Tool (pkgtool version 10.0)". Since everything is entirely composed of scripts, you can edit to your hearts content with relative ease. I also changed the file "slack-desc" to "desc" as you'll notice later on. Doing that means that you need to do a find/replace in all of the sbin scripts to match. You will also need to edit the very bottom of "installpkg". Where it says "slack-*", put in "desc". There are 2 places where it needs to be changed. I purposefully tried to break compatability as much as possible with the original pkgtools. I also just didn't like the descriptions being named "slack-desc" if they are going to be used on this system.* Code:
cp ../pkgtool/*.8 usr/man/man8/ Code:
cd po Code:
tar -xzvf tar-1.13.tar.gz Code:
tar -xjvf ../mktemp-1.5.tar.bz2 Code:
cd /sources/pkgtool-build If your done with the /sources/{pkgtool,pkgtool-build} directories, you can go ahead and delete them. I use this script right before I run "makepkg" on all my binaries. * Code:
#!/bin/sh ----------- NOTE: For some reason yet unexplained, tar-1.13 was hardcoded to something in my toolchain. Once I removed /tools and tried to use "makepkg", my tar-1.13 binary broke, giving me the pkgtools error of having a tar greater than 1.13, because it could now only use tar-1.14.... I re-did ALL of the above steps except for mktemp after removing the /tools directory and all is well now... :-( The colors for package tools now work as expected too.... I plan on looking into it. 1-28-2005 *Edited mktemp install location* *Added SED command* *Shortened the cp man command* |
I used checkinstall, IMO much easier ( make sure you have either the which script in the BLFS book or the which program itself and mktemp).
|
Yea, I'm not a big fan of checkinstall. I used it for a year or so tho. It always louses up the doinst.sh's symlinks and then corrupts your hostname. Pretty much renders your entire system useless until you reboot. Even when chrooted in LFS, it will affect your host. Pat's checkinstall usually doesn't do that but it did this time around with LFS. Extremely buggy program IMO. I'd rather make em by hand so I know everything is correct. You could try it tho and see if you have any luck with it. It will make the whole process easier for sure as long as it decides it wants to actually work as advertised. Pat even makes mention of it needing quite a bit of work and I tend to agree with him... ;)
|
I used it with LFS 6.0 and it worked pretty well. it did botch some symlinks, making them in the root directory for some reason, but it must have made the correct ones also cause i never had to manually create one. But I agree with you, it may be easier IMO, but a little on the buggy side also.
|
slack pkgtools
Jong, I'm in the process of implementing your pkgtools hint. Just a couple of suggestions:
- Since the editing of "install/doinst.sh" is a necessary change (not just a cosmetic one like the menu options and title) maybe sed instructions would be more appropriate? Same logic could apply to the slack-desc reference I guess. sed -i '1,8d' install/doinst.sh sed -i 's@/usr/share@../share@g' install/doinst.sh - After the mktemp installation into /tools/usr/bin should "export PATH=$PATH:/tools/usr/bin" be added? Unless I've missed something it's not a default path upon entering the chroot in chapter 6. Alternatively sedding the references in the pkgtools scripts to properly reference the location of mktemp? - Regarding the strip script, it refers to /tmp/build for stripping. I've changed it to /tmp/$1 since from what I understand you build each package in a specific directory (ie. /tmp/linux-libc-headers-2.6.8.1-i686). Anyway I'm having fun playing with the pkgtools scripts atm & look forward to seeing your hint on the lfs site, thanks for getting me started. |
Thats a good idea with the sed command. Thanks for bringing it up. I don't know if everyone would want to change their 'slack-desc' to 'desc' tho.... Personally, I don't see why you would want to leave it as slack-desc... ;) I will implement sed in the hint. Thanks again.
As for the install path of our pkgtools mktemp, it should be /tools/bin.... 6.3. Entering the Chroot Environment still has /tools/bin at the very end of our $PATH.... Thanks again. Altho, I had no problems with mktemp being in /tools/usr/bin for sections 6.9 through 6.16... That makes me scratch my head a little. 6.17 is where we install mktemp for good which should render our temporary mktemp binary inactive. If we were to sed a new path into pkgtools, we would have to keep the /tools directory around forever... I don't know about you, but I can't wait to do a rm -rf on that bad boy at the end of Chapter 6...... Unless of course the sed command would just add a secondary location to look for the mktemp. I just wouldn't want any refrences to /tools at all in my pkgtool scripts. You can change the 'strip' script to point to where ever you want for the build location. Actually, I used the same directory for every package. That being /tmp/build.... eg - make install DESTDIR=/tmp/build Obviously, you'll have to rm -rf /tmp/build/* AFTER you build your package and move your new binary some where for safe keeping. You need a fresh build directory for each package (for all the noobs out there :D ) Then I placed the script into /tmp. So then after I built the source code and the binary was ready, I'd just: Code:
cd /tmp Code:
cd /tmp/build I went thru the slackware FTP site and snagged all the "slack-desc" files that I needed. That way you already have those ready. Just rename them to desc (if you go that route) when your ready to place them into your install directory before you build the package. You do have to make a few of them by hand tho. I also edited ALOT of Pat's slack-desc files. It irks me that the descriptions in the parenthesis are cut off in pkgtool. Now when I browse my packages in pkgtool under the 'remove' option, you see the full package name and the full description, however short it may be. ALSO: If your package contains any libs, don't forget to append ( /sbin/ldconfig ) to the end of your doinst.sh... What I did was to issue makepkg, say YES to removing the symlinks, say YES to making an instalation script and then I'd use gedit from my host to add that line really quick. Delete the ~backup and then jump back to my terminal to say NO to changing the permissions. Then it builds the binary. Then your library database gets updated with each package that contains libraries. I don't think Pat does this by default because he has ldconfig set to run at every boot. Thats my guess anyway. I rarely see him running ldconfig in his install scripts. I'll try to finish up the hint and submit it soon. Needs some nice formatting and, as you have pointed out, some tweaking. I also really want to figure out why I had to rebuild and install pkgtools after I removed the /tools directory. I'd really like to know if you run into the same problem with the tar-1.13 binary breaking and the dialogrc file not being read as well. Like I say, I rebuilt the package after removing the /tools directory and pkgtool works like a charm now. That bugs the hell out of me not knowing what happened there. Think I need to figure it out before I submit it to HINTS. |
tar breakage
I encountered the same problem you did with tar breaking upon removal of the tools directory, currently trying again with...
... export LDFLAGS="-static" configure/make/makeinstall stuff unset LDFLAGS ... Might end up breaking something else but when I get to the end of chapter 6 (doing an optimized build atm) I'll edit this post to let you know how it went. Forum posting in lynx is not fun. |
Yea, you may be on to something there. Obviously, isn't finding any shared libs. If we configured for /usr, I'm not sure why it's trying to look in /tools anyway.... Thanks for taking an interest. I kind of put it on the back burner and have been tweaking out my bootscripts and installing packages from BLFS the past week. I'm at a good stopping point, and I still have my toolchain tarballed. I'll mess with it some as well.
Allthough, 6.12 is where we readjust our toolchain to point to /lib, /usr/lib and we built pkgtools in 6.8..... Maybe you should try building pkgtools after your done with 6.12... Install 6.9 thru 6.11 as per the book but keep the source around so you can still make and install the binaries after 6.12.... Don't know. I just think I'm too far along to try and help you out on this one... I don't see how I can revert back to that state completely without starting over.... Don't think I have the patience for that.... You shouldn't have to wait till the end of Chapter 6. I assume you just did a 'mv /tools /blah' to see if tar would break or not? That might be the best way to do it right now if you want to track the problem down. Otherwise, you might be too far downstream like myself... Just thinking out loud... |
Well, I think I've wrapped this up as much as I'm going to for now. I'll figure out the broken tar/dialogrc problem next time around. Here's my completed hint. I just went ahead and wrote it in script fashion. My old one was basically a script anyway...
Code:
#!/bin/sh |
All times are GMT -5. The time now is 12:21 PM. |