|
Quote:
Code:
echo $PATHQuote:
Code:
install -m 755 src/tar $PKG/bin/tar-1.13Quote:
Code:
make headers_install INSTALL_HDR_PATH=$PM_DEST/usrAm I right in assuming your making packages out of everything now? If not, then the above command would have been: Code:
make headers_install INSTALL_HDR_PATH=/usr |
Yep indeed :) making packages out of EVERYTHING :)
The tar situation was indeed weird for a bit. I had it set up the same as my real system, which ahs both, but it didn't work. And I checked the path; it WAS in there, yet it still wouldn't work. I finally installed it from scratch, from within the chroot, using installpkg, and it worked :) but I still have tar-1.16 installed as "tar116' so I can call it when I need it. Correct: Tar 1.13 doesn't like bzips. Also, it isn't necessarily typos on my part; it's muchly a copy & paste process, however, the occasional cp -v command to 'install' stuff to /tmp the way they do in the docs, doesn't create the parent directories, so I had to send just the final part of the destination path to /tmp, then go there and create the parents and put the stuff in order. So while learning how to make the packages (which I had never done manually with 'makepkg' before) I was repeatedly sitting in the wrong folder when making the packages :p but all good now :) All is well so far, but it looks like it'll be a battle with GCC now for some reason. The first run of torture tests didn't produce very good results, so I just rebooted and am starting it again right now.. |
Quote:
Code:
sh glibc.buildQuote:
Quote:
Code:
mkdir -p $PKG/{etc,bin,usr/man/man1}Quote:
Quote:
Oh... I guess it doesn't matter too much but glibc is a wondefull package to optimize at -O3... That's one of the reasons your doing this, no? I'd set your -O2 package in a safe place and go back and rebuild it at -O3 if I were you. But that's just me... ;) But... You've probably already re-adjusted your toolchain so that makes things a little more complicated. A little but not really. |
Once you are compiling stuff with the new compiler and want to make packages you should be able to use src2pkg without any trouble. The package installer currently uses the Slackware installpkg though I have already been looking at the tar-compatibility problems.
The problem revolves around the -l option which has been changed and the --no-overwrite-dirs option which was the standard behaviour before. The -l option has changed so the long syntax is needed --one-file-system. A small change to installpkg should make it work the same with newer tar versions or tar-1.13, something like this: Code:
--- ./installpkg.00 2004-05-30 02:20:34.000000000 +0200Starting with 1.2 we have support for downloading multiple sources associated with a build, even starting the whole thing off from the command-line with a simple 'src2pkg -x URL-address-of-src2pkg-script' I use a very simple GroupBuild script for building groups of packages, whether they depend on each other or not. You can change the behaviour pretty easily depending on what you wanna do: Code:
#!/bin/bashYou'll of course want to compile your src2pkg from scratch since you are building a new system -especially since the new version uses newer installwatch libs. Get the latest package or sources at src2pkg's new home here: http://distro.ibiblio.org/pub/linux/...nload/src2pkg/ |
Gnashley -- thank you very much for that reply above :)
Ummm -- jong357, I need to clarify something here (or gnashley or anyone who's here who knows for sure) regarding making the packages.. I know we have covered this, but something just isn't right here, and I think it's glibc's installation; I have literally thousands of GCC test-suite errors.. Here's a simple example: Let's say I want to make a package which is entirely comprised of one file, in one folder, like so: Code:
/ETCMy $PM_DEST is "/tmp" so after running the install, I end up with /tmp/etc/file.conf. Now, when I run 'makepkg', should I be sitting in /tmp or sitting in /tmp/etc ?? Based on your above post, I figure I should be in /tmp but please clarify. Thanks so much. :) |
Yea, sounds like you need to get ahold of making packages. To answer your question directly, you need to be in /tmp, not /tmp/etc
1.) Don't use /tmp for $PM_DEST. Use /tmp/package-NAMEOFPACKAGE 2.) cd into /tmp/package-NAMEOFPACKAGE 3.) makepkg /tmp/NAMEOFPACKAGE-VERSION-ARCH-BUILDNUMBER.tgz 4.) installpkg /tmp/NAMEOFPACKAGE-VERSION-ARCH-BUILDNUMBER.tgz You need to be in the ROOT of the package before issuing 'makepkg'. Your probably also not making an install/slack-desc file either, right? Not overly important to the sanity of the package but when you install it, you won't see any sort of description... ALWAYS use a seperate CLEAN directory for each package. If you don't (and don't rm -rf on everything in that directory for each package), you'll progressively get larger and larger packages as you go. Before you know it, you'll have a 500mb package that also contains all the previous packages before it. And yes, you've probably borked your glibc package by not packaging it properly. You should have seen some problems with the bottom commands of "Readjust Toolchain" if your new glibc wasn't right. What was the output from those sanity checks? You should have seen this: Code:
[root@jaguar ~] # 1. dynamic linkerNot a big deal. Do a "removepkg" on everything thus far and start over with man-pages. This time try using -O3 on glibc... :-) It also wouldn't hurt to use -march=i686 for everything too... (if that is indeed your processor ARCH) |
OK, as per your above post, I have the package-making part correct as far as I can see.. (Remember I used /tmp as my PM_DEST) I did:
Code:
make install $PM_DEST/some-package-nameBut something's screwed up. The sanity checks returned ALL OK. Everything was found and identified correctly as you wrote above. I don't think I have the compounded-archive problem from not cleaning out the tmp dir each time, because I actually made the package from the contents of the first folder, and not from /tmp, however I can't be sure, so I will remove all the packages and go back to glibc. should work fine this time round, and will be worth making sure. I didn't use -O3 because of everything I have read: while it is actually fine to optimize glibc, the general concensus seems to be that O3 does not necessarily make an installation any faster, but often makes it slower. Perl is done at O3 because that's what the Perl people intended and tested, but since I have done the entire system at "-O2 -march=i686 -mtune=pentium4 -pipe" I figured I'd stay on the safe side since it actually compiled fine; remember, prior to that, it was at -O3 as perthe instructions, but I backed it down to O2 and it compiled. I will do it again though. I want this perfect :) and if O3 works the first time, Ill use it --- if it fails but works at -O2, then I'll go with -O2. And yes -- that's basically the purpose of all this: the CC optimizing, besides the upgrades :) so I have done the -686 optimizing. OK, back in a bit! |
Quote:
Code:
make install DESTDIR=$PM_DEST/some-package-nameAlso, you should just define $PM_DEST as "/tmp/package-PACKAGENAME". So for glibc, it would be: Code:
PM_DEST=/tmp/package-glibcCode:
make install_root=/tmp/package-glibc install -j1Quote:
Quote:
Good luck... Your a trooper, that's for sure. ;) |
A good way to see what the glibc devs intend is to look at the fedora spec file for glibc. Both those guys work for redhat.
http://cvs.fedora.redhat.com/viewcvs...ec?view=markup Quote:
build_CFLAGS="-march=i486 -mtune=generic -g -O3" |
:) here I go again -- fresh! You're right, I had the DESTDIR= either missing or otherwise screwed up. Plus, somehow /libexec got installed to / rather than /usr which is why the entire GCC test-suite took an extra long lunch break -- and never returned :p ; I suspect, it is because I screwed up the package making.
I'll be keeping this thread handy when I get to CHROOT again. RE: Someone asked above if I tried src2pkg yet.. I did, but it didn't work because of the problems I just covered. Have I scripted this yet? No, because I learn more by typing stuff. Pressing GO doesn't teach anyone anything, and besides, with all the sed's and other tweaks and stuff to the makefiles and all, the script, when finally ironed out, would only be good for THIS EXACT COLLECTION of packages. Sure, it might save me a little while during this learning phase, but in the long run, I'd rather have gone thru it by hand, because I pick up new things every run. I will go with -O3 for the glibc again this time, but what ebout "everything" else on the system? What's your opinion of -O3 for stuff in general? I have read quite a bit that claims it is often counterproductive. I have so far done everything on -O2, and will this time too, except glibc, but I'd appreciate you opinion.. OK, here I go. Back soon. |
Quote:
But yea... You've got to nail down the package making thing first off. Otherwise nothing is where it's supposed to be... ;) Quote:
Quote:
Quote:
|
Best thing to use, I think, is what you get when you compile a kernel. For example I get:
Code:
-O2 -fomit-frame-pointer -pipe -march=i686 -mtune=pentium4I strongly recommend against -O3. It breaks SO many programs ... it's just not worth it, IMO. |
|
Good, here's a nice Gentoo wiki on safe cflags:
http://gentoo-wiki.com/Safe_Cflags One more thing you might wanna know (if you don't already). As you know the standard Slackware CFLAGS are: Code:
-O2 -march=i486 -mtune=i686Quote:
So, if you have a high-end pentium and you want it to run on all i686 processors you can do: Code:
-march=i686 -mtune=YOUR_PROCESSOR_GOES HERECode:
-march=YOUR_PROCESSOR_GOES_HERE |
grrrrrrrrrrrrrrr.. gee cee cee shmeee cee cee
okies.. Well, glibc compiled and tested out perfectly, a score of 100% :) and following that, GCC 4.1.2 also built, and this time, passed all tests with flying colors.
Also, I have the package-making part figured out now for sure. However, after building GCC, the next thing is binutils. The ./configure instruction for it craps out, telling me "gcc cannot compile executables." So, prior to making GCC, the sanity checks were all good. ldd --version returns "glibc 2.4" gcc --version returns "gcc 4.1.2" so this is fine. However, here is the docs for installing gcc: Code:
make -k check || :Code:
make -k check || :I tried making & installing this package 4 or 5 times now, both in BETWEEN the MAKE and MKDIR commands, followed by symlinking, and also AFTER doing the make & mkdir & symlinks commands, and still, when I run ./configure, it finds gcc ok, but then stops and tells me gcc cannot make executables. Something's obviously not where it ought to be... Anyway, I have saved ALL 5 GCC packages I have made, so it isn't hard for me to re-package it, if I can figure out what the heck's going on here and correct it. { example of making my packages, for the record: # cd /tmp/gcc412 # makepkg -l y -c n /tmp/gcc-4.1.2-i686-6.tgz # cd .. # installpkg gcc-4.1.2-i686-6.tgz } @ H_TexMeX_H -- :) Looks like I'm basically doing an upgrade and 'some' optimization when compared to the original Slackware CFLAGS (I have a P4) but the sense of accomplishment will be well worth it when I get there :D :confused:-------------------->:confused::confused:-------------------------------------->:confused::confused::confused::confused: EDIT: I'm making the compiler over again. |
| All times are GMT -5. The time now is 07:13 AM. |