Linux From ScratchThis Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.
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.
I discovered that if I make the libraries statically linked using --disable-shared in the gcc configure script, it completes the bootstraping, but as the book says, if you go that way, you don't get the lgcc_eh.so (or similar, don't remember now), so there's no logic in my action... just testing, but for now... no results...
maybe the error could be using FC2 64bit, maybe I'll try to make my 64bit pure system using my FC2 32bit as a host and passing the -m64 optimization flag... I'll try it tonight
humm... as my host is FC2, i'll have to find a workaround to solve the problem...
I've been looking the glibc manual pages for compiling and configuring... seems I'll have to put a few more lines to the configure script, but it's strange, as the LFS book doesn't recommend any optimization flags, and the glibc manual does the opposite... it's useful to give optimization flags...
myabe i'll try to make all with cpu optimizations and code level optimizations, along with no backwards kernel compatibility by adding directly the kernel 2.6.9 compare option and disabling profile or modifying what add-ons are put into glibc... maybe this way I'll be able to get rid of the problem...
Originally posted by ParticleHunter humm... as my host is FC2, i'll have to find a workaround to solve the problem...
I can't say this for sure, BUT, FC2 is based off RedHat, and RedHat started the whole RPM movement (doesn't it stand for Redhad Package Manager or something like that?). That means that FC2 should have some sort of package management tool that will allow you to do the same thing I did. packageDrake just works off RPMs, after all.
surely there must be some sort of a static glibc package (not sure, I haven't dived into the DVD), but I don't get the point on doing that...
I mean, you're supposed to compile all the packages by yourself and it's suppposed the host influence on your build, given the fact that you follow the steps of the book (I'm using 'supposedly' up-to-date SVN version with modifications for me to be able to obtain the stablest configuration given the unstable nature of the SVN version ), it's minimal, although not zero, but it's nonsense for me (at least with my current level of understanding on the linux packages) to have my host have static libraries for me to be able to compile a 'brand-new-and-fresh' glibc, it's supposed to be independent, so I don't fully understand your move...
Anyway, as I stated in my previous reply, I'll try to modify glibc settings to eliminate all possible 'hot' points in compilation and being able to have just what I want, as I don't want 32-bit compatibility, just plain 64-bit performance levels, so what I want to do is to... let's say... 'isolate' all chances of making 32bit code, no dependencies, no dynamic code, my intention on this is to compile (after seeing all horrible errors on compiling the 'cute' way) all my system packages statically, at least the basic packages (not having, in example, NSS static, as the glibc manual clearly says if you do so, you defeat the purpose of NSS)
the funny thing in all of this is I'm not completely sure about what I'm talking about, I mean... maybe there isn't the error but it's worth the try... what can I lose on the way? binutils compiles for me in less than 3 minutes (2.34 at my best ) so i have nothing to lose in making my LFS system from scratch time after time, results are what I look for
it *is* possible to build a 64-bit only version of LFS - but it's a pain in the ass.
here's what i did (host system: dual opteron 244/suse 9.1-x86_64)
to solve your GCC problem, pass in the following options to configure:
--without-multilib --disable-multilib
that'll get you past this first hurdle. i would, for good measure, pass them to binutils and glibc as well, although i don't know for sure if either package recognizes them.
during pass 1 of the linux-libc-header install, do this instead of what the book says:
when you do your second pass through GCC, do not apply the specs patch as given; it won't work. edit lines 65, 78, and 79 to point to /tools/lib/ld-linux-x86-64.so.2 - and then apply the patch.
during your second pass through binutils, do this at the end:
make -C ld LIB_PATH=/usr/lib:/lib:/lib64:/usr/lib64
compile everything else in part 1 as you would normally. when you get to the creation of symlinks at the beginning of part 2, replace this:
ln -s /tools/lib/libgcc_s.so{,.1} /usr/lib
with this:
ln -s /tools/lib64/libgcc_s.so{,.1} /usr/lib64
here are some things to keep in mind as you're building the actual system (chapter 6). vim does not compile (at least not on my machine) so i'd suggest using another editor. when building gcc, glibc, and binutils, make sure to pass the flags i gave above. when building anything that installs libraries, put them in /lib64 or /usr/lib64 whenever possible via passing a --libdir option to configure. same thing when the book tells you to move stuff around from /usr/lib to /lib - do it with /usr/lib64 and /lib64.
here's the kicker: GRUB does not compile under a 64-bit environment. my workaround for this was to take the various /boot/grub files from my host system and just copy them over to the LFS part, and then run grub from the host when i was ready to make the LFS bootable.
there are some other problems that i ran into that i don't remember off-hand but none of them were particularly difficult to solve. i only found this forum due to a google for the same problem you're having, so i don't know how often i'll check back here, but if you have problems or questions, post 'em and i'll try to remember to check in.
Originally posted by ParticleHunter hmm... sounds interesting... but, If I use your scripts, although cross-compiling LFS it will run 'natively' when switching to the new system, right?
Yep, it builds all ch5 (with some additions) and cross-builds a target-native toolchain to use for ch6
* MAKE OPTIONS:
make LDFLAGS="-static" CFLAGS="-nostdlib" LANGUAGES="c" 2>&1|tee make.log
did have to hack several times.
* MAKE INSTALL:
make install
all ok.
--
I had to do multiple hacks, this is how i got the compiler done.
THREADS:
When compiling the file "gthr-default.h" gets included by "gthr.h". Unfortunatly there does not exist such a file...
When changing to "gthr-posix.h" it tries to use <pthread.h> something that doesn't exist without glibc...
So I ended up with adding --disable-threads as option to configure. This solved all problems with threads.
SED:
When I was compiling the program gave an error about: " sed -e ;"
Of course this is illegal syntax. Simply the script turned out to forget place " $t " behind it. When trying manually the hole bash command it did work (with changing "sed -e ;" to "sed -e $t ;"). How could I pass this? Fortunatly it has an if elseif construction.
When making symlinks to your bin directory containing your new binutils it will work. So let's do it:
ln -s ${PREFIX}/${TARGET}/bin ${PREFIX}/gcc-build/gcc/binutils
COULD NOT FIND ./nm
Later in the progress i found out that the program nm could not be found. Even when the dir containing nm (and ar and as) was in my PATH. Even when having the symlink in gcc-build/gcc/binutils. This time I had to make another symlink.
ln -s ${PREFIX}/${TARGET}/bin/* ${PREFIX}/gcc-build/gcc/.
Now it was going all ok.
COULD NOT FIND crti.o AND crtn.o
Hmm, my host system had also the crti.o and crtn.o files. Why not simply copy them in my dir? Well that was 32bit code, but what the hack.... Yes, it did proceed. So:
cp /usr/lib/{crti.o,crtn.o} ${PREFIX}/gcc-build/gcc/.
Lets go!
COULD NOT FIND -lc
When running xgcc it was given the option -lc. What? I didnot have a c library sofar. It simply shouldnt pass the option. Since I am no expert on makefile and makescripts I didn't no what to do. Even giving all kinds of options to configure and make didnt work. So lets do:
grep -R -- -lc ${PREFIX}/gcc-build
This gave me a .mk file which contained the -lc option. I simply deleted the entry. It did the trick.. OK nice going.
COULD NOT FIND -lc (2nd time)
Same trick.
THEN WARNINGS:
/mnt/tools/sparc64-tvburger.net-linux-gnu/bin/ld: warning: sparc:v8plus architecture of input file `/mnt/tools/gcc-build/gcc/crti.o' is incompatible with sparc:v9 output
/mnt/tools/sparc64-tvburger.net-linux-gnu/bin/ld: warning: sparc:v8plus architecture of input file `/mnt/tools/gcc-build/gcc/crtn.o' is incompatible with sparc:v9 output
make[2]: Leaving directory `/mnt/tools/gcc-build/gcc'
echo timestamp > stmp-multilib
make[1]: Leaving directory `/mnt/tools/gcc-build/gcc'
DONE..
huh? Yes it was done but with a warning. probably it now within the next day if it really will hold... hmmm..
Any comments on how todo better, are welcome. Did more people have such problems? I really want to do it again but now with the proper crt[in].o files. How to get them?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
odd problem with GCC pass 1... :scratch:
), it's minimal, although not zero, but it's nonsense for me (at least with my current level of understanding on the linux packages) to have my host have static libraries for me to be able to compile a 'brand-new-and-fresh' glibc, it's supposed to be independent, so I don't fully understand your move...
but it's worth the try... what can I lose on the way? binutils compiles for me in less than 3 minutes (2.34 at my best 
