RE: Omnibook XE3 combo net device
lauri.kasanen wrote: Hi. Im not sure if this is the right place to ask this, nor if this Nor am I. It's still not clear to me if you are using LFS or only Knoppix! No matter... My laptop has a 56k modem and a 100mbps lan in a combo device, in one mini-pci slot. lspci shows them separately, but there is only one network device, eth0. Yes that's correct, you only have one network interface on the card. The modem is considered to be a serial device, not a network device, so it should normally be accessed via /dev/ttyS0 or something like that. Can I use the modem and LAN at the same time, or only one at a time, or something? Any suggestions please? And instructions too, Im kinda new to linux, I've only used Knoppix for a few months. You should be able to use both devices independently, i.e. the net only, the modem only, or both together. Of course they are set up completely differently. For the modem, you will at least have to configure which phone number to dial and what kind of connection (PPP, SLIP, or simply a terminal access). There are too many possibilities to describe here without knowing exactly what you want to do with the modem (besides, I haven't used a modem in 8 years so I don't remember that well!). I suggest a good starting point for you would be to visit The Linux Documentation Project (tldp.org) and grab yourself a copy of the Serial HOWTO document. Brandon. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Problems installing Expect-5.42.1
Richard Caldwell wrote: Thanks Brandon. That worked, and for some weird reason I didn't have to ad the --with-tcl... line to ./configure as I had previously done. I must have done something incorrectly the first time. Not really weird. If the Tcl stuff (headers, libraries,..) is all installed properly in the correct directories then Expect finds them where it expects to (pun intended) without you having to point it to the Tcl sources. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
RE: Error during the Adjusting Toolchain - section 5.7 of the book
Vladimir Marcu wrote:
a quick question about an error I got when I issued a command from section
5.7 of the book:
mv -v /tools/bin/{ld-new,ld} - when I issued this command I got an error
message saying that ld-new does not exist. I don't remember creating any
ld-new filwe along the way.
See 5.3. Binutils-2.16.1 - Pass 1 (the last 3 commands _after_ make
install)
Installing the new ld at the correct stage of the book is a critical part of
the
process, so don't go further until you get that sorted out.
ANother question is regarding bootstrappig GCC in Pass 1 (section 5.4 of
the book).
My swap file size started to increase a lot - up to twice my RAM amount. I
am
installing LFS from the LFS Live CD on a Toshiba laptop with 64 MB of RAM
and a
Pentium 2 266 MHz proc). AFter about half-an hour of grinding the HDD, it
crashed
saying that it ran out of memory. I ran make bootastrap again and it
finished
(apparently) OK. Should I worry about this affecting the future steps?
make bootstrap is a pretty heavy process. It's quite normal that it
should use a
few hundred MB of swap and take several hours to complete, on that hardware.
As long as the make bootstrap completed successfully the second time and
the
make install went smoothly you should be OK. The 1st pass of GCC is only
used
until the end of section 5.11 when you install a 2nd pass of GCC, so if you
get
beyond that point without further problems then the 1st pass becomes
irrelevant.
Brandon
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
RE: 6.12.1. Installation of GCC (Book: LFS Version 6.2)
knutz wrote: Hi. This is my fourth attempt at an LFS system - I have had one success so far - I applaude your persistence :) In section 6.12.1 - Installation of GCC all goes well. The test-suite shows some errors, but I carry on as it usually does. I start the test for the dynamic linker. All is fine until I do the test for the search paths: Step 15: grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' Desired output: SEARCH_DIR(/usr/i686-pc-linux-gnu/lib) SEARCH_DIR(/usr/local/lib) SEARCH_DIR(/lib) SEARCH_DIR(/usr/lib); What I got: SEARCH_DIR(/tools/i686-pc-linux-gnu/lib) SEARCH_DIR(/usr/lib) SEARCH_DIR(/lib); All other tests showed the desired output. My question is: How far back do I need to go? This looks like the output you should get in 6.10, so most likely you won't need to go back any further than that. I'm no toolchain guru but it looks to me like the gcc you used to compile your dummy.c is not using the new Binutils from ch 6.11. Are you sure that you entered the chroot with the correct command? Check that your PATH is correct (/usr/bin first and /tools/bin last) and that shell hashing is off (output of echo $- must not contain lowercase 'h') Brandon -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
RE: lfs-support Digest, Vol 1088, Issue 1
Vladimir Marcu wrote: Indeed you are right. I discovered this the hard way. I'll start over. That's how we learn :) -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
RE: 6.12.1. Installation of GCC (Book: LFS Version 6.2)
Brandon Peirce wrote: entered the chroot with the correct command? Check that your PATH is correct (/usr/bin first and /tools/bin last) and that shell From ch 6.4: PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin Ok, /usr/bin should be 2nd not 1st, but the point is that the new gcc and binutils in /usr/bin should be found before the one in /tools/bin. You might also like to repeat the test from 6.12 explicitly using /usr/bin/gcc instead of just cc to generate the dummy.log. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
RE: error during the installation of binutils
Vladimir Marcu wrote: I seem to get stuck at the section 5.3.1 of the book, during the make install of binutils. I am trying to build the LFS system using the LFS Live CD as a host. This is the output from make install: [...] mkdir -p -- /tools /tools mkdir: cannot create directory '/tools': Permission denied Did you create the symlink in Chapter 4.2. Creating the $LFS/tools Directory? Try ls -l /tools and you should get something like: lrwxrwxrwx 1 root root 15 Oct 3 19:55 /tools - /mnt/lfs/tools/ If you don't, that's your problem! The way I got around this was to change the configuration command switch --prefix=/tools (as it is specified in the book) to --prefix=$LFS/tools. Bad idea! Like that probably everything will go fine until the end of Ch 5, and then as soon as you enter the chroot in Ch 6, nothing will work anymore because in the chroot your $LFS/tools has become just /tools and $LFS/tools doesn't exist anymore but you will have that path hard-coded into all your programs! Brandon. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
RE: Glibc error
Wojciech Giel wrote: When replying, please edit your Subject line so it is more specific than Re: Contents of lfs-support digest... Please follow that advice. It makes life easier for people to see what the mail is about before they open it :-) From: Brandon Peirce Wojciech Giel wrote: Hi I'm compiling LFS 6.2. I get this result of check test of glibc in 6.9 chapter make[2]: *** [/sources/glibc-build/rt/tst-mqueue5.out] Error 1 Maybe you are lucky and it just timed out. Try grep -A 1 '^Timed out' glibc-check-log If you get two lines of output: Timed out: Killed the child process make[2]: *** [/sources/glibc-build/rt/tst-mqueue5.out] Error 1 then that's the answer. Otherwise, try to check the contents of that tst-mqueue5.out file. It's contents should be the output of the test case. i have two processors 400 Mhz i this box. I compiled glibc once again with MAKEOPTS=-j5 and i only get (ignored) failure in the posix/annexc test which is acceptable it seems as if it was problem with slow processor. sorry for my english. does time out mean slow processor in other words ? :-) Hmmm, a dual processor 400MHz... Compaq AP400 professional worstation maybe? I worked a lot with those in my former company :) The person who writes the test case expects it to finish in a certain time, e.g. 10 seconds. It is made so that if the test is not finished in that time, then it is cancelled (stopped). That is called a time out and the test fails. If you run on a 400MHz box, it is very likely that you will get a few time outs, especially if your box is also busy with something else. However, I think it is not a very good idea to use MAKEOPTS=-j5 for the test suite (although it seems to work ok the first time for you). The Glibc Makefiles use a specific variable PARALLELMFLAGS which is specifically set to -j1 for the testsuite IIRC. You should not cause any damage by running parallel make for the test suite, but it might give unexpected failures or even crash if some commands are executed in a random sequence. For Glibc testsuite, the correct solution is to use TIMEOUTFACTOR. Try something like make TIMEOUTFACTOR=5 check This will make all the time outs 5 times longer, e.g. a test that timed out in 10 seconds before will now be allowed to run for 50 seconds before it is stopped, and probably it will pass after 20 seconds! However, I think your previous (lucky?) result with MAKEOPTS=-j5 shows it is safe to continue. You don't need to rerun the test with TIMEOUTFACTOR unless you are interested. Regards, Brandon -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
RE: Glibc error
Wojciech Giel wrote: Hi I'm compiling LFS 6.2. I get this result of check test of glibc in 6.9 chapter root:/sources/glibc-build# grep Error glibc-check-log make[2]: [/sources/glibc-build/posix/annexc.out] Error 1 (ignored) That one, as you can see, is safe to ignore make[2]: *** [/sources/glibc-build/rt/tst-mqueue5.out] Error 1 Maybe you are lucky and it just timed out. Try grep -A 1 '^Timed out' glibc-check-log If you get two lines of output: Timed out: Killed the child process make[2]: *** [/sources/glibc-build/rt/tst-mqueue5.out] Error 1 then that's the answer. Otherwise, try to check the contents of that tst-mqueue5.out file. It's contents should be the output of the test case. Regards, Brandon -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Bash log file hangs
Peter Ennis wrote: Dan Nicholson dbn.lists at gmail.com writes: Not the answer you're looking for, but a much better general purpose solution is to use screen. It's an awesome terminal multiplexer. ... It works great and the hanging error in bash tests passed. This is a great resource for others reading the list: http://jmcpherson.org/screen.html Screen is full of possibilities that are seldom used. This one is worth a read IMO for some ideas: http://www.jerri.de/blog/archives/2006/05/02/T22_41_44/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
RE: package users: using a config user for post-installationmodification of conf
Angel Tsankov wrote: The package users hint (http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt) says: In case you were wondering if you should create /etc/nsswitch.conf and /etc/ld.so.conf as root or glibc, I recommend to assign all files that you manually create or manually edit to the root account. [...] With regard to the management of configuration files, I suggest that on systems, where the package users system is used: 1) initially, any configuration file be owned by the package user who has installed the package that this configuratino file is part of or used by; 2) a config user (possibly with primary group config) be used to change (either manually or automatically) any configuration file; the rationale behind this proposal is to avoid the possibility that root forgets to change the owner and/or the group of any configuration file that they change; So if I understand correctly, your logic is that the config user doesn't initially have permissions to modify the config file. You are forced to login as root and 'chown config config.file' or 'chgrp config config.file' before you can edit it as config. (And you have to do that instead of remembering to 'chown root:root config.file' and you must still remember not to edit config.file as root.) That way you can't forget. Right? 3) when using the approach proposed above, either the owner or the group of a modified file be changed so that one can tell which package the file is part of (or used by) by looking at the other attribute; Have you tried this approach? It looks like it could work, but is it usable in practice? I mean, does it really provide added benefit that is worth the added complication? -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
RE: Chap 8.4 Problem with GRUB
Ellis Wilson wrote: Almost to my own distro, but ran into a problem on the last page (of course) of instructions trying to make grub setup my hd0. I've got 4 partitions on a 160gb hd, 1 being M$ (unfortunately) 2 being ext3 (LFS), 3 being a storage fat32 partition and 4 being my swap. Now upon trying to root (hd0,1) it says Filesystem type unknown, partition type 0x6 and upon going anyhow and trying setup (hd0) I get Error 17: Cannot mount partition. My host is the LFS LiveCD. All help is appreciated. I have not yet mastered Grub myself, but the error message looks very suspiciously like your LFS partition has the wrong type ID in the partition table. If I interpret that number correctly, type 0x6 is FAT16 whereas an ext3 filesystem should have type 0x83. You can change this using the 't' command in util-linux's fdisk. Brandon -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Precompiled Temporary Toolchains
On Tue, 12 Sep 2006, Dan Nicholson wrote: On 9/12/06, Brandon Peirce [EMAIL PROTECTED] wrote: Dan Nicholson wrote: The advice at the end of Ch. 6 is bogus. Would you care to elaborate? Thx A long standing hammering of /tools done in the toolchain readjustment. When you finish Ch. 5, /tools is well fleshed out and the toolchain is properly set to compile programs that link into /tools/lib, etc. Then you get to the Ch. 6 readjustment and you change the default ld (in /tools) and add a specs file (in /tools) so that compiled programs will link to /lib, etc. in the chroot. This achieves the proper effect as you don't want your final gcc and binutils linking against the temporary system. However, when you get to the end of Ch. 6, it says you can tar up /tools and use it again. Wrong. Sorry, I couldn't find that bogus advice, which is why I asked. Going through the museum, I see it got ripped out the book after 6.0. Now your toolchain in /tools points to /lib and friends. If you move the old ld back in /tools/bin and remove the specs file, all is well. Then you really can unpack /tools and start firing away in Ch. 6 on a blank disk. The way it is now, a tarred up /tools provides nice temporary tools if something is messed up, but it doesn't give you a clean starting point if you were trying to build a pure final system. So end of Ch 5 would be the good place to tar up /tools then, instead of end ch 6, right? The changes in /tools to adjust the toolchain are not really necessary. There are other methods where the changes could be made without affecting anything in /tools (beware of flame wars, though :). See how DIY does the readjustment and subsequent gcc and binutils builds: http://www.diy-linux.org/x86-reference-build/chroot.html#c-readjust-toolchain Well that's not so different from LFS, hardly more than a syntactic difference! As far as I can tell without reading cover-cover, it's still the same pure LFS idea of constructing a temp toolchain in a chroot env, then using it to build the final toolchain and switch over to that to build the rest of the system. They just use a temp specs file instead of modifying the installed one. Is that wording OK to avoid flame wars? :) BTW I'm interested in taking this subject further (not to suggest LFS should do it differently, but to discuss/validate another alternative that I'm developing). Something to better carry across to lfs-chat maybe? Brandon. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Precompiled Temporary Toolchains
Dan Nicholson wrote: The advice at the end of Ch. 6 is bogus. -- Dan -- Would you care to elaborate? Thx -Brandon -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Switching users in a bash script?
Angel Tsankov wrote: exit END FILE Then simply call: echo build-package-name.txt | su What will happen if I do not append an 'exit' at the end of the file? Then it will get stuck I think and you will have to hit C-c to get out of it. No, it does not. I tried with and without 'exit' and I get the same result, at least visually, i.e. I did not chech if some process is left waiting or anything like this. That's not surprising. Non-interactive shell should terminate when it encounters EOF on input stream. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Switching users in a bash script?
Lynx wrote: On 27/08/06 12:19:38, Scott wrote: On Sat, Aug 26, 2006 at 06:11:43PM -0700, veritosproject at gmail.com wrote: Here's how you pipe commands. Throw an exit on the end of that, your root password on the front, giving: START FILE 123456 ./configure --prefix=/usr make make install exit END FILE Then simply call: echo build-package-name.txt | su I tried that before. On my system (Mandrake 10.1) I get: stdin must be tty I don't actually understand why 'echo' is used. I would have expected: cat build-package-name.txt | su or equivalently: su build-package-name.txt On 29/08/06 00:12:00, Brandon Peirce wrote: I have never seen this technique before. But being curious I tried it too and am getting: su: must be run from a terminal Are there different implementations of su out there? I have an LFS 5.1.1 There is an su command in Coreutils and in Shadow. The one from coreutils sucks. Actually, I may be mixing things up there, so let me withdraw that opinion and stick to the facts One _advantage_ of the coreutils version is that is implements a -c switch which the shadow version doesn't. (More about -c later.) However, the shadow version supports PAM which the coreutils version does not (although I saw a mention of a patch). LSB has chosen the shadow version as the standard. I came across this the other day: http://www.freestandards.org/policy/consent.html: --- 1. Util-linux versus Shadow-utils Where there are conflicts between a command implemented by util-linux and shadow-utils, the shadow-utils version should be used. This item moved from Workgroup Policies 16 June 2005. Originally ratified 01/30/2001. --- Or do the mean 'removed' instead of 'moved'? In any case, the debate is far from settled; a sample of distro's shows no consensus: http://www.mail-archive.com/bug-coreutils@gnu.org/msg07573.html http://www.diy-linux.org/pipermail/diy-linux-dev/2005-August/000610.html It seems I have su from shadow-4.0.14. It gives a usage message with --version. Is it really the shadow-su that accepts this pipe input? Hmmm, well I was also curious to try this technique, and now I've finally got round to it. I have both su-shadow and su-coreutils installed on my host with su as a symlink to one of them. Neither of them work as described. su-shadow always gives me the su: must be run from a terminal message, no matter which technique I try. And I've tried from a linux vc as well as an xterm window. su-coreutlils will never take the password from anywhere but the terminal, but thereafter will accept commands from stdin or a file named with -c: cat su_script | su su su_script su -c su_script All 3 above work with su-coreutils (5.2.1) but in a script, it would still stop and prompt you for a password. The way I'm working around it is to run my script as root then that kicks off another script to do the non-root part (as nruser) with: su -c nr_script nruser That works because root can su to any other user without requiring a password. BTW, under the same conditions, i.e as root, the piping technique would work with su-coreutils, as in: cat nr_script | su nruser (without the root password as the 1st line of the script!) I still think the cleaner and correct solution is to use sudo, but I haven't got around to installing that yet (and one would need it installed in one's chroot environment too, presumably). -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
RE: mounting ptoc
dave frost wrote: somehting strange has happened, it seems mount reports proc is mounted about 15 times, theres also loads of entries in /etc/mtab but /proc/mounts reports /proc mounted only a single time. The output of 'mount' without parameters is basically just a formatted dump of what's in /etc/mtab if it exists, so they will show the same thing. /proc/mounts reflects the actual state of the kernel. Any thoughts on why proc is being mounted so many times ? It's should be mounted every time you boot your system! (note ive modified the init scripts but the mount command for proc is being issued only once ) Check your shutdown sequence carefully. Remember that 'umount -a' will unmount all filesystem, _except_ /proc. It will also remount your root filesystem read-only (because it can't really umount it). If you umount /proc after that, the entry will not be cleaned out of /etc/mtab because that is now on a read-only filesystem. Next time you boot, /proc will be mounted again and a new entry added to /etc/mtab, so now you have two. And every time you reboot another will be added Of course, I have not investigated your system so that's just my guess what's happening. It's also possible that that happened during a period while you were testing your modified init scripts and now the problem is solved but the duplicate entries remain in mtab. I suggest you clear out /etc/mtab once, then observe. If you get one more /proc entry each time you reboot, then you still have the problem, otherwise you don't. The safest way to clean out /etc/mtab is just to 'umount /proc' fifteen or so times, ignoring the warnings that it's not mounted, until there are no entries left, then mount it again once. (You'd best drop down to single-user mode, or at least stop services like klogd, if umount complains that proc is busy.) Hope that helps, Brandon. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
RE: init and init scripts
dave frost wrote: Now i thought that the scripts would have to work out what the previous runlevel was (using an exported shell variable) and stop the previous runlevel, but this doesnt seem to be working. It struck me that the shell the init script runs in when entering a runlevel wont be the same shell the init script for the other runlevel runs in so exported variable wont work, make sense ? Could someone clarify how the current lfs init scripts detect the previous runlevel. AFAIK there are at least two techniques available. I think probably about 90% of all GNU/Linux systems use #2. 1) there is a binary called 'runlevel' which you can execute and it will print the previous and current runlevel. 2) when the init process calls the scripts, it defines a couple of environmonent variables like RUNLEVEL and PREVLEVEL which are available to the scripts. See the init(8) man page. Brandon -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
RE: package users: re-adjusting the toolchain
Angel Tsankov wrote: As what user should I re-adjust the toolchain in Ch. 6 of LFS 6.1.1? First, backup the /tools linker, and replace it with... The linker (ld) is part of the binutils package, so the first block of commands (3 mv and 1 ln) should be done as your binutils package user. Next, amend the GCC specs file so that it points to the new dynamic linker, ... The Gcc specs file belongs to GCC, so you run the next block of commands (gcc -dumpspecs | perl) as your gcc package user. The rest of section 6.10 are just checks. They should ideally be run as a normal user without any privileges, i.e. not root and not a package user. Brandon. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: package users: re-adjusting the toolchain
Angel Tsankov wrote: As what user should I re-adjust the toolchain in Ch. 6 of LFS 6.1.1? First, backup the /tools linker, and replace it with... The linker (ld) is part of the binutils package, so the first block of commands (3 mv and 1 ln) should be done as your binutils package user. For LFS 6.1.1 the instructions says Install the adjusted linker by running the following command from within the binutils-build directory: The make -C ld ... install command is different to the LFS 6.2 commands but is still manipulating (in 6.1.1 overwriting) the linker (ld) from the binutils package so it must still be run as your binutils package user. Next, amend the GCC specs file so that it points to the new dynamic linker, ... The Gcc specs file belongs to GCC, so you run the next block of commands (gcc -dumpspecs | perl) as your gcc package user. In 6.1.1 you're still manipulating the same gcc specs file with an almost identical command, so it must still be run as your gcc package user. The rest of section 6.10 are just checks. They should ideally be run as a normal user without any privileges, i.e. not root and not a package user. In 6.1.1 it's section 6.12 which has less thourough checks, but the same applies. I was talking about LFS version 6.1.1 rather than 6.2. Sorry you did mention that but I clicked my bookmark to the 'stable' version too quickly. BTW, I know the commands are sometimes quite cryptic but if you figure out which file(s) they are manipulating then you just have to look which user owns the files from that package and that's the user to use. The whole principle of the package users method is that only the user who owns the package has the permissions to manipulate the files from that package. (Root has permissions too, of course, but that's what you are avoiding with package users.) In most cases, you will get a warning or error message related to permissions if you use the wrong user. Brandon -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: package users: re-adjusting the toolchain
Chris Staub wrote: The adjusted linker is installed into /tools, so you need to use root. Why root? Of course you can always achieve this with root, but that's kind of missing the point of package users technique, (and also violating principle of least privelege). I concede that the motivation for why you would use the package users technique in the first place is much less applicable to the installations in /tools than to the final installations in /usr. However from reading the experiences of people who have used this technique, they all say that you should start with it from the beginninig because you make life really difficult for yourself if you try to switch half-way. I therefore assume that if Angel has got this far with package users, he has been using them also in Ch 5. I'm also assuming that the numeric user IDs of the package users in the chroot match those on the host, otherwise it will be a real mess. Hmmm. A lot of assumptions. I concur with your earlier statement about the level of experience need to use the package users technique compared with the type of questions asked. Brandon -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: package users: re-adjusting the toolchain
Chris Staub wrote: Chris Staub wrote: You're not *supposed* to be using package users in chapter 5. It's only in chapter 6. The only package installed using package users so far should be glibc. From the hint: Build Chapter 5 exactly as explained by the LFS book. There is only one little change you have to make. After running `make install' for the coreutils package, issue the following command (still from within the coreutils build directory): cp src/su /tools/bin OK, I see the approach. Thx for pointing that out. Root it is, then. Brandon. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Switching users in a bash script?
lynx.abraxas wrote: On 27/08/06 12:19:38, Scott wrote: On Sat, Aug 26, 2006 at 06:11:43PM -0700, [EMAIL PROTECTED] wrote: Here's how you pipe commands. Throw an exit on the end of that, your root password on the front, giving: START FILE 123456 ./configure --prefix=/usr make make install exit END FILE Then simply call: echo build-package-name.txt | su I tried that before. On my system (Mandrake 10.1) I get: stdin must be tty I have never seen this technique before. But being curious I tried it too and am getting: su: must be run from a terminal Are there different implementations of su out there? I have an LFS 5.1.1 There is an su command in Coreutils and in Shadow. The one from coreutils sucks. Ever since I can remember LFS suppresses the coreutils one and installs the shadow one, but maybe the suppression technique has changed. Also, LFS 5.1.1 is probably from the time before the merge of sh-utils and textutils into coreutils, so you should best go back and look at the relevant chapters of the 5.1.1 book in the LFS museum. If you skipped the supression command you might have ended up with the wrong version. Running 'su --version' might help you to indentify your binary. Recent coreutils versions will respect that switch and clearly print out that it is from coreutils. Recent shadow versions will complain that it's an unrecognized option and print a usage message. I also have an older su binary lurking on my box (probably from the shadow version used in LFS 4.0) which treats the --version arg as the user name to su to, and will prompt for a password. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: upgrade of libc-2.3.3.so to libc-2.3.6.so problematic?
lynx.abraxas wrote: Forgot to ask what gcc version You'd recommend for glibc, and wich for the kernel, and the rest? Should it all be compiled by the same version? I know 2.95 is not good anymore but version 4 does something wrong, too. 3.3.6 then, or 3.4? I suggest that if you want to choose a Gcc version you will have the fewest headaches with the newest Gcc before the 4.x series. I'm getting good results with 3.4.6. No they do not all need to be compiled with the same version, but if you start to install many different versions of Gcc on your box you increase the risk that something might get mixed up sooner or later. LFS 5.1.1 should have been built with Gcc 3.3.3. If that's still the one installed on your system, just use that unless you encounter a specific problem/reason to use a newer on. B. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Switching users in a bash script?
Luca Dionisi wrote: On 8/27/06, Angel Tsankov [EMAIL PROTECTED] wrote: Btw, how do I call a function in a bash script from another bash script? Try putting all your functions alone in a file, then source that file (man source) That's one possibility that definitely works. AFAIK if you 'export my_func' in the first script, then it will be visible from a child script. B. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Switching users in a bash script?
[EMAIL PROTECTED] wrote: If you really want it fast, you can put almost everything into the main script and have the 'su' script just call 'make install'. I think you are assuming that compiling is done as lfs user and install is done as root. That is the normal case, but it's not like that for package users technique. BTW, I'm curious why just doing the install in an su script instead of the whole package in and su script should be faster? As long as you don't increase then number of su's then it should make no difference whether the bulk of commands come before or after the su (unless you have a very long PATH for one of the users and shell hashing off). And anyway, doing an su is not all that slow compared to the time of a build. I mean I have not seen an autoconf configure script complete in less than 6 seconds on my box and there's no way su takes anywhere near even 1 second. B. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: upgrade of libc-2.3.3.so to libc-2.3.6.so problematic?
Dan Nicholson wrote: So, you want to install into a temporary location. make install_root=/some/temp/location install Certainly, however you proceed after to upgrade your live system you want to start with the above. You don't want to leave this critical installation in the hands of the Makefile! I stole this from Greg Shafer's scripts, and David Rosal, who wrote the paco package manager, has dubbed it the tar sandwich. As root: cd /some/temp/location tar -cf - . | tar -C / -xf - For reasons that I can't explain fully, this is safer than rm /lib/libc.so.x.y.z install -m755 libc.so.x.y.z /lib which is basically what the Makefile would do. That may be so, but you want to be very careful about the way tar (mis)handles overwriting of existing symlinks. If Dan says he's done it exactly like that, then I must believe him. But I suspect you might not get exactly the result you expect The tar sandwich is good but I would suggest to exclude the symlinks in /some/temp/location from that sandwich. Let's take a look what's going on. Almost every binary on your system needs at least 2 critical files just to be able to start. Take any basic binary that you think you might need during the upgrade: rm, mv, cp, ln, tar,... and examine it: bash$ ldd /bin/cp libc.so.6 = /lib/libc.so.6 (0xb7eb9000) /lib/ld-linux.so.2 (0xb7feb000) So, I think you can appreciate that if you mess up either of these 2 files, you will no longer be able to start any of the commands that you need to fix the mess and you are hosed. Time to dive for the boot-CD. (Well actually there's another life-saver I will come back to.) Take a look and you will see that both these critical files are actually symlinks: /lib/libc.so.6 - libc-2.3.3.so /lib/ld-linux.so.2 - ld-2.3.3.so So the basic approach, which I have used successfully, is to install the new files /lib/libc-2.3.6.so and /lib/ld-2.3.6.so then adjust the symlinks to point to the new files. Remember that if you do something like (cd /lib; rm -f libc.so.6; ln -s libc-2.3.6.so libc.so.6) you will be screwed because the ln -s will be unable to start due to the missing libc.so. Normally something like (cd /lib; ln -sf libc-2.3.6.so libc.so.6) is fine but you definitely want to know about sln before you attempt this. Of course, you don't want to do that 'by hand' for each file, but it helps to understand what's going on in case you have to recover by hand. The basic steps are 1. configure and compile glibc and install to /some/temp/location 2. check /some/temp/location and remove any files you do not want to overwrite, e.g. customized versions of etc/ld.so.conf or etc/nsswitch.conf 3. remove the symlinks from /some/temp/location and create a suitable script (see below). 4. do your backups, and make sure you also have a backup copy of sln binary on your root partition. It comes with glibc so it will be overwritten and something could go wrong... 5. do the tar sandwitch thingy to install the new files including the new shared libraries. this shouldn't break anything critical yet 'cos the the 2.3.3 files and symlinks pointing to them are still in place. 6. run the script created in step 3 to upgrade the symlinks. 7. now you should be running with the new glibc. check that stuff still works. 8. you may want to reboot now as Dan suggested, but don't do it before you have verified that things work. If you have a libc problem, then things like mount will not work when you reboot and your init scripts will fail horribly. 9. if all is good, remove the old 2.3.3 files (only files not common between the versions, i.e. only the ones containing version num in the file name). For the script mentioned in steps 3 6, you can use code similar to the following (heavily based on ideas from Slackware's pkgtool scripts): cd /some/temp/location find . -type l \ | xargs ls -l --time-style=long-iso \ | sed -e 's/ \+/ /g' \ | cut -d ' ' -f 8,10 \ | while read link link_trgt [ -n $link ] do link_name=`basename $link` link_dir=`dirname $link` echo ( cd $link_dir \ ; sln $link_trgt $link_name ) /some/script/file rm -f $link done (The sed is to squeeze double spaces between some columns of ls output for the benefit of cut.) This will delete all the symlinks from the temp location and create a script that looks like ... (cd /lib; sln libc-2.3.6.so libc.so.6) (cd /lib; sln ld-2.3.3.so ld-linux.so.2) ... Warning: You are about to attempt a potentially catastrophic upgrade. Don't take my word for it. Test the above code in /another/temp/dir and be sure it does what you want. Familiarize yourself with sln. It does not support all the syntax variations and options of the core-utils ln, and the behaviour is different in some cases, particularly overwriting existing links. IIRC sln behaves more like ln -s -f Good luck. I'd make sure to make a backup of the original glibc and make sure I had a LiveCD handy
Re: upgrade of libc-2.3.3.so to libc-2.3.6.so problematic?
Dan Nicholson wrote: So, you want to install into a temporary location. make install_root=/some/temp/location install Certainly, however you proceed after to upgrade your live system you want to start with the above. You don't want to leave this critical installation in the hands of the Makefile! I stole this from Greg Shafer's scripts, and David Rosal, who wrote the paco package manager, has dubbed it the tar sandwich. As root: cd /some/temp/location tar -cf - . | tar -C / -xf - For reasons that I can't explain fully, this is safer than rm /lib/libc.so.x.y.z install -m755 libc.so.x.y.z /lib which is basically what the Makefile would do. That may be so, but you want to be very careful about the way tar (mis)handles overwriting of existing symlinks. If Dan says he's done it exactly like that, then I must believe him. But I suspect you might not get exactly the result you expect The tar sandwich is good but I would suggest to exclude the symlinks in /some/temp/location from that sandwich. Let's take a look what's going on. Almost every binary on your system needs at least 2 critical files just to be able to start. Take any basic binary that you think you might need during the upgrade: rm, mv, cp, ln, tar,... and examine it: bash$ ldd /bin/cp libc.so.6 = /lib/libc.so.6 (0xb7eb9000) /lib/ld-linux.so.2 (0xb7feb000) So, I think you can appreciate that if you mess up either of these 2 files, you will no longer be able to start any of the commands that you need to fix the mess and you are hosed. Time to dive for the boot-CD. (Well actually there's another life-saver I will come back to.) Take a look and you will see that both these critical files are actually symlinks: /lib/libc.so.6 - libc-2.3.3.so /lib/ld-linux.so.2 - ld-2.3.3.so So the basic approach, which I have used successfully, is to install the new files /lib/libc-2.3.6.so and /lib/ld-2.3.6.so then adjust the symlinks to point to the new files. Remember that if you do something like (cd /lib; rm -f libc.so.6; ln -s libc-2.3.6.so libc.so.6) you will be screwed because the ln -s will be unable to start due to the missing libc.so. Normally something like (cd /lib; ln -sf libc-2.3.6.so libc.so.6) is fine but you definitely want to know about sln before you attempt this. Of course, you don't want to do that 'by hand' for each file, but it helps to understand what's going on in case you have to recover by hand. The basic steps are 1. configure and compile glibc and install to /some/temp/location 2. check /some/temp/location and remove any files you do not want to overwrite, e.g. customized versions of etc/ld.so.conf or etc/nsswitch.conf 3. remove the symlinks from /some/temp/location and create a suitable script (see below). 4. do your backups, and make sure you also have a backup copy of sln binary on your root partition. It comes with glibc so it will be overwritten and something could go wrong... 5. do the tar sandwitch thingy to install the new files including the new shared libraries. this shouldn't break anything critical yet 'cos the the 2.3.3 files and symlinks pointing to them are still in place. 6. run the script created in step 3 to upgrade the symlinks. 7. now you should be running with the new glibc. check that stuff still works. 8. you may want to reboot now as Dan suggested, but don't do it before you have verified that things work. If you have a libc problem, then things like mount will not work when you reboot and your init scripts will fail horribly. 9. if all is good, remove the old 2.3.3 files (only files not common between the versions, i.e. only the ones containing version num in the file name). For the script mentioned in steps 3 6, you can use code similar to the following (heavily based on ideas from Slackware's pkgtool scripts): cd /some/temp/location find . -type l \ | xargs ls -l --time-style=long-iso \ | sed -e 's/ \+/ /g' \ | cut -d ' ' -f 8,10 \ | while read link link_trgt [ -n $link ] do link_name=`basename $link` link_dir=`dirname $link` echo ( cd $link_dir \ ; sln $link_trgt $link_name ) /some/script/file rm -f $link done (The sed is to squeeze double spaces between some columns of ls output for the benefit of cut.) This will delete all the symlinks from the temp location and create a script that looks like ... (cd /lib; sln libc-2.3.6.so libc.so.6) (cd /lib; sln ld-2.3.3.so ld-linux.so.2) ... Warning: You are about to attempt a potentially catastrophic upgrade. Don't take my word for it. Test the above code in /another/temp/dir and be sure it does what you want. Familiarize yourself with sln. It does not support all the syntax variations and options of the core-utils ln, and the behaviour is different in some cases, particularly overwriting existing links. IIRC sln behaves more like ln -s -f Good luck. I'd make sure to make a backup of the original glibc and make sure I had a LiveCD handy
RE: Permission denied -- how to report a bug?
I wrote: I couldn't enter a defect ticket in the LFS wiki using a login I used successfully once before. I guess this is not the right forum to deal with that issue, so what is? Sorry. Withdraw that question. Problem was with my ISP's proxy. Bypassed and now it works. B. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Dejagnu 1.4.4 testsuite failures
Colin Kemp wrote: On Aug 22, 2006, at 10:59 PM, Brandon Peirce wrote: I'm having massive failures with the Dejagnu testsuite, by which I mean 21 failures and only 3 passes! Dejagnu itself seems fine, because I installed it anyway and used it to successfully run binutils and gcc testsuites with identical results to previous builds. The only thing that i could see is the fact that dejagnu is a temp tool that does not require a test suite... something on the host could be screwing with it, but if it works then i would disregard it Strictly speaking, it is a temp tool as far as LFS is concerned, but it is also a useful package to have around and I consider it a fairly important part of a complete toolchain/development environment. I prefer to have a measure of confidence in a program before installing it, rather than just blindly installing and hoping I won't discover an issue further down the chain... And it's not like I'm doing this just once! I am busy developing a kind-of customized A,B,C-LFS of my own, so lots of packages being recompiled and comparison of test-suite results provides useful 'checkpoints'. B. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS Version 6.2 - 8.4. Making the LFS System Bootable
Wang, Baojun wrote: Does LFS 6.2 require kernel 2.6.16? if not, you can copy a config file(usally /boot/config-2.6.x-xxx) to override the .config file under linux source tree then rebuild the kernel. here is the .config file for linux 2.6.15 modify very small from ubuntu 6.06 LTS: Unless you have a lot of experience it is much safer to stick to the version in the book. The versions of packages given in the book are tested to work together. If you run into problems with a different version and ask for help, you are likely to get the answer to first try the correct version The good news is that if you have a config file from 2.6.15 that works for your system, you can use that as a starting point to configure your LFS 2.6.16.27 kernel. It should have suitable drivers for your hardware. But you cannot use it just as it is. What you have to do is first apply the patch and do make mrproper like in the book. Then copy your existing config file to .config in the kernel source tree like you describe, and then run make oldconfig instead of make menuconfig. Make oldconfig will regenerate the .config file, but it keeps all the same settings you had in the old one unless they are incompatible with the actual version of the kernel sources you are using. It will prompt you only if there are new options in the kernel that don't exist in you old config file. Brandon -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Dejagnu 1.4.4 testsuite failures
Hi all, I know I pushing my luck asking this question here because I'm not exactly following the book, but any suggestions would be appreciated. I'm having massive failures with the Dejagnu testsuite, by which I mean 21 failures and only 3 passes! The only thing I could find in Google is http://savannah.gnu.org/bugs/?func=detailitemitem_id=17176 which describes my problem almost exactly but without further info. Dejagnu itself seems fine, because I installed it anyway and used it to successfully run binutils and gcc testsuites with identical results to previous builds. I'm just wondering if anyone else has experienced this. Also, would it be possible to post some other logs under http://www.linuxfromscratch.org/lfs/build-logs/6.2/ ? Brandon -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS Version 6.2 - 8.4. Making the LFS System Bootable
S. Anthony Sequeira wrote: On Sun, 2006-08-20 at 14:40 +0200, Mag. Leonhard Landrock wrote: As I said: My boot device for LFS is an external USB hard disk. In fact, it is a Western Digital WD2500BB in an external USB case. If it's a SATA disk, you will find the SATA drivers under SCSI low level drivers in the kernel config. If you're not sure which SATA driver to use, `lsmod |grep sata_' on your host box should be helpful. No. It should be an IDE device. Take a look at http://www.wdc.com/en/products/Products.asp?DriveID=41;. USB drives are supported by the SCSI drivers. Make sure you have the relevant SCSI options compiled into the kernel. In fact, the kernel has deprecated support for SATA under IDE and the modern SATA support is under SCSI. On my system, the BIOS shows my SATA interface as a 3rd IDE intf but nevertheless my Linux kernel uses SCSI. Granted, it's not an external USB device, but I still think it would be worth double-checking what support you have configured into your kernel, and also compare how your Debian host is accessing the disk as with the lsmod command, for example. See also the thread that concludes with http://archives.linuxfromscratch.org/mail-archives/lfs-chat/2006-March/027309.html Brandon. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: First-time LFS book reader beeing stuck
Richard Szlachta wrote: Actually, ls -l /mnt/data/tools says it is nor file nor directory. I must have misunderstood something in the book. I think you did. Re-read 4.2. Creating the $LFS/tools Directory and the bits about /tools... in 5.2. Toolchain Technical Notes I have placed tools on /tools, where / is filesys root of system (debian) i am currently running. So, if i 'mv /tools /mnt/data' will it be right thing to do? Yes, and then create the symlink too: mv /tools /mnt/data ln -s /mnt/data/tools / The idea behind this is that the new compiler, linker, etc (toolchain) that you are installing in /mnt/data/tools is built in a way that it contains hard-coded paths to /tools. You will find them installed in /tools after you chroot into /mnt/data. However, you actually need to start using this new toolchain _before_ you get to the chroot part. There are two things needed to make this happen. 1) You have /tools/bin as the _first_ element of your PATH (see 4.4. Setting Up the Environment) 2) You have the symlink /tools - /mnt/data/tools so that your host system can find these files in /tools/* although they are actually in /mnt/data/tools/*. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Uninstalling software in Linux
Angel Tsankov wrote: Really simple way: Run ./configure and make as usual, but don't make install yet. Run touch /baseline (any file works) to set a baseline date. Run make install. Run find / -cnewer /baseline | sed -e '/^\/proc/d' -e '^\/sys/d' /packagename.txt . This will show all of the files that were updated in the make install. Then you can just run rm `cat /packagename.txt` to remove the package. Hmm, this seams a very neat solution, but one need to be very careful when applying it in a multi-user environment (even in a multi-process one), so that files modified between 'make install' and 'find' do not get accidentally deleted. These could be user files (ones owned by non-root users) or even configuration or log files of other programs already installed and running on the target system. Indeed, you have well understood the limitations of this method. That's why you should check the contents of /packagename.txt well before doing the rm! In your chroot environment while building LFS, you should be quite free from the concurrency effect. Also, you can exclude certain directories like /home and /var/log. Watch out particularly for shared config files and the like. If the make install created a new user for example, the above method will zap your entire /etc/passwd! A more common example is the installation of packages with texinfo pages, which add entries to the top level info directory node. Again, the above method will zap /usr/share/info/dir. You can deal with that by the following technique: DIRFILE=`grep info/dir /packagename.txt` install-info --dir-file=$DIRFILE --delete \ `grep info/.*\.info.* /packagename.txt` (Don't forget to remove the $DIRFILE line from /packagename.txt before the rm!) A safer approach is to install into a temp dir and then roll that up into a tarball. It usually goes something like this: DESTDIR=/tmp/packagename mkdir $DESTDIR make DESTDIR=$DESTDIR install cd $DESTDIR tar -czf /packagename.tar.gz . To install: cd / tar -xzf /packagename.tar.gz To uninstall: cd / tar -tzf /packagename.tar.gz | grep -v '/$' |xargs rm -vf With this approach, you still have to be careful of the type of problem I described above with info/dir. It is also better to script the symlinks rather than to let tar handle them. So there are several things to watch out for but there are solutions for all of them and they can all be scripted--once you have done that, you will have written your own basic package management tool! B. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS 6.1.1: umount: /mnt/lfs: device is busy
On Sat, 12 Aug 2006 12:41:45 +0300, Angel Tsankov wrote: Also, if you forgot to unmount anything while chrooted, that would do it too. I have not mounted anything other than the following devices (during populating /dev): mount -nvt tmpfs none /dev mount -vt devpts -o gid=4,mode=620 none /dev/pts mount -vt tmpfs none /dev/shm I guess I do not need to unmount these devices, right? If you issued those commands _inside_ the chroot env, then yes you do need to umount them before leaving it (or chroot back in to recover). You can always check those with cat /proc/mounts. That will show _all_ the mounts, both on the host and inside the chroot, whereas they use seperate /etc/mtab which each show only an incomplete picture. Two points to note: 1° the output of mount comes from /etc/mtab 2° for filesystems mounted from within the chroot env, /proc/mounts will show a different mount point depending on whether you are in the chroot or not. B. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Compiling with MSYS
[EMAIL PROTECTED] wrote: MSYS (or MinGW, almost same thing) has GCC. On 8/3/06, Jaqui Greenlees [EMAIL PROTECTED] wrote: --- Shane D. Johnson [EMAIL PROTECTED] wrote: I found MSYS while I was investigating QEMU. Has anyone tried to use it to compile LFS? the Linux kernel actually requires gcc to build properly. so, even if MSYS will build everything else, you'll still need to build the kernel with gcc. Jaqui Shane, I think you need to first be clear what you hope to achieve by this. Are you trying to achieve some kind of UNIX-like environment running under Windoze, or are you trying to build a fully bootable GNU/Linux system compiled under Windoze? If the first, then you may want to rather check out Cygwin, (although it has one major security hole inherent in it's current design). Note also that the porting effort of the Cygwin project is also heavily used in Msys. And yes, I did say porting, with all the implications thereof. If your aim is the second, I would suggest that it would be much easier to use the LFS live CD or any other Linux distro. Remember, Msys is designed towards building native Windoze executables, so IMO you would need to for some kind of cross-linker in your Msys env and you'd probably be doing CLFS not LFS. Either way, I don't expect it will work out of the box. In my previous job, I was trying to set up an Internet- exposed SFTP server on a W2k server box. There's a really cool OpenSSH install package available, but based on Cygwin and I wasn't comfortable with that shared memory vulnerability. I had compiled and installed OpenSSSL and OpenSSH without problems under Linux, but when I tried under Msys I abandoned the project after 2 days. If that's any indication, compiling LFS under Msys will be BIG challenge. Brandon. on -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
RE: glibc-2.3.4 make check error
On Wed, 02 Aug 2006 14:11:39 +0200, Danny wrote: Now I am trying to build a LFS on my PII, 350MHz, 96MB Unfortunatly now I am stuck at chapter 6.11 from the book (V6.1.1) Make[2]: *** [/sources/glibc-build/posix/bug-regex24.out] Error 1 Make[2]: *** [/sources/glibc-build/posix/tst-regex2.out] Error 1 Make[2]: [/sources/glibc/posix/annexc.out] Error 1 (ignored) Make[1]: *** [posix/tests] Error 2 make: *** [check] Error 2 I've checked the archives back till january 2005 and read every post about glibc, and found that annexc.out can be ignored (like it says) but I don't know about the other two. Can some please shed a light on this for me? Danny, I was building on very similar hardware (PII, 180MHz, 96MB) until the box died on me earlier this year. I suffered a lot of errors which I eventually identified to be timeouts. I can't find any logs that old, but those two regex failures do look vaguely familiar. I suggest you scan the test suite log files in the build tree for further info, but most likely your build is fine. If you really want to be sure, I can try to describe more-or-less how it tracked them down but be warned, it's tedious work. Brandon. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: binutils options
On Sat, 29 Jul 2006 21:18:32 -0600, Dennis J Perkins wrote: On Sun, 2006-07-30 at 01:59 +0200, Brandon Peirce wrote: so if you feel like compiling the interesting stuff that you've found into a document (or an update to an existing document), I'm sure many people would find that useful. I might do that but I can't claim to understand many of the options for installing binutils. No obligations :-) I started experimenting today on building a cross compiler for my Athlon 64. I think using --with-sysroot is a good idea, but I don't know yet if its use should be limited to building a cross compiler. I did find that --with-sysroot apparently dos not work with binutils, despite seeing it in tutorials, etc, on line. DESTDIR worked instead. I don't claim to be an expert on this because I've never (yet) tried cross-compiling, although I plan to look into that at some point to compile an i486 system on my somewhat faster i686. But this is what I've managed to find out: 1. The --with-sysroot will never work on binutils-1.17, even if you stand on your head Take another _careful_ look at the output of `binutils-1.17/configure --help` again as someone suggested earlier in the thread. For GCC it's called --with-sysroot, but for Binutils, it's called (arguably more appropriately) --with-build-sysroot, so the option you gave was probably silently ignored. 2. This option should definitely be limited to building a cross compiler IMO. The GCC documentation describes it as a cross compiler-specific option. 3. The DESTDIR variable and the --with-(build-)sysroot option are two completely different things. DESTDIR specifies an alternate location to copy the files to when you install, without affecting any paths compiled into the binaries. It's just an extra prefix on the destination file path during install. --with-(build-)sysroot is more like a search path used at build time to find libraries and headers for the TARGET system. (At least that's my understanding from reading stuff in the INSTALL subdir of the Gcc tree--recommend you look at that. I'm assuming it works similarly for Binutils.) BTW, if you've done LFS and want to check out cross-compiling in more detail, have you tried first to follow the CLFS? That is specifically dedicated to cross-compiled LFS build, and should provide you with something that works. Then you can experiment/learn by deviating from a working CLFS. Brandon. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: binutils options
On Fri, 28 Jul 2006 22:24:04 -0600, Dennis J Perkins wrote: I've been googling on cross compiling and comparing different methods of cross compiling, but some things, like --with-sysroot, aren't well documented, so I was trying to find something more comprehensive. I think I understand most of what I have found. Indeed. Clear, comprehensive documentation in that area is lacking, so if you feel like compiling the interesting stuff that you've found into a document (or an update to an existing document), I'm sure many people would find that useful. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: binutils options
On Wed, 26 Jul 2006 22:10:42 -0600, Dennis J Perkins wrote: On Wed, 2006-07-26 at 18:47 -0400, rblythe wrote: Dennis J Perkins wrote: I'm trying to learn more about the toolchain. I've found guides for building a toolchain, and I sometimes see options like --with-sysroot, but I am having trouble finding information on the options for configuring and compiling binutils. Where can I find this information? After unpacking binutils and changing to the unpacked directory, you could try: ./configure --help [further expl. snipped] That helps, but I was looking for something with more details about building binutils. Have you tried the README file in the binutils _subdir_ of the binutils source tree? - Brandon -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
