Re: [lfs-support] gcc-4.9.0 failure
On Thu, Apr 24, 2014 at 12:23:28AM +0200, Frans de Boer wrote: I could not compile 4.9.0 since it always fails when staring to configure for 'libvtv' as showed next: [snip] Any suggestion? Frans. http://wiki.linuxfromscratch.org/lfs/ticket/3552 Pierre seems to be on the case - so far, two extra configure switches in chapter 5 one extra switch in binutils pass 2. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] ACL check errors: are they important?
On Mon, Apr 21, 2014 at 06:36:19PM +0100, Hazel Russman wrote: On Mon, 21 Apr 2014 19:25:10 +0200 Pierre Labastie pierre.labas...@neuf.fr wrote: Looking more closely at your log, it seems that acl's are enabled, because the line beginning with [95]: 'getfacl --omit-header f' correctly returns acl entries: user::rw- user:bin:rw- user:daemon:r-- Actually, the line beginning with [91], which returns the first error, seems to choke on g:users:rw. Do you have a users group in /etc:group? Pierre Thank you very much. That was the source of the problem. Adding the users group cleared all the remaining errors. But I notice that this group, like the daemon user, are not specified in section 6.6 where /etc/passwd and /etc/group are created. Should they be? From memory (so, I might be wrong) the book doesn't ever create a 'users' group in LFS. What we as individuals have to do may differ. I came here via RedHat-6 and Mandrake-7 and shared /home between the systems I was running at the time. So /home/ken is owned by user 500 and group 1000 : I create ken as user 500 and add a users group of 1000 whenever I build a new system. When I was using ppc I had a user/group combination from debian-based systems - the numbers were quite different. So, I _guess_ that the 'users' group exists on your host system and you will need to create it in LFS to get these tests to work. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] error when trying to cross compile glibc-2.19
On Fri, Apr 18, 2014 at 10:37:48PM +0300, mar...@byteanywhere.com wrote:
Hi,
I am getting the following error trying to build LFS 5.7
For anybody confused by '5.7', that is section 5.7 not the LFS
version ;-) With glibc-2.19 you are either using LFS-7.5 or a
recent version of the development book.
x86_64-unknown-linux-gnu-gcc -D_RPC_THREAD_SAFE_ -D_GNU_SOURCE
-DIS_IN_build -include
/home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/glibc-build/config.h
rpc_main.c \
When I see a version of crosstool in the directory name, together
with your heading about cross-compiling, I think that I don't know
what you are doing! The LFS book is written for people building in
/mnt/lfs, with a symlink from /tools to /mnt/lfs/tools.
There is no requirement that /mnt/lfs needs to be a separate
filesystem, but you do need to be able to access it as /mnt/lfs -
from time to tiem I do test builds using a directory which I have
bound to /mnt/lfs. Perhaps you are doing the same, but referencing
crosstool implies you may well be doing something very different.
In particular, you probably have not followed section 4.3 - we tell
people to log in as the lfs user. Or perhaps the lfs user does have
write access in /home/marian - some potential to overwrite your own
files.
-o
/home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/glibc-build/sunrpc/cross-rpc_main.o
-MMD -MP -MF
/home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/glibc-build/sunrpc/cross-rpc_main.o.dt
-MT
/home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/glibc-build/sunrpc/cross-rpc_main.o
-c
rpc_main.c:37:19: fatal error: errno.h: No such file or directory
#include errno.h
^
compilation terminated.
If you are indeed following the book, I think that perhaps you
didn't install the kernel headers. There are _variants_ of errno.h
in those. But I think this is probably a crosstool issue : glibc
itself provides errno.h, so at this point in the process I guess it
comes from the host system. Or alternatively, it should be coming
from the glibc you are building - in that case, either your disk is
full or the extracted source appears to be incomplete.
It would definitely help if you can explain what you are trying to
do.
I configured :
../glibc-2.19/configure --prefix=/tools --host=$TARGET
--build=$(../glibc-2.19/scripts/config.guess) --disable-profile
--enable-kernel=3.7.10 --with-headers=/tools/include
libc_cv_forced_unwind=yes libc_cv_ctors_header=yes libc_cv_c_cleanup=yes
--without-selinux
I am running on linux 3.7.10. I am not sure how to get this working.
I build gcc using:
make all-gcc
make all-target-libgcc
make install-gcc
make install-target-libgcc
Yes, you are doing something different from the book - we are able
to build pass-1 gcc using just make and make install.
because otherwise if i use make, i also get error saying that the
compiler can not create executables.
Thanks,
Marian
We don't support real cross-compilation, if that is what you are
trying to do. If your host system is x86_64-unknown-linux-gnu then
you should be able to build LFS for x86_64.
But one of the things you need to learn, even if you are not
following the book, is how to debug the C compiler cannot create
executables message. It's actually quite easy - in both gcc and
binutils, configure is run in several directories. As it runs,
it creates output in config.log in that directory, then moves on
to the next directory and does the same thing - until it fails.
So, to debug the gcc build problem (and your solution suggests that
you are really cross-compiling), you need to find the newest
config.log (or log configure's stdout and stderr and work out which
directory it was in by reading the log). Then open up that
config.log in e.g. vim ('view' for safety, I suppose) or else in
'less'. Search for the message:
/C\ compiler\ cannot
('/' to search in vim or less, '\ ' to escape the spaces so that
they are treated as part of the text to search for.)
When you find that error message, look at the lines above it
(probably a few screens worth, say 50 to 100 lines). You should see
a message about what is being tested, a program fragment getting
created, and then it is fed to the compiler to see if it will
compile. Throughout any config.log you will see many error messages,
typically because your system does not support a particular feature,
or does not have a specific file. That is normal, but here you have
a real error.
Sometimes, a missing header might trigger it - that seems unlikely
for this particular error, particularly since you compiled pass 1
binutils just before gcc. Perhaps there was a typo in $LFS_TGT when
you built binutils. Usually, either gcc or ld is objecting to
something in the compile, or occasionally there is a problem with
ld. Either way, you will see the error message in config.log, a few
lines above C
Re: [lfs-support] EXT3-fs (sda4): error: couldn't mount because of unsupported optional features (240) , during kernel boot
On Fri, Apr 04, 2014 at 07:31:51AM -0700, Golam Md. Shibly wrote: Hi, EXT3-fs (sda4): error: couldn't mount because of unsupported optional features (240) EXT4-fs (sda4): couldn't mount as ext2 due to feature incompatibilities What can be the reason for this error? Answers will be appreciated. Thanks. This looks perfectly normal. There is a kernel option to allow ext4 to handle ext2 and ext3 filesystems. I think you probably made an ext4 filesystem on sda4, and after this it should get mounted as ext4. I see something like these messages on every boot. So, do you have a problem [ i.e. it failed to boot ] or are you just concerned about reported errors ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] EXT3-fs (sda4): error: couldn't mount because of unsupported optional features (240) , during kernel boot
On Fri, Apr 04, 2014 at 09:01:56AM -0700, Golam Md. Shibly wrote: cat /etc/fstab = # Begin /etc/fstab # file system mount-point type options dump fsck # order /dev/sda4 / ext4 defaults 1 1 [...] On Friday, April 4, 2014 9:39 PM, Ken Moffat zarniwh...@ntlworld.com wrote: So, do you have a problem [ i.e. it failed to boot ] or are you just concerned about reported errors ? You didn't answer the question, so I assume you are just concerned about reported errors. You seem to have been able to log in to the LFS system to run that 'cat'. So this is nothing to worry about. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Brand new and confused. Mostly about the 7.5 book.
On Sun, Mar 30, 2014 at 11:31:59PM +0200, Aleksandar Kuktin wrote: On Sun, 30 Mar 2014 14:05:50 -0700 Al Szymanski a...@mac.com wrote: I am just trying to figure out the overall smallest size of hard drive space needed for all of the partitions. My sums from the 7.5 book come to 80 Gig plus whatever space I want for /home . [ suggested partition sizes: root LFS 10Gig /usr/src 30-50Gig /opt 5-10Gig /usr 5Gig /tmp 5Gig swap 2xRAM /boot 100Meg =~81Gig ] Are these numbers your own estimates, or did you pick them up somewhere? I'm asking because they overestimate. In particular, the line for /usr/src seems way too big. My own tarball dir (which cotains everything I build) is 2.7 GB, almost ten times smaller that your low estimate. I think we are all following Al in asking the wrong question ;-) Surely, the first question ought to be What partitions will suit _my_ usage ?. In my own builds, /sources is an nfs mount (and it contains in excess of 20GB : I pruned it last week, but it has source for most of the packages in BLFS, so that I could test them for 7.5. My own builds are motly on desktops, and in general I have the following as separate filesystems : /, /boot, /home and swap. I _only_ use LFS, so I need at least two partitions which can be used for '/', and I also allocate my remaining space [ modern disks are stupidly big for desktop users ] to /scratch which does _not_ get backed up. Also, if you have the space in /home, you can keep the sources there. Re the other places mentioned : /usr/src : why do anything here ? In BLFS you are recommended to _not_ build as root (although I do in my scripts) and by default /usr/src is only writable by root. Similarly, anyone who says that the kernel tree belongs in /usr/src/linux is living in the distant past - that idea was obsolete even when I first used linux at the turn of the millenium. Building newer kernels in ~/ is good. /opt : Sometimes it is useful to keep this separate, but unless you intend to put TeX or KDE in /opt I would NOT make it separate. Even if you do intend to use those space-hogs, a bigger '/' [ ideally with room for TWO versions of /opt ] will make building a newer version on the current system _much_ easier. If you do separate /opt, please remember that its programs and libraries will link to libs in '/lib' and '/usr/lib', so sharing /opt between multiple systems on the same machine is not usually possible. Perhaps I should stress that the recommended upgrade path for LFS is to build a new system. So, if you have /opt as a separate filesystem for the first LFS you will need a simialr amount of space for the replacement system. IMHO, far better to make '/' big, with /opt and /usr part of the root filesystem. But whatever you do, if you keep building LFS or similar systems you will eventually find that your partitioning no longer meets your requirements. A rescue CD is essential [ please let me mention systemrescuecd, even though it uses zsh and is therefore not always plain-sailing when entering chroot ]. /usr : A separate /usr is a very old idea. Useful if you are on a network where /usr is an nfs mount shared by several machines. I'm sure there are other use cases, but I can't think of any at the moment. For most of us, giving /usr on its own filesystem makes no sense. /tmp : This is separate ? ken@ac4tv ~ $mountpoint /tmp /tmp is not a mountpoint At one time we used to mount a tmpfs on /tmp, but somewhere along the way (perhaps between 6.8 and 7.0) we stopped doing that, which from my POV was a shame. But I cannot see any good reason to give /tmp its own filesystem. swap : yes. The traditional theory was 2 x physical memory, but I might go with more than that if physical memory is small (e.g. = 4GB). On what is now a small disk I would not go overboard with the swap. /boot : yes, it makes things easier when you upgrade your LFS syustem by building a fresh system. For me, at the moment I have 3 MB in /boot/grub, and 5 MB per kernel - and I've got a lot of those, but they are generally slimmed-down to match my hardware. Sticking a finger i nthe air, 100MB lookss adequate. For *servers*, some other directories might benefit from having their own filesystem, it all depends on what you are doing. I've seen a use-case for separating /var/log, and I myself separate /var/tmp on my server - I also have other non-standard filesystems there. That is all a question of what fits best with what you intend to do. I used to use 6GB partitions for '/' with /sources separate (nfs), but my desktop builds increased to cover more of what is in BLFS. I now use 8GB, but that is not enough for all of the desktop alternatives, and doesn't give enough space for TeX even on my normal desktop [ I put TeX in my /sccratch partition, and bind it if I need to use it, but for a full-ish desktop including more than one DE [
Re: [lfs-support] Brand new and confused. Mostly about the 7.5 book.
On Sun, Mar 30, 2014 at 11:44:19PM +0100, Ken Moffat wrote: swap : yes. The traditional theory was 2 x physical memory, but I might go with more than that if physical memory is small (e.g. = 4GB). On what is now a small disk I would not go overboard with the swap. I managed to come away from Al's post with the impression that he had an 80GB disk, which is where what is now a small disk came from. He actually said that he thought LFS needed 80GB. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 64 bit host machine build question
On Thu, Mar 20, 2014 at 09:15:35PM -0400, Jonathan Arnold wrote:
I'm doing the 5.7 glibc-2.19 step and everything seems to be going
along swimmingly. But the test program mentioned in the Caution isn't
exactly what is desired:
lfs:/mnt/lfs/sources/glibc-build$ echo 'main(){}' dummy.c
lfs:/mnt/lfs/sources/glibc-build$ $LFS_TGT-gcc dummy.c
lfs:/mnt/lfs/sources/glibc-build$ readelf -l a.out | grep ': /tools'
[Requesting program interpreter: /tools/lib64/ld-linux-x86-64.so.2]
While the Caution says to expect the /tools/lib64 part, it doesn't say
anything about the '-x86-64' I have appended to the name. Is this going
to be okay or is something amiss here?
Your result looks fine. When you get to section 6.10 you will see
that we add the phrase allowing for platform-specific differences in
dynamic linker name. If you look at your host system, the linker
will be ld-linux-x86-64.so for 64-bit x86_64.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Blank screen when booting with 3.13.3 kernel. - LFS 7.5
On Wed, Mar 12, 2014 at 08:52:55PM -0500, rhubarbpie...@gmail.com wrote: Louis, Actually, I got several responses quickly. I just sent you one which echoed my situation. I'm hoping Armin will glean something from the log file. Also, take a look at https://lkml.org/lkml/2014/3/13/71 (HP Compaq nc6120 - I don't think you ever mentioned what sort of laptop this was). ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Blank screen when booting with 3.13.3 kernel. - LFS 7.5
On Wed, Mar 12, 2014 at 02:29:52PM -0500, rhubarbpie...@gmail.com wrote: On 03/12/14 12:11, Duc Tran wrote: On 03/12/2014 11:11 PM, Armin K. wrote: On 03/12/2014 05:09 PM, rhubarbpie...@gmail.com wrote: On 03/12/14 10:19, Merell L. Matlock, Jr. wrote: On 03/12/14 10:54, Armin K. wrote: On 03/12/2014 03:46 PM, rhubarbpie...@gmail.com wrote: [ keeping all that, I've lost track of who wrote what ;-) ] Could you post your kern.log from /var/log after you boot? (you can get it from chroot after reboot iirc). Compress it before sending or it might get blocked. I also had no success after deselecting Sony Vaio Programmable I/O Control Device Support. A couple of things I noticed, the first of which is relevant to this, and hte second of which might make things more comfortable when you have this issue sorted. First: Mar 12 13:22:40 lfs kernel: [Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness Mar 12 13:22:40 lfs kernel: [Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness This is supposedly fixed with acpi_backlight=vendor but I think you said that didn't help. Later, some messages showing the console was created : Mar 12 13:22:40 lfs kernel: fbcon: inteldrmfb (fb0) is primary device Mar 12 13:22:40 lfs kernel: Console: switching to colour frame buffer device 160x50 Mar 12 13:22:40 lfs kernel: i915 :00:02.0: fb0: inteldrmfb frame buffer device So it seems that the console is there, but without the backlight. Does your config have all of the CONFIG_BACKLIGHT settings which you had in 3.10 ? Looking at one of the _many_ matches for ACPI: No _BQC method I found an old one which led me to suggest that you try i915.invert_brightness=1 in the boot args. If that helps, you might need to take it upstream : there seem to be a horrendous number of variations in intel graphics chips/implementations, and breakage of some models seems to happen from time to time. This option is documented in the kernel's Documentation/kernel-parameters.txt file. I assume that you are putting the options in the right place, on the same line as root= ? I'm sure you are, but best to check. Iff none of this helps, it might be a kernel regression. Ideally, try to isolate where it happened (e.g. try 3.13.0, 3.12.0, 3.11.0 until you find one that works, and then perhaps move forward through its stable releases to find out where it broke). It's also possible that this has worked sometimes, but not others, on your hardware. *** But first try the latest 3.13 just in case it has already been fixed *** Second: I don't know what size of screen you have (inches or cm, as well as pixels), but 160x50 might be a bit tiny to read - if so, after you can get a display, change (or add) video=x in the boot args where is the number of horizontal pixels on your screen, and is the vertical. On my old 1600x1200 4:3 screen I can also pass 1024x768 or 800x600, but I don't know what your screen size is, or if there are any conventional smaller sizes which would fit onto it. If you are trying this, copying the grub stanza for the kernel but with something different in the menuentry such as your x and just adding the video= will let you see it it helps and still be able to go back to the first one. Using a bigger consolefont can also help - on my netbook I use a 12x22 font to make it easier to read. That requires setting font support, fonts, and Sun 12x22 in the kernel, and the LFS sysconfig will need to either _not_ specify a font (i.e. use the kernel's sun font which is ok for American), or use one of the 12x22 fonts from kbd to get wider coverage. NB specifying a 12x22 font in LFS on the current kernel which probably doesn't support 12x22 will not load the 12x22. If you want to try 12x22, then I suggest you try it in the kernel and look at the kernel messages before userspace drops back to whatever font you are currently using. Then you can decide is 12x22 is useful for you, and either continue, and change the font in LFS, or give it up as too big. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Exotic lfs compiling question
On Thu, Feb 20, 2014 at 04:49:29PM +0100, loki wrote: Kernel is 2.6.35.3. For the future, you _might_ want to think about using a long-term-supported stable kernel (at the moment, 3.10), or even updating your kernel once or twice a year. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 6.55 man-DB 2.6.6
On Sat, Feb 15, 2014 at 08:36:45PM +0100, Frans de Boer wrote: I did a rebuild with glibc-2.18 and there is no difference. All other variables like flex-2.5.37 and using man-db-2.6.5 did not help. So I just put some set +eset -e around the make check and continue with the next package. We'll see where it goes wrong. Frans. It seems to work fine, at least in an LFS/BLFS context. Bruce has now experienced this failure too. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Basic Kernel Configuration
On Sun, Feb 16, 2014 at 01:04:12AM +0100, Armin K. wrote: Hello there, I have been spending my time on LFS IRC for a long time now and have noticed that most users who come for help there get stuck at configuring their kernel. Thus, I have written a rather basic guide on how to configure the kernel to get your machine to boot for the first time (disk controllers and filesystem drivers), but not other hardware specific stuff. You can see it here: http://www.linuxfromscratch.org/~krejzi/basic-kernel.txt Any suggestions or additions are welcome. Cheers. Just a couple of suggestions: 1. SATA etc So I select the first two modules below. s/modules/drivers/ - people coming from a distro might be used to building everything as a module and take it too literally. 2. filesystems - I would be inclined to drop specific mention of reiser3, and cover it by Additionally, any other filesystem not listed here., but perhaps some distro(s) used to use it in the last couple of years. I guess that defconfig covers almost everything else that is commonly needed to get a bootable .config. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 6.55 man-DB 2.6.6
On Thu, Feb 13, 2014 at 06:08:46PM +0100, Frans de Boer wrote: On 02/13/2014 05:29 PM, Armin K. wrote: On 02/13/2014 04:42 PM, Frans de Boer wrote: During testing I get col: Invalid or incomplete multibyte or wide character as output for the man-6 test. I found references which date back to 2009 with the same errors, but no solution is found. So, I doubt I'll be the first to notice this. Any suggestions? Regards, Frans. Ken also reported it few days back on lfs-dev, but it seems that there's no solution for that one, too. http://www.mail-archive.com/lfs-dev@linuxfromscratch.org/msg19395.html Yes, exactly the same error. I also checked my glibc logs as well as the actual contents of the 'locale-archive'file. Could not find any error. Maybe the answer is in the past, since this was noticed in 2009 too. I will look furtherer into it, because it will have impact as reported in 2009. By the way, I tried this with 2.6.4 and 2.6.5 with the same result. I do not remember this when building with glibc-2.18. I will check that too. My build was with glibc-2.18 - I don't expect problems from 2.19, but if they do happen it would be nice to correctly attribute the problem - I've seen too many fixes in distros over the years where they blamed the wrong part of hte toolchain. And all the other testsuites were reasonably ok. Frans. PS: I am glad I finally have made an automated build, same me sooo much time and energy. Great. I just wish I could quickly spot all the changes in LFS and BLFS between my own builds, without looking line-by-line at the diffs. Fortunately, Armin is good at identifying what I've done wrong when I report problems in BLFS ;-) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Lfs building problems
On Mon, Feb 10, 2014 at 01:32:27PM -0800, Jerry Trymander wrote: The problem is that in my case, for instance, the mpfr dir already exists. So my question is: is the mpfr left as a result of the build process failure at some previous step? If not, am I suppose to delete the mptr dir or should it be left as it is? The same problem occurs with a number of xxx-build dirs. Otherwise, despite the fact that, so far, I cannot build the LFS, the book is excellent. Always delete the directories (souce as well as any build dir) before you build a package in a later stage. Deleting them after completing the package's install is best, providing you remembered to do everything in the install. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Errors in 6.13 - Binutils 2.24
On Wed, Jan 29, 2014 at 05:39:39AM +, Ken Moffat wrote: On Wed, Jan 29, 2014 at 03:10:42AM +, Ken Moffat wrote: On Wed, Jan 29, 2014 at 04:53:21AM +0200, Markku Pesonen wrote: The binutils testsuite creates detailed logs in binutils/binutils.log, ld/ld.log, and gas/testsuite/gas.log in the binutils-build directory. I have found them to be very useful in figuring out unexpected test failures. Thanks! I've just blown the first attempt away, but I'll have a look at these in the second attempt. Verily, it was written: cannot find -ldl So, the ld testsuite needs /usr/lib/libdl.a for the -static tests. But now I wish I'd gone to bed hours ago : I'm still getting the same 5 failures- ld-elf.exp Forget that. I'd been up all night in the hope of getting these tests to all pass, and I guess I must have got too tired. Apologies to the binutils devs for suggesting that the summary and ld.log differed, I was wrong. I _thought_ I had rerun my script, i.e. remove the directories, untar, patch (to see which linker was used), make, make check, halt and with my own log from make check logged as LFS-7.4.-3 (third build on this machine). I certainly checked that the date/time (to the minute) of my check log and ld.log agreed, but I now guess that I must have rerun 'make check' by hand and I'm surprised that I managed to read the initial ld.log after the check log had been created, find libdl.a.hidden, rename it, and rerun make check (or perhaps just make check in ld) before the minute changed. I could have sworn that I got the not remade because of errors message. Maybe I reran make check, glanced at the screen with sleepy eyes, and read the earlier 'not remade' message. Whatever, now that I've woken the box from suspend (don't ask about yesterday :) I _did_ rerun my script and all the tests passed, with a status of 0. Spelled out in detail not because it is interesting, or counts as an adequate excuse, but because I believe that technical / support issues are like an exam - show working. Sorry for the noise. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Errors in 6.13 - Binutils 2.24
On Tue, Jan 28, 2014 at 05:30:16PM +0100, Frans de Boer wrote: The next messages are produced every single time I encounter this chapter: Running /sources/binutils-2.24/ld/testsuite/ld-elf/binutils.exp ... Running /sources/binutils-2.24/ld/testsuite/ld-elf/comm-data.exp ... Running /sources/binutils-2.24/ld/testsuite/ld-elf/compress.exp ... Running /sources/binutils-2.24/ld/testsuite/ld-elf/dwarf.exp ... Running /sources/binutils-2.24/ld/testsuite/ld-elf/eh-group.exp ... Running /sources/binutils-2.24/ld/testsuite/ld-elf/elf.exp ... FAIL: static preinit array FAIL: static init array FAIL: static fini array FAIL: static init array mixed Running /sources/binutils-2.24/ld/testsuite/ld-elf/exclude.exp ... [...] Running /sources/binutils-2.24/ld/testsuite/ld-ifunc/ifunc.exp ... FAIL: Could not link a static executable [...] - There are five failures and I can't find the cause of it. I rebuilded everything from scratch - more then once, but still encounter these messages. I tried this on i686 and x86_64 machines. Anybody an idea what might be the cause and if it is a show stopper. Regards, Frans. I see that all the time, at least on x86_64 (I don't remember if I saw it when I built and tested i686 in August). So, definitely NOT a show stopper. In my own builds, I do everything I can to avoid static libraries. I have a _few_ from the toolchain, particularly libc.a, but not all of them, and not static libs from other packages. Pedantically, I do still have the libs, but I rename them to libwhatever.a.static so that I can make them available if I need to. The last time I looked at my own failures in static linking during these tests, I failed to diagnose the problem : I have a variable to preserve all static libs if I'm doing a build like the book run, and I thought that would solve the problem, but it didn't. By the time I looked at the results, I was way past binutils and didn't have the build and source directories any more. I was not sufficiently interested to prioritise debugging what I assumed was a problem with my own scripts. If you have not advanced beyond the tests, and still have all the build directory, I guess you could look at the test results and see if anything jumps out. If not, I suppose I can do a fresh build sometime in the next week or two. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Errors in 6.13 - Binutils 2.24
On Tue, Jan 28, 2014 at 07:27:58PM +0200, Markku Pesonen wrote: Frans de Boer wrote: FAIL: static preinit array FAIL: static init array FAIL: static fini array FAIL: static init array mixed FAIL: Could not link a static executable There are five failures and I can't find the cause of it. I rebuilded everything from scratch - more then once, but still encounter these messages. I tried this on i686 and x86_64 machines. Anybody an idea what might be the cause and if it is a show stopper. I got those errors when I had removed the static version of libz (/usr/lib/libz.a). Static version of glibc is also needed. Thanks for that pointer. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Errors in 6.13 - Binutils 2.24
On Tue, Jan 28, 2014 at 09:48:38PM +0100, Frans de Boer wrote:
On 01/28/2014 09:09 PM, Frans de Boer wrote:
On 01/28/2014 08:37 PM, Ken Moffat wrote:
On Tue, Jan 28, 2014 at 07:27:58PM +0200, Markku Pesonen wrote:
I got those errors when I had removed the static version of libz
(/usr/lib/libz.a). Static version of glibc is also needed.
Thanks for that pointer.
ĸen
Hm, there should be a libz.a somewhere, but none is build. I will look
into the matter and will report back my findings.
Sorry, I had a leftover from a previous experiment where I removed the
static files after install. So, the absence of libz.a is hereby
explained. I will check other scripts for the BSS phase on that fact too.
That does not explain the static allocation errors by it self, but will
start fresh again with a BSS build and monitor what is happening.
Regards, Frans.
I hope your attempt goes better than mine!
I discovered that I had an error in the functions I use while
building, libc.a was being renamed to libc.a - but even with that
renamed, and libz.a being made available, for me the tests still
fail.
Looking at the last test:
binutils-2.23.2/ld/testsuite/ld-ifunc/ifunc.exp
The tests seem to be run from the check-DEJAGNU target
and that uses LIBS=$(LIBS) which is -lz -ldl so that explains the
need for libz.a : the static tests pass -static to the linker.
This particular test is
if ![default_ld_link $ld tmpdir/static_prog -static -Ltmpdir
tmpdir/static_prog.o -lifunc] {
fail Could not link a static executable
set fails [expr $fails + 1]
}
and for me, now, the problem seems to be $ld.
If I try to run the command in binutils/build/ld using _any_ ld
(either the existing version in /tools/bin. or the newly built
ld-new which is what actually gets used) it fails like this:
ld -o tmpdir/static_prog -static -Ltmpdir tmpdir/static_prog.o -lifunc
ld: warning: cannot find entry symbol _start; defaulting to
00400140
tmpdir/static_prog.o: In function `main':
prog.c:(.text.startup+0x28): undefined reference to `printf'
prog.c:(.text.startup+0x41): undefined reference to `puts'
prog.c:(.text.startup+0x4d): undefined reference to `puts'
prog.c:(.text.startup+0x62): undefined reference to `puts'
prog.c:(.text.startup+0x71): undefined reference to `puts'
I tried adding other libs, but only managed to progress to blowing
up against undefined unwind symbols and __gcc_personality_v0 which
may be a g++ thing. Adding libstdc++ and libsupc++ didn't help.
There was a suggestion elsewhere to link in libgcc_s to fix a
__gcc_personality_v0 problem, but that is a _shared_ lib and the
test forces -static.
BUT if I run it using gcc :
gcc -o tmpdir/static_prog -static -Ltmpdir tmpdir/static_prog.o -lifunc
it succeeds and I can then do
./tmpdir/static_prog
ifunc working correctly
I found that binutils-build/ld/ld-new was being used by instrumenting
binutils-2.23.2/ld/testsuite/lib/ld-lib.exp
by adding a line
send ld is $ld
in the default_ld_link proc. Oh well, I've learned how to print a
variable in an expect script :-(
And it seems to me that when I run the testsuite it will only work
if $ld is expanded to gcc. And yet it appears to work for some other
people.
I think I'll make a fresh attempt, maybe tomorrow, but in the mean
time any suggestions are welcome. Although the build was scripted,
the ld tests still fail if I run 'make check' by hand in
binutils-build/ld. For those who want to know about my environment:
root in chroot /building/binutils-build/ld# printenv
TERM=xterm-color
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin
JOBS=4
PWD=/building/binutils-build/ld
REALDEV=
PS1=\u in chroot \w\$
SHLVL=1
HOME=/root
_=/tools/bin/printenv
OLDPWD=/building/binutils-build
root in chroot /building/binutils-build/ld#
Oh, and type-pa ld shows /tools/bin/ld
(yes, still building in /mnt/lfs/building - /sources is still an nfs
mount from another machine :)
$REALDEV could be /dev/sdX, it gets used in real builds to help me
work out values for fstab and for the rootfs backups, but I've bound
/scratch/lfs to /mnt/lfs for this debugging build.
$JOBS gets passed to make -j during (most) compiles (but never to
installs).
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Errors in 6.13 - Binutils 2.24
On Wed, Jan 29, 2014 at 12:40:15AM +, Ken Moffat wrote: I discovered that I had an error in the functions I use while building, libc.a was being renamed to libc.a - but even with that was being renamed to libc.a.hidden renamed, and libz.a being made available, for me the tests still fail. Just correcting that line for clarification, both libc.a and libz.a are available. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Errors in 6.13 - Binutils 2.24
On Wed, Jan 29, 2014 at 04:53:21AM +0200, Markku Pesonen wrote: Ken Moffat wrote: I think I'll make a fresh attempt, maybe tomorrow, but in the mean time any suggestions are welcome. Although the build was scripted, the ld tests still fail if I run 'make check' by hand in binutils-build/ld. The binutils testsuite creates detailed logs in binutils/binutils.log, ld/ld.log, and gas/testsuite/gas.log in the binutils-build directory. I have found them to be very useful in figuring out unexpected test failures. Thanks! I've just blown the first attempt away, but I'll have a look at these in the second attempt. Also, an addition to my previous comment on instrumenting the exp file (if anyone cares) - send ld is $ld\n; will be much nicer. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Errors in 6.13 - Binutils 2.24
On Wed, Jan 29, 2014 at 03:10:42AM +, Ken Moffat wrote:
On Wed, Jan 29, 2014 at 04:53:21AM +0200, Markku Pesonen wrote:
The binutils testsuite creates detailed logs in binutils/binutils.log,
ld/ld.log, and gas/testsuite/gas.log in the binutils-build directory.
I have found them to be very useful in figuring out unexpected test
failures.
Thanks! I've just blown the first attempt away, but I'll have a
look at these in the second attempt.
Verily, it was written:
cannot find -ldl
So, the ld testsuite needs /usr/lib/libdl.a for the -static tests.
But now I wish I'd gone to bed hours ago : I'm still getting the
same 5 failures-
ld-elf.exp
static preinit array
static init array
static fini array
static init array mixed : all still fail
ifunc.exp - could not link a static executable : still fails
For the first four, ld.log tells me PASS !! :
Executing on host: sh -c {/building/binutils-build/ld/ld-new -m
elf_x86_64 -o tmpdir/preinit -dynamic-linker
/lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/crt1.o
/usr/lib/../lib64/crti.o
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtbegin.o
-L/building/binutils-2.23.2/ld/testsuite/ld-elf -static
tmpdir/preinit.o -lz -ldl -L/usr/lib/../lib64 --start-group
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libgcc.a
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libgcc_eh.a -lc
--end-group /tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtend.o
/usr/lib/../lib64/crtn.o 21} /dev/null ld.tmp (timeout = 300)
spawn [open ...]^M
Running: tmpdir/preinit tmpdir/preinit.out
diff tmpdir/preinit.out
/building/binutils-2.23.2/ld/testsuite/ld-elf/preinit.out
PASS: static preinit array
Executing on host: sh -c {/building/binutils-build/ld/ld-new -m
elf_x86_64 -o tmpdir/init -dynamic-linker
/lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/crt1.o
/usr/lib/../lib64/crti.o
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtbegin.o
-L/building/binutils-2.23.2/ld/testsuite/ld-elf -static
tmpdir/init.o -lz -ldl -L/usr/lib/../lib64 --start-group
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libgcc.a
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libgcc_eh.a -lc
--end-group /tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtend.o
/usr/lib/../lib64/crtn.o 21} /dev/null ld.tmp (timeout = 300)
spawn [open ...]^M
Running: tmpdir/init tmpdir/init.out
diff tmpdir/init.out
/building/binutils-2.23.2/ld/testsuite/ld-elf/init.out
PASS: static init array
Executing on host: sh -c {/building/binutils-build/ld/ld-new -m
elf_x86_64 -o tmpdir/fini -dynamic-linker
/lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/crt1.o
/usr/lib/../lib64/crti.o
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtbegin.o
-L/building/binutils-2.23.2/ld/testsuite/ld-elf -static
tmpdir/fini.o -lz -ldl -L/usr/lib/../lib64 --start-group
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libgcc.a
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libgcc_eh.a -lc
--end-group /tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtend.o
/usr/lib/../lib64/crtn.o 21} /dev/null ld.tmp (timeout = 300)
spawn [open ...]^M
Running: tmpdir/fini tmpdir/fini.out
diff tmpdir/fini.out
/building/binutils-2.23.2/ld/testsuite/ld-elf/fini.out
PASS: static fini array
Executing on host: sh -c {/building/binutils-build/ld/ld-new -m
elf_x86_64 -o tmpdir/init-mixed -dynamic-linker
/lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/crt1.o
/usr/lib/../lib64/crti.o
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtbegin.o
-L/building/binutils-2.23.2/ld/testsuite/ld-elf -static
tmpdir/init-mixed.o -lz -ldl -L/usr/lib/../lib64 --start-group
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libgcc.a
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libgcc_eh.a -lc
--end-group /tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtend.o
/usr/lib/../lib64/crtn.o 21} /dev/null ld.tmp (timeout = 300)
spawn [open ...]^M
Running: tmpdir/init-mixed tmpdir/init-mixed.out
diff tmpdir/init-mixed.out
/building/binutils-2.23.2/ld/testsuite/ld-elf/init-mixed.out
PASS: static init array mixed
for ifunc.exp I'm not exactly sure what I'm looking for, but all
the tests seem to pass.
I'm _sorely_ tempted to give up attempting to run testsuites on
lfs (yes, I still remember the erratic problems people had in LFS-4
which led to pure lfs in which toolchain testsuites were run, but
I'm getting hacked off by this heap of foetid dingos' kidneys).
The logs (binutils-2.23.2.log.check and ld.log) are now at
http://higgs.linuxfromscratch.org/~ken/binutils-failures/
and changed to m644 so that people can read them.
Undoubtedly the fault is still in what _I'm_ doing, but I'm
distinctly unimpressed by tests which report that they fail, but
show as pass in the detailed log.
Now, if you will excuse me, I'll go and shout some language which
would get me banned from the lists if I posted it.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above
Re: [lfs-support] 5.8 Libstdc++4.8.1 compilation error also on 32-bits architecture
On Wed, Jan 22, 2014 at 11:40:44AM +0100, Pierre M.R. wrote: Enrique Larraia wrote: libtool: install: i686-lfs-linux-gnu-ranlib /tools/lib/libsupc++.a ../libtool: line 1132: i686-lfs-linux-gnu-ranlib: command not found The error message comes from bash. It looks like 'make install' reset the shell PATH. I would suspect some security magics like selinux. Pierre If so, more likely AppArmor - but ubuntu has shipped with that for several years. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 5.8 Libstdc++-4.8.1
On Wed, Jan 22, 2014 at 10:11:29PM +, akhiezer wrote: (( p.s. Although - and excuse the/any noise - OTTOMH am not sure why sudo need be part of the picture if the 'su - lfs' is done in '4.3. Adding the LFS User'. Also noticed earlier that the 'problematic' ranlib in your /tools/bin was owned by root:root ; which didn't seem right for that stage of build. BUT, am still not at a suitable environment for checking those out: hence again, apols for the/any noise. )) Well spotted - I had missed that ownership. Owning by root:root is probably, in itself, not a problem. But it appears to indicate that make install is being run as root. If that is the case, any errors can trash the host system. I don't, for the moment, understand *how* root came to be involved. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 5.8 Libstdc++4.8.1 compilation error also on 32-bits architecture
On Tue, Jan 21, 2014 at 09:53:03PM +, Enrique Larraia wrote: Hi all, I'm experiencing the same issue as Louis Rine in this thread: https://www.mail-archive.com/lfs-support@linuxfromscratch.org/msg21373.html I'm unsure whether or not reply to the cited thread, or create one on my own. I apologize if this causes a duplication of the same topic :( I think we are out of ideas on that thread, so either way will suit :-( I got the following otuput error after make install of package libstdc++-4.8.1: make[1]: Leaving directory `/mnt/lfs/sources/gcc-build/include' Making install in libsupc++ make[1]: Entering directory `/mnt/lfs/sources/gcc-build/libsupc++' make[2]: Entering directory `/mnt/lfs/sources/gcc-build/libsupc++' test -z /tools/lib || /bin/mkdir -p /tools/lib /bin/sh ../libtool --mode=install /usr/bin/install -c libsupc++.la '/tools/lib' libtool: install: /usr/bin/install -c .libs/libsupc++.lai /tools/lib/libsupc++.la libtool: install: /usr/bin/install -c .libs/libsupc++.a /tools/lib/libsupc++.a libtool: install: chmod 644 /tools/lib/libsupc++.a libtool: install: i686-lfs-linux-gnu-ranlib /tools/lib/libsupc++.a ../libtool: line 1132: i686-lfs-linux-gnu-ranlib: command not found From memory, Louis was using x86_64 so the problem appears to be related to ubuntu-derived hosts, but on both architectures. What do 'ldd' and 'ls -l' report for /tools/bin/i686-lfs-linux-gnu-ranlib ? I'm expecting sensible results (all libraries present, and file is executable), but something unexpected is happening somewhere. make[2]: *** [install-toolexeclibLTLIBRARIES] Error 127 make[2]: Leaving directory `/mnt/lfs/sources/gcc-build/libsupc++' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/mnt/lfs/sources/gcc-build/libsupc++' make: *** [install-recursive] Error 1 I've checked and i686-lfs-linux-gnu-gcc-ranlib IS under /tools/bin. I'm building with host Ubuntu 12.04, I've checked the host requirements and are all OK (i think), in particular: - /bin/sh points to bash not dash - /usr/bin/yacc - /etc/alternatives/yacc - /usr/bin/bison.yacc with bison.yacc being the following simple script: #! /bin/sh exec '/usr/bin/bison' -y $@ .bashrc file of lfs user has $LFS variable well defined, /tools directory is a symlink to $LFS/tools and $PATH has first /tools/bin. I think we were hoping that if Louis started again with /bin/sh pointing to /bin/bash, it would fix it. That seemed a plausible hope, because the initial configure in the top level directory will use its shell and it converts variables which may then be used by configure scripts in other directories. Dash is known to be less powerful than bash and has often broken with constructs which work fine in bash. Oh well, something else must be involved. sigh/ In case you find it useful, I'm including the errors in the config.log after configure Libstdc++-4.8.1, located in $LFS/sources/gcc-build. Not sure what they mean or if they are related to the issue (yes, I untar'ed gcc package again to build libstdc++): Just to confirm : you removed the original gcc-4.8.1 and gcc-build directories before doing that ? lfs@tornasol:/mnt/lfs/sources/gcc-build$ cat config.log | grep -i error i686-lfs-linux-gnu-gcc: error: unrecognized command line option '-V' i686-lfs-linux-gnu-gcc: fatal error: no input files i686-lfs-linux-gnu-gcc: error: unrecognized command line option '-qversion' i686-lfs-linux-gnu-gcc: fatal error: no input files i686-lfs-linux-gnu-g++: error: unrecognized command line option '-V' i686-lfs-linux-gnu-g++: fatal error: no input files i686-lfs-linux-gnu-g++: error: unrecognized command line option '-qversion' i686-lfs-linux-gnu-g++: fatal error: no input files conftest.c:9:28: fatal error: ac_nonexistent.h: No such file or directory conftest.c:9:28: fatal error: ac_nonexistent.h: No such file or directory collect2: error: ld returned 1 exit status | /* Override any GCC internal prototype to avoid an error. collect2: error: ld returned 1 exit status All these sorts of messages seem absolutely normal. Configure scripts are run by /bin/sh and most of them mainly do two things: (i.) generate program fragments and try to compile them - this determines if headers / libraries exist, or if certain things exist in certain functions: that is what you see above, and is all part of adapting the build to different systems (not just linux) or different architectures (ii.) they use pkg-config to find if a package exists, and how to compile against it. And then, at the end of configure, they use the settings to alter how Makefiles will be created. glibcxx_cv_system_error14=yes glibcxx_cv_system_error15=yes These sort of variables might be used in the creation of the various Makefiles ERROR_CONSTANTS_SRCDIR='config/os/generic' WERROR='' #define HAVE_STRERROR_L 1 #define HAVE_STRERROR_R 1 These sort of variables definitely get used in the creation of
Re: [lfs-support] 5.8 Libstdc++4.8.1 compilation error also on 32-bits architecture
On Wed, Jan 22, 2014 at 12:23:26AM +, Ken Moffat wrote:
On Tue, Jan 21, 2014 at 09:53:03PM +, Enrique Larraia wrote:
Your error was
libtool: install: chmod 644 /tools/lib/libsupc++.a
libtool: install: i686-lfs-linux-gnu-ranlib /tools/lib/libsupc++.a
../libtool: line 1132: i686-lfs-linux-gnu-ranlib: command not
found
I got sufficiently interested by this to try building LFS-7.4 on my
i686 7.4 system, using copy-and-paste. Fortunately (although
perhaps discouragingly for Enrique) this isn't very far into the
build.
That appears to be using a libtool script. I don't recall if it is
within the gcc-build directory, or the gcc-4.8.1 source - or even in
a subdirectory. But I guess it is in the top level of gcc-build (if
I'm wrong you'll need to search for it), and perhaps created from a
file in the gcc source by using sed on variables.
OK, so I overlooked that we are now only trying to build and
install in libstdc++. The libtool script is gcc-build/libtool.
What is the first line of this libtool script ? (I'm guessing it
will be something like #!/bin/sh or #!/bin/bash ?
Mine starts #! /bin/sh so the /bin/sh symlink to /bin/bash is
indeed important. Let's try rechecking, in case something in
ubuntu-land is making the symlink disappear (unlikely, but when the
obvious fails, never discount things).
I get
lfs:/mnt/lfs/sources/gcc-build$ file /bin/sh
/bin/sh: symbolic link to `bash'
lfs:/mnt/lfs/sources/gcc-build$ /bin/sh --version
GNU bash, version 4.2.45(1)-release (i686-pc-linux-gnu)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
You are almost certainly using a different version of bash, please
can you compare your results for those two commands ?
At this point, I'm expecting that the /bin/sh - bash symlink is
NOT effective - but that is guesswork, and I don't know why it would
happen.
If your /bin/sh is any version of bash-4.2, please try what I've
written below.
Can you paste the lines around line 1132 where it is invoking this
command ? I'm not sure if the ranlib (i686-lfs-linux-gnu-ranlib) is
hard-coded in the libtool script [ i.e. something got processed by
the shell to create this libtool script ], or if it is using
variables.
In fact, that is a chunk within a function which looks like this:
# func_show_eval cmd [fail_exp]
# Unless opt_silent is true, then output CMD. Then, if opt_dryrun
# is
# not true, evaluate CMD. If the evaluation of CMD fails, and
# FAIL_EXP
# is given, then evaluate it.
func_show_eval ()
{
my_cmd=$1
my_fail_exp=${2-:}
${opt_silent-false} || {
func_quote_for_expand $my_cmd
eval func_echo $func_quote_for_expand_result
}
if ${opt_dry_run-false}; then :; else
eval $my_cmd
^ this is line 1132
my_status=$?
if test $my_status -eq 0; then :; else
eval (exit $my_status); $my_fail_exp
fi
fi
}
So we can see that either the function is being misparsed (perhaps
the local variables give a problem), or else the command is simply
not being found.
In the previous case (x86_64) I think we established that the
ranlib WAS on the PATH, but let's check in your case that things are
correct. Here are my commands and results -
lfs:/mnt/lfs/sources/gcc-build$ echo $PATH
/tools/bin:/bin:/usr/bin
lfs:/mnt/lfs/sources/gcc-build$ type -pa i686-lfs-linux-gnu-ranlib
/tools/bin/i686-lfs-linux-gnu-ranlib
lfs:/mnt/lfs/sources/gcc-build$ ldd $(type -pa
i686-lfs-linux-gnu-ranlib)
linux-gate.so.1 (0xe000)
libz.so.1 = /lib/libz.so.1 (0xb7701000)
libc.so.6 = /lib/libc.so.6 (0xb754c000)
/lib/ld-linux.so.2 (0xb772d000)
And if your results really do match all of mine, I think I need a
very stiff drink ;-)
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] 5.8 Libstdc++-4.8.1
On Sat, Jan 18, 2014 at 01:28:58PM +, akhiezer wrote: Date: Fri, 17 Jan 2014 22:17:42 -0600 From: Louis Rine louisr...@gmail.com To: LFS Support List lfs-support@linuxfromscratch.org Subject: Re: [lfs-support] 5.8 Libstdc++-4.8.1 . . Anyway, as for those sanity checks: $ ls -laF /tools/bin/x86_64-lfs-linux-gnu-ranlib -rwxr-xr-x 2 root root 5204187 Jan 17 18:29 /tools/bin/x86_64-lfs-linux-gnu-ranlib* OK. Size looks very large, even re cross- stuff; not near a machine to check just now. Just a side-note that this size isn't totally out of order, I got 4.6M on x86_64-lfs-linux-gnu- on a gcc-4.8.1 host with CFLAGS unset and the file not stripped. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 5.8 Libstdc++-4.8.1
On Thu, Jan 16, 2014 at 04:23:51PM -0600, Louis Rine wrote: Hello all. :) I'v gone through the book a couple times in the past on i686, but this is my first time around with x86_64. All seemed to go well until I ran into this little gem while installing libstdc++: ...lots of compilation output... Making install in libsupc++ make[1]: Entering directory `/mnt/lfs/sources/gcc-build/libsupc++' make[2]: Entering directory `/mnt/lfs/sources/gcc-build/libsupc++' test -z /tools/lib/../lib64 || /bin/mkdir -p /tools/lib/../lib64 /bin/bash ../libtool --mode=install /usr/bin/install -c libsupc++.la '/tools/lib/../lib64' libtool: install: /usr/bin/install -c .libs/libsupc++.lai /tools/lib/../lib64/libsupc++.la libtool: install: /usr/bin/install -c .libs/libsupc++.a /tools/lib/../lib64/libsupc++.a libtool: install: chmod 644 /tools/lib/../lib64/libsupc++.a libtool: install: x86_64-lfs-linux-gnu-ranlib /tools/lib/../lib64/libsupc++.a *../libtool: line 1132: x86_64-lfs-linux-gnu-ranlib: command not found* make[2]: *** [install-toolexeclibLTLIBRARIES] Error 127 make[2]: Leaving directory `/mnt/lfs/sources/gcc-build/libsupc++' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/mnt/lfs/sources/gcc-build/libsupc++' make: *** [install-recursive] Error 1 I checked in /tools/bin, and indeed x86_64-lfs-linux-gnu-ranlib IS there, along with the other stuff that should be there. The lfs user environment seems to be all set up correctly, including $PATH which is /tools/bin:/bin:/usr/bin. Perhaps /tools/bin/x86_64-lfs-linux-gnu-ranlib is broken. What does 'ldd' say about it ? What host system are you using, and did you check all the host system requirements ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 5.8 Libstdc++-4.8.1
On Thu, Jan 16, 2014 at 05:47:42PM -0600, Louis Rine wrote: If this is the correct use of ldd... :~$ ldd /tools/bin/x86_64-lfs-linux-gnu-ranlib linux-vdso.so.1 = (0x7fffa837b000) libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7ff874f03000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7ff874b3a000) /lib64/ld-linux-x86-64.so.2 (0x7ff87511a000) Not sure how to tell if that output is correct... Looks ok : no such file can mean broken linkage, but not in this case. I'm using netrunner 13.06 which is based on ubuntu 12 I think? host system requirements check scripts gives the following :~$ ~/code/lfs/version-check.sh bash, version 4.2.45(1)-release /bin/sh - /bin/dash Fix that - dash causes problems in all sorts of places. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Proposed Changes to LFS Book
On Tue, Jan 14, 2014 at 03:50:47PM -0500, alex lupu wrote: Dear Development LFS Book Administrators: For development, you ought to post to lfs-dev, but you'll need to subscribe before you do that. The devs (primarily Bruce and Matt) might read this here, I'm not sure. I would like to submit for your consideration the following changes to the Section III. 6.7. Linux-3.12.6 API Headers of the Linux From Scratch - Version SVN-20140102 book. 1. After the paragraph ..: This is done by way of sanitizing various C header files that are shipped in the Linux kernel source tarball., I would insert: Note: For the meaning of the action sanitizing (in this context), run command sh scripts/headers_install.sh | sed s/echo// and in the output read the section between Prepares and keywords. (output, lines 3-6). I don't find that helpful. At all. 2. After section They are placed in an intermediate local , I would insert: subdirectory (named by us, 'dest', in the command below) If the user does not understand that we are creating a directory called 'dest' then LFS is probably too hard for them. In everything, a balance is needed between explaining and teaching your grandmother to suck eggs. 3. After copied to the needed location, I would change to copied to the intended user-space standard location, '/usr/include/...' Again, that should be obvious from the command. 4. I would change the command cp -rv dest/include/* /usr/include to cp -prv dest/include/* /usr/include That would synchronize the file times in the '/usr/inlude/' tree to the times of the files created in the kernel directory on running the command 'make headers_install', and not assign them an arbitrary time when I get around to run the copy after taking out the garbage and then getting a well deserved rest before being finally able to complete the procedure :) So, you think that the time(s) when the files were initially created in dest/ are more important than the times when they were finally installed to /usr ? Why ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Proposed Changes to LFS Book
On Wed, Jan 15, 2014 at 04:51:23PM +, Ken Moffat wrote: On Tue, Jan 14, 2014 at 03:50:47PM -0500, alex lupu wrote: I would like to submit for your consideration the following changes to the Section III. 6.7. Linux-3.12.6 API Headers of the Linux From Scratch - Version SVN-20140102 book. 1. After the paragraph ..: This is done by way of sanitizing various C header files that are shipped in the Linux kernel source tarball., I would insert: Note: For the meaning of the action sanitizing (in this context), run command sh scripts/headers_install.sh | sed s/echo// and in the output read the section between Prepares and keywords. (output, lines 3-6). I don't find that helpful. At all. Please note that I'm not intending to shut you off here - _I_ know what is meant by sanitizing the headers (or, I think I do), but the book doesn't go into any detail. Maybe we ought to change the chapter 5 reference to 'sanitizing' (5.6) - that is where we first mention it. At the moment we say This is done by way of sanitizing various C header files that are shipped in the Linux kernel source tarball. perhaps change to ... source tarball (to make them fit for use by userspace applications). But I've been doing this stuff for years, back to the days of linux-libc-headers and clfs's own attempt. Not sure if my wording would add anything useful for new readers, or if it would just sow confusion. And anyway, I'm too busy to do any development at the moment. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Section 5.5.1 GCC-4.8.1 'make'
On Sun, Jan 12, 2014 at 04:00:04PM -0500, William Darryl Jackson wrote: Hello again, In the GCC first pass section 5.5.1 page 38 - I received the following compile error: checking for i686-lfs-linux-gnu-gcc... /mnt/lfs/sources/gcc-build/./gcc/xgcc -B/mnt/lfs/sources/gcc-build/./gcc/ -B/tools/i686-lfs-linux-gnu/bin/ -B/tools/i686-lfs-linux-gnu/lib/ -isystem /tools/i686-lfs-linux-gnu/include -isystem /tools/i686-lfs-linux-gnu/sys-include checking for suffix of object files... configure: error: in `/mnt/lfs/sources/gcc-build/i686-lfs-linux-gnu/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. ^^ Open config.log in 'less' or 'view', search for the error message - /cannot\ compute\ suffix\ ofenter Then look at the lines above that - there will be some sort of compile or link error message. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] folder permissions
On Sat, Jan 11, 2014 at 03:14:38PM -0500, William Darryl Jackson wrote: On 01/11/2014 02:51 PM, Chris Staub wrote: On 01/11/14 14:47, William Darryl Jackson wrote: On 01/11/2014 02:33 PM, Chris Staub wrote: Your output says there is something mounted on /media/lfs, yet you keep saying you are assigning LFS=/mnt/lfs. I was trying to follow the instructions precisely. I agree this seems to be the cause of the problem. This is an external drive that auto mounts to the (user) media folder, and (root) dev folder. The only reason it says media/lfs is because I added a label in gparted. Debian is using uuid identifiers - which is causing me problems. Would it help if I replaced LFS=/mnt/lfs with something else? Also, I have 2 partitions on that external drive. They both mount showing 500GB, when the drive is only 500GB. Thanks. Using automounting for where you intend to build LFS is probably a bad idea. Actually, in my personal view automounting is always a bad idea : I don't expect the system to try to second-guess what I want to do ;) You need to be root at certain places in the LFS build, so you might as well be root to mount /mnt/lfs. Just remember to become user LFS when the book does. We used to have certain things which _required_ /mnt/lfs, now I believe you can mount the build anywhere and have a reasonable chance of success if you make the consequential changes. But if it breaks, you get to keep both pieces. So, /mnt/lfs is what we recommend. Sorry, but if you really need to ask this, LFS is just too advanced for you. I suggest going here - http://www.linuxfromscratch.org/lfs/view/7.4/prologue/prerequisites.html - for starters, and learning about how to actually use Linux, especially on the command line, before attempting something like LFS. That was a bit harsh. I have been using command line for 3 years. That is long enough for me to attempt to learn more about Linux, which is what I thought LFS is all about. I have learned enough now to not bother the list with silly questions. I _will_ reiterate that you seem to have a fundamental problem with how you are mounting the external drive : each partition should be smaller than the total size of the drive, and when both are mounted you ought to be able to see different partition numbers, and sizes, in the output from 'mount' and 'df'. Debugging this problem for yourself will help you when it comes to other problems with your new LFS system. LFS *is* about learning linux - but mostly in the sense of how the various packages fit together to produce a usable minimalist system. By paying attention to the details of how each package is built, you will perhaps learn a little about how to use sed and patch. But other common tools will only get brief mentions. I think awk probably gets used in checking the host requirements. Some people have apparently built LFS to learn linux- for me, that would have been unnecessarily difficult. Read the links Chris pointed to, read the book _before_ you try to follow it (to get an overview of what is to be done), and then if you think you are ready, please check the host requirements. I will also add that I recommend that people build and install a kernel before trying LFS (in situations where that is possible) - i.e. use an upstream kernel, come up with a .config which boots *without* an initrd [ build in the root filesystem and whatever you need for your disk drives ], test, strip things out and/or add other things until the kernel both boots and does everything you need it to do. For this, edit /boot/grub.cfg as root [ review what the book says for kernel configs ] AND add your own identifier in the EXTRAVERSION so that a later rebuild to get a better config will not overwrite the modules from the current attempt. Of course, some people leave the fun of finding a useful kernel config until they have completed LFS. Personally, I find it a lot easier to debug any problems on my own builds (yes, I still get boot problems) - mostly from upgrades to the BLFS packages which I build before I boot, e.g. for nfs, but I can still remember that I had issues when I updated my (very) old server system to LFS-6.8 because of config changes I had forgotten about over the years - if the kernel .config is known good : people get all sorts of one-off problems when building LFS for the first time, e.g. by botching one of the packages [ /me scowls at ncurses and libz ]. And if you do get more problems when you are building LFS, please mention where you are in the book when you ask for advice. Have fun, building and booting LFS isn't about ticking boxes on a ToDo list. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Chapter 5.7 glibc-2.1{7,8}
On Sat, Jan 11, 2014 at 10:29:41PM +0100, Frans de Boer wrote: Your right of course, that is the only exception. I always use a build directory within the source tree. I has always worked before...until I tried now using a build directory outside the source tree! Behold, it is now working. Never had this experience before, but will follow the direction to have a build directory OUTSIDE the source tree!! Just curious, since it had always worked before, why is it required to have a build dir outside the source tree? Is there a dependency of some sort? Regards, Frans. The book has always [1] used separate build directories for binutils, gcc, glibc. I imagine that you got lucky when a build directory in the source tree worked. Perhaps, in the days when LFS was only i?86, we were unnecessarily cautious in following what upstream recommended. But doing it that way has always worked. 1. Since at least late 2005, when gcc-4 came out. I think we did that even when I first got here (for LFS-3) but I don't now have my scripts before late 2005, and I can't connect to the lfs-museum at the moment. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Static versus Shared libraries
On Mon, Dec 30, 2013 at 11:29:34PM +0100, Frans de Boer wrote: Dear reader, While building things again, I now start to wonder why LFS let almost every package installs a static library? Where are the static libraries used? They can sometimes be used if you mis-install one of the packages :-) More so on 32-bit x86 - x86_64 is more likely to fail to link static libs into shared executables because it requires -fPIC. Obviously, using something to suppress the static libs in your own package management will highlight any places where this happens! I append .hidden to all non-toolchain /usr/lib/lib*.a files at the end of my package installs. More likely, _some_ of the toolchain libs _might_ be required to run configure scripts. I've never found enough time to test this. I did hide a few unlikely to be needed static toolchain libs, but others such as libc.a seem likely to be generally used, at least in configure scripts. Or, as Bruce's reply probably pointed to (I didn't read his link) - for development. After all, the down side of static libraries is that once linked into a module/program, any upgrade is not incorporated. Potentially leaving modules/programs vulnerable to manipulation. In general, please be aware that --disable-static does not always work. More importantly, some libs are not in fixed versions, so the static version is theoretically required (e.g. PAM needs a static lib from flex - I got a dirty workaround from our late colleague Andy to convert any .a to .so, but that might not be a good idea when things can change because they have not been versioned). Also, in BLFS tcl and tk require their static stub libs, and firefox / xulrunner require libcrmf.a which in my systems comes from standalone nss. I now remember there is at least one static lib in kde. And probably others in packages I don't care about. It is listed that only a very few use some static libraries and others are not mentioned. I know, disk space is not an issue nowadays, but still it needs to be maintained and dependencies are not listed anyhow. Can someone shed some light on this issue? Regards, Frans. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page I think many LFS/BLFS builders don't care about these sort of problems. It was a tedious buisness to disable static libs in BLFS. Fortunately, those of us who care can fix the parts we care about on our own systems (so yes, I could test if my remaining static toolchain libs are really needed, but it hasn't yet proved important enough to me : if I need to rebuild the toolchain, I upgrade LFS). ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFS 7.4 Patching Perl
On Wed, Dec 25, 2013 at 10:44:38AM -0500, Bob Elgie wrote: My apologies if I'm blindly overlooking something obvious. Among the patches needed to build 7.4 is a Perl libc patch. I can't see where this patch is applied; it is not mentioned in chapter 6.39. The only place I find instructions to apply it is in the French version of the svn build. Should the patch be applied at all, and if so, where would that happen if not in 6.39? Thanks. Bob Elgie You are looking at the wrong chapter! We use it in chapter 5. Please read the patch, including the description. We use it so that perl will work when we enter chroot using /tools/libc.so and /tools/bin/gcc. It is specific to how we build LFS in chroot, the new system doesn need this workaround. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Configuring 3.10.10 for quad-core processor
On Wed, Dec 04, 2013 at 02:46:47PM -0600, William Harrington wrote: On Dec 4, 2013, at 1:49 PM, Dan McGhee wrote: AMD-10-5745M Have you used the powernow-k8 driver and have SMP enabled? http://cateee.net/lkddb/web-lkddb/X86_POWERNOW_K8.html Sincerely, WIlliam Harrington Powernow is for cpufreq (a good thing to use, IMHO, but not mentioned in LFS) and not used anymore for K10 and newer CPUs (the support is now in acpi-cpufreq). From memory, the initial K10 was the athlon64xII. My git-foo isn't good enough to identify which release that happened in, but the indications are that it was well before 3.10. SMP is the key. If Dan is building only for that machine (and doesn't intend to use the system to boot any replacement machine when the time comes) then optimizing for the specific processor family, i.e. AMD x86_64 (Opteron/Athlon/Hammer/K8 : this is CONFIG_MK8 but works on K10 ;-) might gain a little, as might Multi-Core Scheduler support. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFS-7.4
On Fri, Nov 29, 2013 at 11:35:19AM -0600, Bruce Dubbs wrote: Baho Utot wrote: Is it possible to build LFS-7.4 on x86_64 without the /lib64 symlink? I have tried to do so but libstd++ in the chapter 5 tool chain dies. I would like to build for x86_64 and have the same filesystem layout that i686 has ie without the lib64 directories I really don't know but I can make some guesses. uname --machine gives x86_64. I wouldn't be suprised if some packages that assume a multilib system use that value to insist on /lib64 or /usr/lib64. -- Bruce Cross-LFS has always done that for pure64. It's a _long_ while since I last built clfs x86_64-64 and many things have changed, but the main difference is that clfs still uses a specfile - their build is now quite different from how LFS has evolved. If you do something like that, then yes, a few _blfs_ packages will probably get confused by the absence of /lib64. OTOH, you would get a nice clean system - but the build for x86_64 will be somewhat different from what is currently in LFS. I've a feeling that someone, perhaps our late colleague Andy, used to build 64-bit LFS without the symlink - but I've no idea of the details about how to do it (and that was before libstdc++ and g++ became required for building gcc, so the details would have to change for gcc-4.8). This message will self-destruct in 5 seconds. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Ethernet Card Not Found
On Mon, Nov 25, 2013 at 07:44:16PM -0500, Alan Feuerbacher wrote: Apparently things in the linux world have changed recently with respect to naming devices generally, so that old conventions like eth0 have been replaced by conventions that are said to make more sense. I suppose enp3s0 makes sense to some people, but eth0 makes more sense to a non-expert like me. If you don't want to run Lennart-from-scratch, this is what I use to get back to a sane name - # fix the ecpXsY ethernet naming echo # dummy, so that network is once again on eth0 /etc/udev/rules.d/80-net-name-slot.rules Strictly, just creating an empty file with that name will solve the problem - but empty files are fragile and their meaning is likely to be forgotten! This fixes the major abomination since udev was merged into systemd - that undesirable change is now also in eudev and Bruce's udev-from-systemd. I leave it to the people drinking Lennart's kool-aid to explain why names such as enp3s0 are saner than eth0! ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Ethernet Card Not Found
On Sun, Nov 24, 2013 at 09:33:54AM -0600, Bruce Dubbs wrote: Alan Feuerbacher wrote: On 11/24/2013 12:19 AM, Bruce Dubbs wrote: Alan Feuerbacher wrote: Can anyone clue me in? It sounds like you don't have the right ethernet driver built. We recommend building it into the kernel. Ok, then I must have missed something when building the system. What do I look for in the LFS book to build the right ethernet driver? Bring up a working system and run lsmod. We have no way to tell what hardware you have, but we do refer to several references on configuring a kernel in Section 8.3. I think Alan needs the r8169, this is what I use : CONFIG_NET_VENDOR_REALTEK=y and CONFIG_R8169=m (actually 'y' would be better, i.e. faster to come up) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Error: invalid file name When Booting For the First Time
On Sat, Nov 23, 2013 at 02:32:47PM -0500, Alan Feuerbacher wrote: In grub.cfg, why is the root in the line set root=(hd1,1) different from the root in the line linux /vmlinuz-3.12-lfs-SVN-20131119 root=/dev/sdb3 ro? In other terms I have: /dev/sdb1 - /boot /dev/sdb3 - / I'm really fuzzy about this stuff. They are totally different things. Grub purports to be a universal bootloader, and there is no consistent way of naming disk devices across different systems, so it uses its own names. For the linux kernel bootargs, root= expresses which partition to load for '/', using the linux kernel's naming system. At any rate, I recompiled the kernel and reinstalled the grub stuff. I'm still getting an error: error: file '/vmlinuz-3.12-lfs-SVN-20131119' not found. I invoked the grub command line to see what I could see: ls = (hd0) ... (hd1) (hd1,msdos2) (hd1,msdos1) (hd2) So grub apparently sees my disk /dev/sdb as (hd1). Next I tried: ls (hd1) = Device hd1: No known filesystem detected - Total size 3907029168 sectors I also tried this with (hd0) and (hd2). Same response: no filesystem detected. So for whatever reason, grub is not recognizing the disks. Having tried the same thing with the two other disks, /dev/sda and /dev/sdc, which grub lists above as (hd0) and (hd2), I'm at a loss. All three of these disks are in operation, since when I fire up Fedora19 on /dev/sda, I can write to and read from all of the disks. Any ideas? Alan How about ls (hd1,1) ? hd0 and hd1 are the whole disk, what you need to look at is a partition. I've also got a much-less-important comment on your kernel names as a reply to your earlier post: You had four variants of 3.12 lfs kernels. All of them had the same size in bytes, one was from nearly two days before the rest, of the others two had the same time and the other was a second later. To me, that looks unusual : Mostly, a fresh build with different options will produce a kernel with a slightly different size. It's not impossible that minor changes might produce same-size binaries, but obviously with different md5sums. But when I see three kernels with essentially the same time I start to worry - I don't think even the fastest machines can produce an updated kernel so quickly. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] /dev/fb0 not being created on boot
On Fri, Nov 22, 2013 at 07:05:14PM +, Richard Melville wrote: Ken, I'm using vesafb on a web server with no Xorg, and I just use the console. I realise that my kernel was quite old but as I like to check every configuration option (often because of new hardware) it takes a long time to configure a new kernel and becomes incredibly boring towards the end :-( Therefore, I usually limit my upgrades to about one per year, or when I can be bothered. OK, but in that case I suggest that you go for early stable kernels (.1, .2, etc). You said you had been using 3.7-rc8 - that probably turned out to be totally good for your uses, but sometimes even .0 releases still have issues in a few places. Also, the config you use in a late -rc will normally not provide any extra questions for released / stable kernels in the same series if you use 'make oldconfig'. Bruce, my framebuffer config was much like yours but with one exception: I had CONFIG_X86_SYSFB=y. This was stopping vesafb loading and stopping /dev/fb0 being created. I've removed that option, reconfigured, and now it all works as expected. Interesting. That option works ok on intel (I'm running with it at the moment), I'll try to remember that for the future - my server also runs with CONFIG_FB_VESA and vga=792 (it's a radeon RS780, when I got it I had no experience with modern ATI hardware and totally failed to get the radeon framebuffer to work - 80x25 is too restrictive for me!) - for the moment I'm running 3.10 (LTS) there. Regarding vga=792, that still works for me. If I substitute video=1024x768 the command is ignored an I get a large, ugly font. I'm currently using grub-2.0, so I can't understand what the problem is likely to be. Any ideas? Richard Stick with vga=792 since it still works ? Any idea how large the font is, or how many pixels in the screen size when you boot with video=1024x768 ? When the box boots, you get the font from its bios. But when the LFS bootscripts start to run it ought to switch to your specified font (provided the setup supports it, e.g. my own 12x22 is only supported on framebuffers and I've not tried it with Vesa, my screen there is physically 1024x768 so I use an 8x16 font on that). So, basically work out what sort of console font *size* will suit you, then try setfont in a spare tty and see if any of the available fonts look ok _and_ provide the character coverage you require. My own LatGrkCyr are intended for white/pale text on a black background and I'm told that at least one of them looks awful with dark text on a pale background : there is a balance between getting adequate coverage, shapes which do not offend our own particular sensibilities, and being able to distinguish the various accents and diacritical markings - for some uses, noting that a glyph is e.g. letter a with accent may be good enough, but others may wish to be able to see at a glance what sort of accent is present, particularly in unfamiliar languages. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFS 7.3 Screen Flickering problem
On Fri, Nov 22, 2013 at 09:17:16AM -0600, Douglas R. Reno wrote: Hello, After completing a successful build of LFS, I restart to get into the system for the first time and my screen turns black and then comes back on for about 1 second. I have a NVidia Vanta LT card in my PC. I am using the Nouveau drivers for the framebuffer, as I plan to install X. I have Nouveau configured as well in the kernel. I can tell that the system booted successfully, Excuse me for being a pedant, but *how* do you tell that the system booted successfully ? If you have been back to chroot and managed to read logs, then yes, it booted and there might be a message somewhere in the log (search for 'nouveau' or 'framebuffer'). If you haven't got logs, then here is my impression of what is happening: Grub passes control to your new kernel - screen goes black, initial messages appear using probably an 80x25 vga console, then it tries to switch to the framebuffer console and goes black. Are the framebuffer and KMS options built in to the kernel, or as modules ? If you leave it for 60 seconds, does it give you any error message and then procede ? If you leave it for 180+ seconds (I suggest trying something a little longer, e.g. 5 minutes, just to be sure) does it reboot ? The first would probably be related to either failing to load a module, or failing to load firmware and the message ought to provide an indication of what is needed. The reboot after 3+ minutes would indicate it oopsed and tried to kill init. but I have already tried various options in kernel configuration (such as Generic VESA). I would also like to keep my bootlogo, but I am willing to remove it if necessary. If you mean the penguin(s), it/they come with the framebuffer and KMS requires a framebuffer. For a recent kernel using KMS, you should enable CONFIG_FRAMEBUFFER_CONSOLE and the appropriate DRM entry, but NONE of the Frame buffer hardware_drivers [ CONFIG_FB_CIRRUS...SIMPLE ] should not be set. The system appears to have issues detecting the card because of the resolution (it stays at about 640x480). I have booted several LiveCDs (Ubuntu and System Rescue CD) successfully without this problem. Host: System Rescue CD (added bison to image) NOTE: this system is i686 Compaq Presario 5230us if that helps. Thank you, Douglas Reno ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Radeon Extra Firmware [WAS: Boot Failure with wlan0 firmware]
On Fri, Nov 22, 2013 at 09:38:59AM -0600, Dan McGhee wrote: I'm asking this question because I really want to re-build my kernel only once. My LFS kernel is looking for ARUBA_pfp.bin and TAHITI_uvd.bin. In '/linux-firmware/radeon I have the same three ARUBA files that you have indicated. So, obviously, I'll put them in /lib/firmware and indicate them in the extra_firmware line. When it comes to TAHITI though, I have the -uvd.bin, but also _ce.bin, _mc.bin, _me.bin, _pfp.bin, _rlc.bin and _smc.bin. Do you know if I need all those TAHITI files, or should I just put them in to be safe and not have to reconfigure my kernel again, and again, and again? I'm very far from an expert on firmware, but on my modern machines with reasonably-stripped-down configs it doesn't take _too_ long to rebuild a kernel. For trying to identify what is needed on a (desktop) radeon, I usually use the gentoo wiki: https://wiki.gentoo.org/wiki/Radeon Just above the 'Driver' section [ gentoo-specific ] is a table with columns for Family, Chipset name, Product name, Firmware - I see that page has been updated since I last needed to look at it: the Sea Islands and Volcanic Islands families are new to me, so I assume that whatever it specifies is current. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFS 7.3 Screen Flickering problem
On Fri, Nov 22, 2013 at 02:54:34PM -0600, Douglas R. Reno wrote: Ken, The screen turns on and off repeatedly... I can see some text when it is on. That is how I can tell it booted successfully because I can see the login prompt for a split second. I also have logs in /var/log. Good. I've never come across one like that, but from what you say below I guess that more than one framebuffer driver is becoming active and they are fighting. Looking at the Kernel Options that you suggested (I keep a backup of my .config on a USB drive), I do believe that I enabled the frame buffer drivers... I will disable those when I get to the machine tonight. And yes, I mean the penguin (it is technically a waste of screen space, but I think it looks cool) Douglas Reno I don't agree it's a waste of space because it only lasts for a little while and then everything scrolls up over it. Perhaps a waste of kernel memory, but amusing - how else would be have seen the Linux for Workgroups penguin in 3.11 ;-) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] umount: mountpoint not found - SOLVED
On Fri, Oct 25, 2013 at 12:21:02AM +0100, Ken Moffat wrote: On Thu, Oct 24, 2013 at 05:59:52PM -0500, Bruce Dubbs wrote: Ken Moffat wrote: I first noticed this on my desktop which is running LFS-svn with make-4.0, and where I've got more than enough other things still to look at. But on my server running 7.4 I've just done: mount /scratch [ /me does something there ] umount /scratch which returns - umount: /scratch: mountpoint not found and /scratch is still mounted. Any ideas about what is going on, please ? No, but you can always 'umount /dev/sd??' -- Bruce Well, root can, so thanks for that (all too often, I'm too close to the problem and can't see the wood for the trees). - /scratch is where I use the spare space from modern disks : it doesn't get backed up [ what a waste of space that would be! ] and either ken or lfs can use it - or indeed /root when updating the system. One day, I suppose I'll find out what else needs to be changed so that users can umount it again. Ah, the wonders of being on the bleeding edge and looking for guidance before anyone else has had the problem :) Arch also suffered this and one of their devs fixed it: http://marc.info/?l=util-linux-ngm=137945227914961w=2 That commit is in util-linux-2.24, which works for me. I'm not sure if the problem also applied to 2.23.1 (I don't have any systems using that), but 2.23 was OK. ĸen, currently upgrading all my 7.4-and-newer systems. -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] umount: mountpoint not found - SOLVED
On Sun, Nov 17, 2013 at 05:35:32PM +, Ken Moffat wrote: That commit is in util-linux-2.24, which works for me. I'm not sure if the problem also applied to 2.23.1 (I don't have any systems using that), but 2.23 was OK. ĸen, currently upgrading all my 7.4-and-newer systems. After further testing, all 6 of my x86_64 systems (4 machines) showed the problem, but my sole i686 (and also my ppc-32) did not. The commit message from Dave Reisner at Arch says When unmounting some mountpoints as an unprivileged user (via the 'user' option in fstab), the umount fails. I'm now guessing that some might mean x86_64. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Help with Installing to UEFI Motherboard
On Sun, Nov 17, 2013 at 05:02:09PM -0600, Dan McGhee wrote: I don't know how, or even if, the distros have modified GRUB in their packages. I remember reading something that said fedora's grub is very different from upstream. Try using cgit to see what fedora are doing [ use a graphical browser ]. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Help with Installing to UEFI Motherboard
On Sun, Nov 17, 2013 at 05:10:57PM -0500, Alan Feuerbacher wrote: On 11/16/2013 6:10 PM, Dan McGhee wrote: The kernel. It dies with a message like ... kernel panic ... Must you do a hard reset to start over or can you use ALT-CTRL-DEL? I have to recycle the power. With your later comment about today's setback, this suggestion is irrelevant unless/until you can get back to this state. But if you manage to recover to there, please see if any indications of what is wrong get to the screen. If anything useful is there (i.e. not scrolled off), google it just in case someone has found a fix. If not, my first suggestion is to try newer kernels. This sounds very like the sort of thing that was discussed in the various lkml threads about EFI/UEFI I alluded to when replying to Dan in the past month (a change which fixes some machines breaks others). I suggest that you start by trying 3.12.0. No idea if anything there will fix it, but it is current. I normally don't recommend people try early -rc kernels, and 3.13-rc1 wasn't even released when I last checked. If you haven't had any success when 3.13-rc1 is released then certainly try it : but expect unrelated breakage in all sorts of weird and wonderful corner cases. So, if 3.12.0 doesn't work I would then try 3.10.0 in case a later fix broke something, and after that perhaps 3.8.0, 3.6.0, 3.4.0 (assuming your glibc --enable-kernel= isn't as aggressive as mine and will let your init run old kernels). IFF you can find something old which boots, you then get to work out what broke it. ĸen, glad to be a luddite using the bios and an MBR - at least until you guys have sorted out what needs to be done. -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Help with Installing to UEFI Motherboard
On Sat, Nov 16, 2013 at 02:04:31PM -0500, Alan Feuerbacher wrote: Hi, After getting the stock LFS system installed, with an MBR type boot installation, I'm experimenting with installing to a UEFI type boot location on a brand new hard drive. I've been reading a lot of online documentation, and have tried a first-cut installation, but am not having success in installing. While I can install the entire set of LFS programs, and a lot of BLFS programs, when I try to boot up, Linux fires up but quickly generates a fatal error. Is there any possibility of advice from the LFS staff? http://www.mail-archive.com/lfs-support@linuxfromscratch.org/ See the posts from Dan McGhee - most recently on 13th November, but starting on 28th October. Four threads, titles mentioning GRUB or EFI. At the moment they are all on the first page at that link, at least in firefox. Our best advice / guesses is in those threads. Dan hasn't cracked it yet, but your hardware might be different. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Shadow
On Sat, Nov 16, 2013 at 07:57:36PM -0500, Alan Feuerbacher wrote: On 11/16/2013 7:43 PM, Nathanial Jones wrote: I would love it if someone could post a link to a mirror or send me the package directly. Check your mail. Alan More generally, http://anduin.linuxfromscratch.org/sources/LFS/lfs-packages/ ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Step 5.4.1 Installation of Cross Binutils errors
On Fri, Nov 15, 2013 at 01:20:06PM +, Vasco Almeida wrote: OK, I did as instructed in your recommendations above, and tried to be as extra careful as ignorance allows. So I am attaching the four logs collected during the 5.4.1 step, for your kind inspection. But when I invoked make install, I got a raft of This is not dpkg install-info anymore, but GNU install-info See the man page for ginstall-info for command line arguments This is not dpkg install-info anymore, but GNU install-info See the man page for ginstall-info for command line arguments This is not dpkg install-info anymore, but GNU install-info See the man page for ginstall-info for command line arguments This is not dpkg install-info anymore, but GNU install-info See the man page for ginstall-info for command line arguments This is not dpkg install-info anymore, but GNU install-info See the man page for ginstall-info for command line arguments which are perhaps not that surprising. They are certainly surprising to _me_, and I don't see them in any of the gzipped logs you attached. Now that we've pointed out the 'Error' that you could not see, please do not attach gzipped logs unless it is essential - a plain text log is readable in many sane mail clients (well, in mutt anyway :) but a .gz has to be extracted before it can be read. Did you type (only, exactly) the commands in the book, and in fresh source and build directories ? Please try again, with fresh source and build directories, and capturing stderr (the 21 stuff) at the places it happens. Those error messages are plain weird for an LFS build. ken (rather than ?en), but ĸen for everyone else - the fonts in console-tools (used by debian distros) are somewhat deficient. -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Step 5.4.1 Installation of Cross Binutils errors
On Thu, Nov 14, 2013 at 10:37:57AM +, Vasco Almeida wrote: 1. On my Ubuntu I should install at least/bison, gawk, g++, m4/ and/makeinfo/ (via apt-get install/packa//ge-name/, assuming these are indeed the names). Yes. For gawk, you might also need to change the 'awk' symlink to point to gawk instead of mawk. 2. Possibly, I should also install/build-essential/. Definitely install this, I think it might pull in some of the others listed above. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] New dovecot page: '--with-...' specs.
On Thu, Nov 14, 2013 at 11:40:42AM +, akhiezer wrote: Hi, On the new dovecot page ( http://www.linuxfromscratch.org/blfs/view/svn/server/dovecot.html), the section 'Command Explanations' lists the five options '--with-ldap' et seq: yet none of them actually appear in the commands. I've noticed a similar thing in several places in blfs74 book. Apols if have missed an earlier discussion on that, but: is this an error in rendering; or is it kindof that those '--with-ldap' c options are really meant as a sort-of subsection concerning other main parameters that the user might want to consider? But in any case, them appearing as-is just looks like it's an error (e.g. has a chunk of text been lopped off the 'configure ...' commmand?), and one repeated elsewhere in the book. They are tagged as option in the xml, instead of command, and different browsers may render them differently. In firefox, the command --disable-static shows in italic monospace, although the directory class overrides that to what I suppose is bold monospace for the moduledir. The options are rendered in normal weight monospace. Yeah, I would prefer italic for options but I'm not touching that stuff (the xml itself) with the proverbial barge-pole. In a related vein, given that four of the above-noted five options are stated to be re auth, could I also recommend noting that (at least) the following auth methods are enabled by default: --with-shadow Build with shadow password support (auto) --with-pam Build with PAM support (auto) --with-bsdauth Build with BSD authentication support (auto) --with-vpopmail Build with vpopmail support (auto) I think it's worth stating that explicitly so that folks can see at-a-glance that dovecot does handle those ( - don't hide its light under a bushel). One of the central considerations, of course, in choosing a pop/imap server is in what authentication methods can it handle, and how it would in this respect integrate with other parts of infrastructure. Sure, folks considering using it seriously, would do their due diligence anyhow and not just make a decision based on a single 3rd-party page (in this case, the blfs page): but still, it doesn't hurt to state it up-front by noting the default methods additional to said list. If something is optional and automatically detected, we don't usually add an explanation of a switch to enable it. Unless an editor thought it was worth mentioning. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] [blfs-support] akamai / osuosl / mailing-list archives (pt. 94)
On Thu, Nov 14, 2013 at 11:53:22AM +, akhiezer wrote: Hi, Could a similar thing (to the Akamai note below) be swung for LFS/BLFS? And likewise, as noted before, for master-mirroring at e.g. osuosl.org? Could be some ways to, inter alia, get the mailing-list archives available again. If you follow the website links for lfs-support you will get to http://linuxfromscratch.org/pipermail/lfs-support/ and the links there point to mail-archive.com Not totally convenient, but a lot better than nothing. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Step 5.4.1 Installation of Cross Binutils errors
On Wed, Nov 13, 2013 at 09:41:33AM +0100, Pierre Labastie wrote: Le 13/11/2013 02:53, Ken Moffat a écrit : On Tue, Nov 12, 2013 at 07:57:30PM -0500, Baho Utot wrote: If you are using bash 4.0 or greater ../path/to/binutils-source/./configure ... | tee myconflog 21 becomes ../path/to/binutils-source/./configure ... | tee myconflog I would change 'becomes' to 'can be changed to' - there is no *requirement* to change a following '21' to a preceding ''. but 21 should be before the `|' anyway : it does not work the same as `'. If you type the command as above, it sends the tee errors to stdout, not the configure errors... Regards Pierre Arghh! Right you are. What was I thinking ? Brown paper bag, please. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Step 5.4.1 Installation of Cross Binutils errors
On Wed, Nov 13, 2013 at 10:52:02AM +, Vasco Almeida wrote: Thank you for your suggestions, Ken. I did check the minimum Host System Requirements when I started off (I am indeed trying to build LFS-7.4 on Ubuntu 12.04), but rechecked them and nothing seems amiss. As for capturing the output, I went about it in two steps: /mnt/lfs/sources/binutils-build$ ../binutils-2.23.2/configure --prefix=/tools --with-sysroot=$LFS --with-lib-path=/tools/lib --target=$LFS_TGT --disable-nls --disable-werror myconflog 21 and, after checking there were no errors in myconflog, followed it with make mymakelog 21. The errors in mymakelog were exactly as reported in my initial post and in my reply to William Harrington. I can send you the log files if you deem it necessary and appropriate. Thank you for your support. Best regards. Vasco Well, I'm pleased that you didn't fall into the trap I accidentally set by putting '21' after the pipe to tee. Also, configure won't report an error if it gets as far as creating the Makefiles - but the results of the various tests which configure runs might be useful iff we can find out what is reported for the error during 'make'. First we need to identify that message. How big is 'mymakelog' ? If it is under 50K, please attach it. If it is bigger, please compress it with gzip and attach the .gz version. My own log [ configure, make, install ] was 259k, but gzipped to 22k so you should be able to attach one or the other without hitting the list's limits. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Step 5.4.1 Installation of Cross Binutils errors
On Tue, Nov 12, 2013 at 11:31:56PM +, Vasco Almeida wrote:
Where do I go from here?
Find the part of the output with the actual 'Error' message (it might
say 'error'). It looks as if the real error was before that warning
about makeinfo. I haven't seen the post where 'make -k' was
recommended (I expect it is taking a slow route to reach me), but in
general you do NOT want to do that in LFS, except when running test
suites.
Since you have barely started, please also check the Host System
Requirements in section Vii of the Preface.
Actually, check the Host System Requirements _first_, then (if
your host meets _all_ of them : newer versions *probably* work for
binutils and gcc), repeat your attempt to compile this, after
removing the existing binutils-2.32.2 (I'm assuming you are trying
to build LFS-7.4) and binutils-build directories.
But this time, capture the output in a log, for example
../path/to/binutils-source/./configure ... | tee myconflog 21
and then
make | tee mybuildlog 21
so that the error messages on stderr ('2') get mixed in. Then look
at the build log in 'view|vim' or 'less' and search for Error [
'/Error' ].
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Step 5.4.1 Installation of Cross Binutils errors
On Tue, Nov 12, 2013 at 07:57:30PM -0500, Baho Utot wrote: If you are using bash 4.0 or greater ../path/to/binutils-source/./configure ... | tee myconflog 21 becomes ../path/to/binutils-source/./configure ... | tee myconflog I would change 'becomes' to 'can be changed to' - there is no *requirement* to change a following '21' to a preceding ''. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Configuring GRUB2--Request for a Logic Check
On Sat, Nov 09, 2013 at 10:42:14AM -0600, Dan McGhee wrote: I wanted to respond directly to you, Ken, because your original was so detailed and obviously took a long time. Thanks for that. I'm keeping your suggestions for the if all else fails part of my work. In what I have observed, the Boot Manager is trying to hand off to a boot loader. I get a really, really quick screen that has two very, very short lines--that's all I can distinguish--before it moves almost instantaneously to the Ubuntu grub screen. That's why I think it's not a kernel problemyet. Understood. I've no idea what happens on efi. So I looked for something detailed and useful about grub efi booting on intel _mac_. Ubuntu's best effort seems to be the *old* page at https://help.ubuntu.com/community/UEFIBooting (the newer page it links to says the old one might be better for macs). That points to a major source of the kernel problems (a mix of EFI 1.x and UEFI 2.x). Arch goes into some detail at https://wiki.archlinux.org/index.php/GRUB#UEFI_systems_2 but I get the impression they do things very differently from ubuntu. There is a page at http://www.rodsbooks.com/efi-bootloaders/grub2.html which talks in general terms - possibly targetted at windows users, I'm not sure if it will tell you anything you haven't already discovered. The gentoo links that google found all seemed to be untested. A mageia link noted that EFI is very flexible so every vendor (I think the writer means every distro) does things differently. (Reminds me of VSAM - a flexible and powerful tool, really easy for the unwary to screw things up). All I can suggest is that you try editing ubuntu's grub.cfg [ perhaps using 40_custom rules in the longer term, but as a first step I would just make it writable and edit it ] so that you can add an LFS entry to the ubuntu grub menu. That might allow you to prove that the LFS kernel is usable, or alternatively to prove that the required parms aren't what was expected. For that, you would need to copy the LFS kernel to wherever ubuntu has installed its kernels. That's only a step on the way, and ignores many of the things you want to eventually do, but it would break the problem down into slightly smaller parts. Although your steps may be quite painful, they may be necessary. Is that called regression testing? I've done a little of that myself recently and regressed to the oral expulsive stage of my personality development in which my hp-envy almost became hp-sattelite when I wanted to make the hp-efi into hp-ufo. Technically, regression testing is when it used to work and you want to see if it still does. You haven't got a known-good setup for LFS at the moment, so it's development. And to refer to Bruce's analysis of what you wrote I wonder if things are horrid because they become simply complicated; e.g. kernel configuration from scratch. It's more that they don't have *any* system available to them, except what is statically built in, and minimal space. That tends to mean odd build dependencies (lilo), awkward user interfaces for loading the new setup (lilo, yaboot is somewhat similar, and uimage which used 'dd' when I had to use that). And that is before the weirdnesses of certain firmware (blessing with hfs|hfs+ on macs). ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Configuring GRUB2--Request for a Logic Check
On Sat, Nov 09, 2013 at 02:13:02PM -0600, Dan McGhee wrote: For one thing it resolved my paranoia about where grub would write. I would describe that as sensible caution, not paranoia. I've irretrievably bricked one machine, and I don't wish that on anyone. In my case (the notorious AmigaOne - I overheated mine one time too many, but it took me a long while to realise what had been happening) and I had learned enough about the hardware to make me give up, and it wasn't _that_ expensive, unlike apple products. Yes, the different distro sites seem to be rather silent on this stuff. And you found something that I was hesitant to mention. This stuff does depend a lot on vendors. Many have written their own Boot Managers and I've found many comments and articles on how buggy and unreliable many are. As of a year ago, HP was one of those that had lots of complaints. That may be something else I need to research. rEFInd and gummiboot, look out I may be headed your way. Ah, I didn't realise it was the hardware vendors. Thanks for clarifying. As I've said, I'd like to accomplish two things: 1) get LFS-7.4 to boot in a UEFI environment, and 2) do it in a way that will be useful to LFS. Thank you very much, Ken, for your efforts. Dan Thank you. I hope it turns out well, and look forward to reading more. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Configuring GRUB2--Request for a Logic Check
On Fri, Nov 08, 2013 at 06:17:44PM -0600, Dan McGhee wrote: I have everything in place to boot LFS in EFI-mode. The problem is that something is failing and the messages go by so fast that I can't see what it is. Just like I have it set up, the laptop boots to Ubuntu if the LFS boot failed. My problem is that I'm stymied in my troubleshooting. I've reasoned that the problem is probably in my grub.cfg. [ snip EFI / grub.cfg details, I'm going to query your reasoning ] One initial question: you are getting kernel messages when LFS fails to boot ? If so, in a conventional bios boot the showstopper is usually something like trying to kill init and that usually happens because rootfs= is wrong, or the device drivers and filesystem are missing. You have root=/dev/sda6, so I will be very surprised if you have fallen into that hole. Hmm, does it change to booting ubuntu _immediately_ if the LFS boot fails ? If so, I can understand why you can't see the messages, but I've no idea how to address that. My reason for questioning if this is a grub.cfg issue is that I've been reading the kernel mailing list (lkml) since before I ever found BLFS or LFS. Some days I skim most of the posts, but in the last month or two I've seen a lot of posts between kernel developers about (U)EFI. My impression is that the situation is still very fragile [to be fair, most of the threads were primarily about signing the kernel for secure boot], and I recall reading that many commits which fixed things for some people broke things for others. In particular, I had the impression that many apple machines seemed to disagree with fixes that worked on regular Windows EFI x86 and (perhaps) on arm. So, I think it might be a problem either with the kernel config, or with the kernel version. Since you can't boot, that isn't a very helpful observation. Can you do anything to pause it after it fails to boot LFS ? On all the machines I've ever built for (x86 with bios, and various ppc) the automatic reboot happened about 3 minutes after the boot failed, which gave me time to note some of the visible messages. Hmm, if this is a laptop then I suppose the screen might not have enough rows to see anything useful. Perhaps the same if you got an oops and the kernel state was dumped. I *guess* a way to approach this might be to take the .config from ubuntu (/boot/config-3.x.y-z-something), work out what needs to be built-in instead of modules [ lsmod on ubuntu - if it loaded, you probably need it, at least until you can boot ], and then take a similar kernel version and try that. What I mean is, IFF you are running e.g. 3.2.0-34-generic on ubuntu, then first try 3.2.0, but also try 3.2.latest. If either boots, it's a start. If both boot, go with 3.2.latest. If neither boots, I've probably wasted your time. If only 3.2.0 boots, perhaps try broad brush bisection between 3.2.0 and 3.2.latest [ I don't know what the latest 3.2 SUBLEVEL is, my oldest running kernel is now 3.10.something, and anyway you might not be running 3.2 in ubuntu ]. ** after you can boot, first try 3.10.latest with that .config as the input to make oldconfig please, in case that works - if so, the job is done ** e.g. if latest is .100, for broad brush bisection try .50, then either .25 or .75 according to whether or not that boots. Depending on available time, you might get to the latest version of _that_ kernel which boots. That would indicate that one of the commits in the next SUBLEVEL broke it. Hmm, ubuntu are doing long-term maintenance of some kernels, of which I think one is 3.8 and I'm not sure about the other - I think they are adding their versions at the fourth level [ EXTRAVERSION ]. Whatever, the first step is to try to get a kernel which boots. If you can achieve that, the next step is to move through the newer still-maintained versions. I think the following are still maintained officially - 3.2, 3.4, 3.10. If it is an errant hardware problem I will have to suggest that you might need to try ALL the various SUBLEVELs of whichever of those series are newer than what ubuntu runs. Hopefully .0 will work, but it is possible that a later SUBLEVEL fixes an error, only for a still-later one to break it again. Actually, once you have a .config that lets you boot LFS, I guess the most efficient thing to do would be to try 3.10.latest with that config, in case it works. [ I've added the '**' sentence above ]. I'm sorry this sounds painful (it probably will be), but EFI is not yet something that most linux users are using. For the BIOS, it took years to sort out some of the weirdnesses. And I'm sorry, my suggestion to try 3.10.latest once you have a working older .config will short-circuit a lot of what I've written (if it works). I'm sure you can find an appropriate path through the twisty maze of kernel versions, all almost alike ;-) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce --
Re: [lfs-support] Configuring GRUB2--Request for a Logic Check
On Sat, Nov 09, 2013 at 02:35:35AM +, Ken Moffat wrote: [ snip EFI / grub.cfg details, I'm going to query your reasoning ] I see Bruce has replied while I was composing this. Definitely try his suggestions first (he understands those horrid gpt partitions and the even more horrid [1] grub ;-) Only come back to my painful suggestions if you have to. ĸen 1. ALL bootloaders are horrid, it's in their nature. -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Chapter 6.7.1 header file search verification failure
On Wed, Nov 06, 2013 at 05:30:58AM -0600, Douglas R. Reno wrote: I am building GCC 4.7.1 (book says to use 4.7.2). My book version is 7.3, so I am not using the latest version of the book. I have built several systems with 4.7.1 instead of 4.7.1. You seem to be confused about *where* you are in the book, and I suspect you are looking at multiple versions of it. Your heading is 'Chapter 6.7.1 header file search verification failure' but in all of the books since (at least) 7.2 the section is 6.10. 7.3 is at : http://www.linuxfromscratch.org/lfs/view/7.3/chapter06/adjusting.html My output of grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' is: SEARCH_DIR(/tools/i686-pc-linux-gnu/lib) SEARCH_DIR(/usr/lib) SEARCH_DIR(/lib); And on that page I've linked to, it says: | If everything is working correctly, there should be no errors, and |the output of the last command (allowing for platform-specific |target triplets) will be: | |SEARCH_DIR(/tools/i686-pc-linux-gnu/lib) |SEARCH_DIR(/usr/lib) |SEARCH_DIR(/lib); Which appears to match your results. For 7.4, the '/tools' match disappears. Perhaps you are trying to build something that is between 7.2 and 7.3, but comparing it to the 7.4 or current svn book ? Or maybe you are building 7.3 except for sticking with an older gcc-4.7 release. That seems weird, but I'm sure you will think many things _I_ do are weird. I can't imagine why you would want to build such an old version - for me, stable 7.4 is verging on 'old' (I'm from the LFS is near the bleeding edge school) - but your system, your rules and the *matching* instructions should still work. But please be _clear_ about which version you are using, and what variations you have made, when you post here. At the moment, people will probably assume you are building 7.4 if you say nothing. I was going to moan about you top-posting, but I see you are using gmail so I guess you don't have any real choice if you are using its web interface - sucks, doesn't it. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 8.3 - Kernel Build
On Wed, Nov 06, 2013 at 01:22:23PM +, Richard wrote: Hello again, I am surprised and confused by the warnings and instructions in Section 8.3 - can someone please elaborate on the points below? I have previously rebuild the kernel several times on a variety of distros and although instructions differ there has always been one unshakable thing in common: the kernel sources always always always live below /usr/src/linux. I have just checked my host system (a recent clean install of slackware - running 3.2.29-smp) and it too has a symlink from /usr/src/linux to the current source tree. So the obvious questions arise: - Where should the kernel source be kept? Presumably below /sources with all the rest? Keep it anywhere you like! Or don't keep it extracted [ I believe that certain iptables-related things want kernel source, but that is extremely unusual and certainly iptables itself doesn't need the kernel source for normal builds ]. Apart from during the build of LFS, where root is the only user, there is no need to build the kernel as root. For years, my kernel source lived in /home/ken. I only moved it out of there to avoid the waste of backing it up : as long as you can recreate the .config, an extracted kernel tree isn't needed. - What are these dire consequences which are alluded to in the warning box at the end of 8.3.1? - Is this a LFS-specific problem or are other distro making a mistake? As just stated there seems to be such a symlink on slackware and I had a brief flirtation with gentoo which I am sure also store kernel source below /usr/src/linux? I have a very vague recollection that one or two packages (probably not in BLFS) used to pick up kernel details by looking at /usr/src/linux , if it existed, in the very distant past. ISTR they actually wanted to know the capabilities of the _running_ kernel. But yes, we consider that everyone making an unnecessary /usr/src/linux symlink is mistaken, just as we consider that updating the kernel headers when updating the kernel is wrong. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 8.3 - Kernel Build
On Wed, Nov 06, 2013 at 01:47:42PM +, Ken Moffat wrote: I have a very vague recollection that one or two packages (probably not in BLFS) used to pick up kernel details by looking at /usr/src/linux , if it existed, in the very distant past. ISTR they actually wanted to know the capabilities of the _running_ kernel. To clarify: consider the situation where you suspect you have a kernel bug. Say you are now on 3.12.0 and had previously used 3.11.5. As a first step, boot 3.11.5 [ assuming you kept it around, of course ] to see if things are different. Any application looking at /usr/src/linux has no guarantees that the source (or indeed the .config there) matches what is running. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] gcc tests
On Thu, Oct 31, 2013 at 01:28:09PM +, Richard wrote: Hello again, I have finally completed the leviathan task of my first gcc compilation and test. I am encouraged to have only one unexpected failure outside libmudflap. This leaves me with two questions. 1. How bad is that error? I have inferred that it is probably infrequent - but it does no harm to check... (FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_HugeMallocTest Ident((char*)malloc(size))[-1] = 0 output pattern test, should match is located 1 bytes to the left of 2726297600-byte) I've never seen that one, I assume it is probably platform-specific My rule of thumb is that a large number of unexpected failures mean something is wrong [ I had that once, in the early days of udev ]. Beyond that, I don't have a high regard for testsuites - what really matters is whether the package will work in normal situations. Getting a new failure is interesting, but might be random. 2. Far more worryingly - have I somehow mishandled the tests? I am drawn to startling disparity in the test totals. Here is my gcc summary, based on source tarballs downloaded in the past week or so: === gcc Summary === # of expected passes92870 # of expected failures259 # of unsupported tests1096 and here is the corresponding section from http://www.linuxfromscratch.org/lfs/build-logs/stable/core2duo/test-logs/080-gcc (which I believe ran in August): === gcc Summary === # of expected passes93302 # of expected failures261 # of unsupported tests1368 Am I correct in thinking that I am missing 706 tests? Has the test suite really shrunk by 700 tests in the past 8 weeks? Are you using the 7.4 book or svn ? If you are using gcc-4.8.2 then I have no data to offer. Again, many thanks, R. I've only built 32-bit x86 once for LFS-7.4 (on a recent AMD machine, I think it's an A4). My results were more like yours than Bruce's : === gcc Summary === # of expected passes92903 # of expected failures 259 # of unsupported tests 1084 What appears to be changing is the number of unexpected failures. My build had some variations from the -rc1 book (a patch in automake which I think got into the release, and eudev instead of udev from systems), but those are later than the gcc test results. I also limit the compatability code in glibc [ --enable-kernel=3.9.0 to suite my rescue CD ] but I'm guessing the config of the running kernel might be what has most influence on which tests are unsupported. Everything else we've built at this stage should match. Mostly, I only look at the errors reported by this sort of testsuite. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] gcc tests
On Thu, Oct 31, 2013 at 03:26:35PM +, Richard wrote: From: Ken Moffat zarniwh...@ntlworld.com ... Are you using the 7.4 book or svn ? If you are using gcc-4.8.2 then I have no data to offer. ... I am (I hope!) using the plain, normal, generic, unadulterated LFS 7.4 - which means that I just compiled gcc 4.8.1. I will proceed under the assumption that all is well. Thanks, R. I thought you were using that - clearly, the tests cannot have changed in the past x weeks because the tarball (and its md5sum) has not changed. ;-) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Some BLFS Packages Before Making LFS-7.4 Bootable
On Thu, Oct 31, 2013 at 02:28:27PM -0500, Dan McGhee wrote: So that I can hit the deck running after I get my new system to boot, I want to add a few packages, and their associated boot scripts, from BLFS. These are dhcpd, wpa-supplicant, libxml, libn, open-ssl and d-bus. I seem to remember reading somewhere, and I thought it was in the LFS book, that it was OK to do what I'm thinking of. I don't see anything that will hinder my plan, but I thought I'd ask here where many people know a lot more about this than I do. Anything to be careful of? Thanks, Dan There used to be some packages that gave problems if building in chroot. But I don't remember what they were. In the last couple of years I've done some complete builds in chroot while I sorted out changes to my build scripts, so I don't think you'll have any problems. You might want to add a text browser so that you can read the BLFS book. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Some BLFS Packages Before Making LFS-7.4 Bootable
On Thu, Oct 31, 2013 at 06:07:03PM -0500, Dan McGhee wrote: I also have my sources in /usr/src and that is a separate partition so I can use it from any build. I recommend the following as separate partitions: /boot, /home, and /usr/src. /opt is also a possibility. -- Bruce I have a script that gets me to chroot and it mounts those each time I go in. I forgot about wget, thanks for reminding me. A separate partition for /usr/src? Never occurred to me, but it's a good idea. Actually, you can build any package *anywhere*. For something like the kernel, keeping the source directories around if I haven't built that version before ( or if there have been major changes such as when I was upgrading only from a very old system that needed the old compatability sysfs options for less ancient kernels) is a good idea. If the kernel boots, I can get the config from /proc/config.gz - it's the ones that don't boot which are the problem ;) My scripts *used* to build (as root) in /usr/src because that was conventional and traditionally intended for root to build in, and kernels and anything else built manually as a regular user were in ~/. Nowadays I use a dedicated partition which doesn't get backed up, and which has _writable_ directories belonging to me and someone called lfs, and another directory that root uses in my scripts. So, you certainly want space to build things, and it needs to be writable by whoever does the building, but it doesn't matter where you put it. BTW, I mention not backed up because '/' '/boot' and '/home' get backed up regularly by fcron invoking an rsync-over-nfs script. That uses a *lot* of space on the server (typically 2.5 times the size of the data : the copy is then rsynced to a retention area using hardlinks for GDG-style backups) and my server disks aren't huge - main system now on a 1TB disk including the area the backups are first written to, and a pair of 1TB RAID-1 disks for inter-alia the backups themselves and also a lot of photos and media. There are probably an infinite number of sensible partitioning strategies, but knowing how you will recover if things go wrong (e.g. a dieing disk) should be a consideration. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] glibc test failures. Acceptable?
On Mon, Oct 28, 2013 at 01:07:32PM +, Richard wrote: Hello experts, I am attempting my first LFS build; which will (hopefully) be 7.4, built on a host system of slackware-14. All went well up until chapter 6. I am unsure as to whether or not the errors in the glibc fall into the acceptable variety or not. glibc appeared to build well enough. Having tried the test suites (with TIMEOUTFACTOR=16 - this is a humble machine), the make - k check ends with: AWK='gawk' scripts/check-local-headers.sh \ /usr/include /source/glibc-build/ /source/glibc-build/check-local-headers.out /usr/bin/perl scripts/begin-end-check.pl argp/argp.h assert/assert.h catgets/nl_types.h crypt/crypt.h ctype/ctype.h debug/execinfo.h dirent/dirent.h dlfcn/dlfcn.h elf/elf.h elf/link.h gmon/sys/gmon.h gmon/sys/gmon_out.h gmon/sys/profil.h grp/grp.h gshadow/gshadow.h iconv/iconv.h iconv/gconv.h inet/netinet/in.h inet/netinet/igmp.h inet/netinet/ip6.h inet/netinet/ether.h inet/netinet/icmp6.h inet/arpa/inet.h inet/arpa/telnet.h inet/arpa/tftp.h inet/arpa/ftp.h inet/protocols/routed.h inet/protocols/timed.h inet/protocols/rwhod.h inet/protocols/talkd.h inet/aliases.h inet/ifaddrs.h inet/netinet/ip6.h inet/netinet/icmp6.h intl/libintl.h io/sys/stat.h io/sys/statfs.h io/sys/vfs.h io/sys/statvfs.h io/fcntl.h io/sys/fcntl.h io/poll.h io/sys/poll.h io/utime.h io/ftw.h io/fts.h io/sys/sendfile.h libio/stdio.h libio/libio.h locale/locale.h locale/langinfo.h locale/xlocale.h login/utmp.h login/lastlog.h login/pty.h malloc/malloc.h malloc/obstack.h malloc/mcheck.h math/math.h math/complex.h math/fenv.h math/tgmath.h misc/sys/uio.h nis/rpcsvc/yp_prot.h nis/rpcsvc/nis_callback.h nis/rpcsvc/yp.h nis/rpcsvc/ypupd.h nis/rpcsvc/nislib.h nis/rpcsvc/nis_tags.h nis/rpcsvc/ypclnt.h nis/rpcsvc/nis.h nptl_db/thread_db.h nptl/sysdeps/pthread/pthread.h nptl/semaphore.h nss/nss.h posix/sys/utsname.h posix/sys/times.h posix/sys/wait.h posix/sys/types.h posix/unistd.h posix/glob.h posix/regex.h posix/wordexp.h posix/fnmatch.h posix/getopt.h posix/tar.h posix/sys/unistd.h posix/sched.h posix/re_comp.h posix/wait.h posix/cpio.h posix/spawn.h pwd/pwd.h resolv/resolv.h resolv/netdb.h resolv/arpa/nameser_compat.h resolv/arpa/nameser.h resource/sys/resource.h resource/sys/vlimit.h resource/sys/vtimes.h resource/ulimit.h rt/aio.h rt/mqueue.h setjmp/setjmp.h shadow/shadow.h signal/signal.h signal/sys/signal.h socket/sys/socket.h socket/sys/un.h stdio-common/printf.h stdio-common/stdio_ext.h stdlib/stdlib.h stdlib/alloca.h stdlib/monetary.h stdlib/fmtmsg.h stdlib/ucontext.h sysdeps/generic/inttypes.h sysdeps/generic/stdint.h stdlib/errno.h stdlib/sys/errno.h string/string.h string/strings.h string/memory.h string/endian.h string/argz.h string/envz.h string/byteswap.h sunrpc/rpc/pmap_clnt.h sunrpc/rpc/xdr.h sunrpc/rpc/rpc_des.h sunrpc/rpc/auth_des.h sunrpc/rpc/pmap_rmt.h sunrpc/rpc/rpc.h sunrpc/rpc/auth.h sunrpc/rpc/key_prot.h sunrpc/rpc/netdb.h sunrpc/rpc/rpc_msg.h sunrpc/rpc/auth_unix.h sunrpc/rpc/pmap_prot.h sunrpc/rpc/svc.h sunrpc/rpc/clnt.h sunrpc/rpc/des_crypt.h sunrpc/rpc/types.h sunrpc/rpc/svc_auth.h sunrpc/rpcsvc/bootparam.h sysvipc/sys/ipc.h sysvipc/sys/msg.h sysvipc/sys/sem.h sysvipc/sys/shm.h termios/termios.h termios/sys/termios.h termios/sys/ttychars.h time/time.h time/sys/time.h time/sys/timeb.h wcsmbs/wchar.h wctype/wctype.h /source/glibc-build/begin-end-check.out make[1]: Target `check' not remade because of errors. make[1]: Leaving directory `/source/glibc-2.18' When I look for just the errors, using 'grep -i error glibc-check-log' I find: If you had used the command in the book (grep Error) instead of your own version you would have got a much shorter output. make[2]: *** [/source/glibc-build/rt/tst-cputimer1.out] Error 1 make[1]: *** [rt/tests] Error 2 make[2]: [/source/glibc-build/conform/run-conformtest.out] Error 1 (ignored) make: *** [check] Error 2 I have inferred from the book that 'cputimer1' and 'run-conformtest' might be 'acceptable' failures, but I was surprised that the test suite ended mid-way. Why do you think it ended mid-way ? Your output from the make check command seems to end normally (I was going to cut it from the reply, but I've left it for the moment) - my log ended similarly. Ah, you don't seem to have results from the posix/ tests. For me they are run (and fail as noted) before run-conformtest.out. If you look at glibc-check-log (try using less or vim from the host system), does tst-getaddrinfo4 get mentioned ? In my log the .c file gets compiled to .o with a command which references the .o and .o.dt before creating the .o, then gets linked to tst-getaddrinfo4 (by gcc), and then gets invoked in the next line to create tst-getaddrinfo4.out. Do you have any of that in your log ? Have I done something stupid? Are these acceptable errors and I am worrying needlessly? Is there something more
Re: [lfs-support] glibc test failures. Acceptable?
On Mon, Oct 28, 2013 at 04:25:02PM +, Richard wrote:
I think I neglected to shut down the networking on the host system - so the
posix tests did not fail. I did not realise that network isolation was a
requirement. I do not have that machine with me here at work - so I will
check later.
That is interesting. And very puzzling. For me, I don't shut down
networking on the host (why would anyone do that ?), but I think that
test has always failed for me since it was introduced - it's fairly
recent.
Similarly, I get an ignored Error for posix/annexc.out and I think
that one has been like that ever since we've been running the tests
('pure LFS' - first release like that was 5.0 if my memory is
correct), but I didn't see that one either in your grep.
I am also assuming that glibc is one of the packages that can safely be
installed to a fake root - then tarballed 'slackware style'? (i.e: I am
intending that my next step would be make DESTDIR=dest install), rather
then installing directly.
For the first time, we recommend doing things by-the-book so that
you understand how it all fits together. If you wish to try doing
things differently, please be aware that you *might* encounter
problems that other people don't.
I'll probably get shouted at for this - but here goes...
... forgive my stupidity. I was trying to stick to doing things by the book.
The method of installing to a fake destination directory is explained in
sections
6.3.2.3 and 6.3.2.6; so I thought that using DESTDIR *was* doing things 'by
the book'.
When we say by the book we usually mean by following the commands
on the page for that step (and ONLY those commands - you have
already shown a willingness to come up with your own version of the
grep command :-) There are a number of different approaches to
package management, all of them have drawbacks.
In my own case I suppress many of the static libraries, but that
restricts what I can do [ no statically-linked packages, some tests
in binutils fail, also I can't build sysvinit, tk, firefox [ with
system libs ], some of kde, or Linux-PAM without making a static lib
available (various different static libs). So, although there are
some packages where I use --disable-static, in other cases I take
other measures (e.g. in flex) so that I can make a lib available when
needed.
So, I'm not trying to condemn you for doing things differently.
I'm trying to point out what we mean by follow the book. Anything
which is different from the book runs the risk of putting you on a
less well-trodden patch. It may be fun (in the sense of the word
used by operators and programmers) and very educational, but if
things break you get to keep both pieces.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] compile error with libstdc++
On Sun, Oct 27, 2013 at 01:01:17AM +0200, Hans P. wrote: Hello, I'm try to compile the libstdc++. I'm read carefully the section 5.8.1. Installation of Target Libstdc++, but when i try to make install I get an error: ../libtool: line 1132: i686-lfs-linux-gnu-ranlib: command not found and after that, some line further the program stop. Can someone help me? Just to be clear - did you remove the gcc-4.8.1/ directory after pass 1 of gcc ? You need fresh source and build directories each time. I'm mentioning that because I don't remember seeing this problem before. If you re-used the previous source, please use fresh source and try again. Thanks a lot best regards rado I execute the following command: ../gcc-4.8.1/libstdc++-v3/configure --host=i686-lfs-linux-gnu --prefix=/tools --disable-multilib --disable-shared --disable-nls --disable-libstdcxx-threads --disable-libstdcxx-pch --with-gxx-include-dir=/tools/i686-lfs-linux-gnu/include/c++/4.8.1 Result: ... make[1]: Leaving directory `/mnt/lfs/sources/gcc-build/include' Making install in libsupc++ make[1]: Entering directory `/mnt/lfs/sources/gcc-build/libsupc++' make[2]: Entering directory `/mnt/lfs/sources/gcc-build/libsupc++' test -z /tools/lib || /bin/mkdir -p /tools/lib /bin/sh ../libtool --mode=install /usr/bin/install -c libsupc++.la '/tools/lib' libtool: install: /usr/bin/install -c .libs/libsupc++.lai /tools/lib/libsupc++.la libtool: install: /usr/bin/install -c .libs/libsupc++.a /tools/lib/libsupc++.a libtool: install: chmod 644 /tools/lib/libsupc++.a libtool: install: i686-lfs-linux-gnu-ranlib /tools/lib/libsupc++.a ../libtool: line 1132: i686-lfs-linux-gnu-ranlib: command not found i686-lfs-linux-gnu-ranlib should have been installed by binutils pass 1. You presumably have *some* of the binutils programs, otherwise gcc pass 1 could not have built for $LFS_TGT. My i686 log shows the following programs were installed. Please check if they are present on your build: /tools/bin/i686-lfs-linux-gnu-addr2line /tools/bin/i686-lfs-linux-gnu-ar /tools/bin/i686-lfs-linux-gnu-as /tools/bin/i686-lfs-linux-gnu-c++filt /tools/bin/i686-lfs-linux-gnu-elfedit /tools/bin/i686-lfs-linux-gnu-gprof /tools/bin/i686-lfs-linux-gnu-ld /tools/bin/i686-lfs-linux-gnu-ld.bfd /tools/bin/i686-lfs-linux-gnu-nm /tools/bin/i686-lfs-linux-gnu-objcopy /tools/bin/i686-lfs-linux-gnu-objdump /tools/bin/i686-lfs-linux-gnu-ranlib /tools/bin/i686-lfs-linux-gnu-readelf /tools/bin/i686-lfs-linux-gnu-size /tools/bin/i686-lfs-linux-gnu-strings /tools/bin/i686-lfs-linux-gnu-strip and also some of them were in /tools/i686-lfs-linux-gnu/bin/ : /tools/i686-lfs-linux-gnu/bin/ar /tools/i686-lfs-linux-gnu/bin/as /tools/i686-lfs-linux-gnu/bin/ld /tools/i686-lfs-linux-gnu/bin/ld.bfd /tools/i686-lfs-linux-gnu/bin/nm /tools/i686-lfs-linux-gnu/bin/objcopy /tools/i686-lfs-linux-gnu/bin/objdump /tools/i686-lfs-linux-gnu/bin/ranlib /tools/i686-lfs-linux-gnu/bin/strip [ ISTR these are hardlinked to the first set ]. Are all these files present ? If not, which are missing ? Another thing to consider - did you interrupt the build and exit it, then later come back ? Perhaps the environment for user lfs didn't get restored ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] umount: mountpoint not found
On Fri, Oct 25, 2013 at 08:28:40AM +0100, Michael E. Maher wrote: On Fri, 2013-10-25 at 00:58 +0100, Ken Moffat wrote: On Fri, Oct 25, 2013 at 12:25:11AM +0100, Michael E. Maher wrote: Hey Ken, Does `/etc/mtab' look good? Thanks, Michael Root has now umounted /dev/sdXY, so it is no longer mounted. What should I look for if I mount it again and then try to umount it ? ĸen First make sure it's a symlink to `/proc/self/mounts' Yes for both (the server running 7.4 where I noticed this, and the current desktop machine where I originally saw it). and check that it contains a entry like: /dev/sdXY /scratch ext4 rw,noquota 0 0 I've just attempted to umount on the desktop (took me a while to get to a point where nothing was actively using /scratch :) - ken@ac4tv ~ $cat /etc/mtab | grep /scratch /dev/sda14 /scratch ext4 rw,relatime,data=ordered 0 0 ken@ac4tv ~ $umount /scratch/ umount: /scratch: mountpoint not found But root was able to 'umount /scratch' after that. The line in /etc/fstab is: /dev/sda14 /scratch auto noauto,user,rw,exec,suid,dev 0 0 The options are because I sometimes do test chroot builds there. Those settings were working fine until recently. I might be way off base, but I'm guessing maybe this is within a `chroot'? No, regular systems. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] umount: mountpoint not found
On Thu, Oct 24, 2013 at 05:59:52PM -0500, Bruce Dubbs wrote: Ken Moffat wrote: I first noticed this on my desktop which is running LFS-svn with make-4.0, and where I've got more than enough other things still to look at. But on my server running 7.4 I've just done: mount /scratch [ /me does something there ] umount /scratch which returns - umount: /scratch: mountpoint not found and /scratch is still mounted. Any ideas about what is going on, please ? No, but you can always 'umount /dev/sd??' -- Bruce Well, root can, so thanks for that (all too often, I'm too close to the problem and can't see the wood for the trees). - /scratch is where I use the spare space from modern disks : it doesn't get backed up [ what a waste of space that would be! ] and either ken or lfs can use it - or indeed /root when updating the system. One day, I suppose I'll find out what else needs to be changed so that users can umount it again. Meanwhile, only about another 30 packages to test (mostly DESTDIR) on *this* build with make-4.0. I'd better get back to preparing my scripts for the *next* build - all the remaining rubbish^Wthings I don't normally build. ;-) Thanks. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] umount: mountpoint not found
On Fri, Oct 25, 2013 at 12:25:11AM +0100, Michael E. Maher wrote: Hey Ken, Does `/etc/mtab' look good? Thanks, Michael Root has now umounted /dev/sdXY, so it is no longer mounted. What should I look for if I mount it again and then try to umount it ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Newbie need help - bus error in 5.5. GCC-4.8.1 - Pass 1
On Wed, Oct 23, 2013 at 05:49:27PM -0400, Viola Zoltán wrote: @akhiezer: I tryed: CFLAGS=-O2 -g make but no changed: My final suggestion is : try a different host distro. The recent google matches for this were almost all for people updating packages on gentoo, which is why I suspect gentoo's hardening. There was one similar error for someone doing something on fedora, but at the moment I regard that as an outlier (it had no responses and apparently remains unresolved). One of the gentoo threads suggested that these errors could come from memory problems (test with memtest86), but I suspect there must also be something in the hardening which has an influence, because you are not getting a segfault. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Newbie need help - bus error in 5.5. GCC-4.8.1 - Pass 1
On Wed, Oct 23, 2013 at 07:14:15PM -0400, Viola Zoltán wrote: Dear Ken, I am sure that this is no memory problem. I have absolutely full totally new memory chipset in my laptop, and all programs work very good, both in my Sabayon (because I use not Gentoo, but Sabayon) and my old Ubuntu 11.10 distro in an other partition. Okay, I try the LFS with any other host distro. Make a suggestion to me, please, which distro would be good for this procedure? No LiveCD please, I have an empty almost 100 GB partitio for the host system. Please propose a distro which has MC... I CAN use the commandline without MC, good, but WITH mc it is much easyer and faster. I am not profi in the Linux, but no beginner. Maybe power user. I can write not too difficult bash scripts, can programming in C/C++ (and a little bit in assembly...), my preferred window manager is the DWM, but I am newbie in the LFS, because I not understand good how the configure, the make, autoconf, automake and the linker work, not know they's syntax, etc. I am in the Linux autodidact, self-educated, I was never learned it in any school or training course. Actually/as a matter of fact, I was begin the LFS even just exactly because I would like to know FULLY, how a Linux system work, and because I very not like the bloatware distros (named *buntu, etc) with lot of (for me) superfluous programs. I like, agree, approve the suckless.orgphilosophy. I like the commandline and the commandline-based programs (and ncurses). But sorry, I not have a good mentor... Thus, what host distro do you suggest for me, which work good (tested) sure to this LFS? Zoli I've no idea which distro would suit you. But whatever you use, 100GB is excessively large for a system. Many people will put the user's files in /home on a separate partition. Some people will put other data files (e.g. audio-video) on a separate partition. You can always reinstall a distro if it gets trashed, but you are the only one who can preserve and back-up your own data. Debian and debian-derived distros (ubuntu, mint) may be missing a few things (e.g. they might have mawk instead of gawk, and /bin/sh might be symlinked to dash - both these things can be fixed). Distros like Arch and fedora might be too bleeding edge (i.e. newer than what we have tested), but I will be surprised if they cause many problems (I'm assuming that systemd doesn't cause a problem in building LFS - I've never used it, and have no plans to). MC is not something I like, so I've no idea which distros use it. The one benefit to a distro is that it should set up your hardware properly. Nowadays many things just work, but older or very new hardware can have problems. Wifi can be a problem, and occasionally graphics are also a problem. Suspend/hibernate also. If you can find a distro which suits you, you can use it to examine desktops and different desktop applications. I assume that debian has the widest range of these. Once you have a usable (for you) desktop, you will (I hope) find that using a graphical browser such as firefox is the easiest way to search for solutions to problems, and you will also be able to try putting multiple terms on the same desktop (if your screen is big enough) - I guess that kde, gnome, and unity (ubuntu) are probably not very good for multiple terms on the same desktop. Seriously, a desktop configured the way you like it, with multiple terms, is the most productive way to write scripts or code IMHO. I'd better not forget to mention Slackware. You might do best to spend a few weeks playing around with different distros - for normal use, I guess that 10GB is plenty for a system, but you may have trouble getting multiple distros to play nicely with each other - particularly when setting up grub, but also the user and group IDs. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Newbie need help - bus error in 5.5. GCC-4.8.1 - Pass 1
On Wed, Oct 23, 2013 at 09:00:36PM -0400, Viola Zoltán wrote: Dear Ken, I need the new distro from you suggestion ONLY, JUST for the building of LFS, no for other works/jobs! No problem, if it not have wifi-possibility or others. I saved the full LFS and BLFS books to my new-used partition, I will work from its. And I was downloaded all needed packages, of course. I will install the new host distro, and build LFS. If I would like work/play any other, then reboot to my Sabayon. Therefore, I no need full-featured desktop environment. Just a lightweight WM with a browser to read the LFS book, mc (not musthaved, but I like it) and nothing else, just I should can build my LFS. I need the host distro just temporarily, ad interim. Which distro you do use nowadays for build you LFS system? To answer that last question - LFS. I have used debian-ppc and then ubuntu for my non x86 boxes, but the last x86 distro I used was probably mandrake-7.2. Is sabayon the gentoo-based hardened distro you were using ? Or did you actually install gentoo ? Or, it is would be much easyer to my, that if you have a full temporary system as written in the LFS book, - finished to the 5.35 chapter - then you pack it to a tar.bz2 file, and send me its download link. I download it, unpack it to my partition, change ownership, and begin at this chapter I continue the building of my own LFS system, with chroot and others. This is a little bit would be alike to the Gentoo, from stage3, I think. Zoli Four reasons why I can't do that : 1. I don't have such a tarball. 2. Size - I don't have anywhere to upload large files. 3. Licensing - you would need my buildscripts, and I would also have to offer to supply you with the source tarballs for a reasonable time, at least for the GPL'd packages. 4. I'm normally building on x86_64. You are building i686. At this point, perhaps I should mention that we really dislike top posting. You mentioned that you didn't like ubuntu : if you have a fairly-recent ubuntu CD, that should be good enough : install it and then boot ubuntu, install a minimal desktop instead of the bloated 'buntu desktop (I prefer icewm, but xfce is nearly as useful), your mc, and then whatever it needs for LFS - build-essentials, and replacing the dash symlink is my guess. Check the host system requirements in the book. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Newbie need help - bus error in 5.5. GCC-4.8.1 - Pass 1
On Tue, Oct 22, 2013 at 05:31:19PM -0400, Viola Zoltán wrote: Hi, excuse me for the bad English... I try LFS from Sabayon host system, with this GCC version: lfs@Csiszilla /Mount/Simplicity/sources/gcc-build $ gcc --version gcc (Gentoo Hardened 4.7.2-r1 p1.5, pie-0.5.5) 4.7.2 The binutils succeeded. The GCC not. It wrote me this error message: build/genautomata ../../gcc-4.8.1/gcc/config/i386/i386.md \ insn-conditions.md tmp-automata.c /bin/sh: line 1: 24043 Bus error build/genautomata ../../gcc-4.8.1/gcc/config/i386/i386.md insn-conditions.md tmp-automata.c make[3]: *** [s-automata] Error 135 Apparently, a bus error differs from a segfault - valid memory is being accessed in an invalid way. The example google found was for unaligned accesses on architectures where those are illegal. i686 is generally very permissive, so I can't imagine what sort of access would cause this. Google did find similar examples on gentoo lists (users trying to emerge gcc and getting a Bus error). Apparently, the pie setting was involved. I've no idea how you would reduce the hardening on a gentoo system. Someone in another gentoo response suggested reducing the CFLAGS to something sane - if you are following LFS exactly, then the default CFLAGS from the package should be used. I -fno-exceptions -fno-rtti are from the package. But if you did set those, try without them. My significant variables: lfs@Csiszilla /Mount/Simplicity/sources/gcc-build $ echo $LFS /Mount/Simplicity Might work nowadays, but we always recommend /mnt/lfs. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Newbie need help - bus error in 5.5. GCC-4.8.1 - Pass 1
On Tue, Oct 22, 2013 at 07:41:24PM -0400, Viola Zoltán wrote: Excuse me, I am very newbie and very idiotic... I tryed it: CFLAGS=-fno-exceptions -fno-rtti; make CFLAGS=--fno-exceptions --fno-rtti; make but nothing changed, the compile not succeeded, same error message... I intended you to try REMOVING those CFLAGS by setting CFLAGS to just -O2 -g, but ONLY if they were already set in your LFS user's CFLAGS. I know you posted some variables in your original post, but perhaps your lfs user has mangaged to acquire some other settings from the host distro ? I don't understand the details of gentoo, but running 'printenv' as the lfs user should enable you to check that if you are in any doubt. Or 'printenv | less' if htings have been picked up. Also, if you do change anything like that you need to use freshly untarred source and a fresh (empty) build directory, and specify them when you run configure. But I think the most likely problem is that your gentoo system has been hardened, and I have no idea how to deal with that. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Ncurses Libraries in Perl Library Tree
On Tue, Oct 15, 2013 at 12:16:48PM -0500, Dan McGhee wrote:
In trying to add Vim at the end of Ch. 5, I discoverd that four ncurses
libraries weren't where they were supposed to be. Instead of /tools/lib
I found libncurses{,w}.so.5{,.9} (actually two of these are soft links)
in /tools/lib/perl15/5.18.1/x86_64-linux-gnu/. This just doesn't seem
right. I think I can remember typing x86_64-linux-gnu when building
Ch. 5, but I can't remember in what section. The only instructions in
either ncurses or perl that could have caused any typing issues--and I
usually copy and paste to eliminate those--are in the perl build. cp
-Rv lib/* /tools/lib/perl5/5.18.1.
On my 7.4 builds, in chapter 6 perl installs some files into
/usr/lib/perl5/5.18.1/x86_64-linux-gnu/. It doesn't do that in
chapter 5.
Similarly, in chapter 5 the book doesn't install the wide versions
of ncurses.
No idea how you could have got ncurses libs installed into the perl
directory tree. I guess you aren't scripting chapter 5, but if your
lfs user's bash history is available it might show something.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Possible Syntax Error in Current Package User Hint Build Script
On Sat, Oct 12, 2013 at 01:36:04PM -0500, Dan McGhee wrote:
I suppose that the most practical thing for me to do is jump into Ch.
6 and build with the script in the hint as it exists now. I could
pause at the end of this command to see what was happening. However,
in a previous life I was an engineer (Oh, no!!) and my OCD has kicked
in. First of all, I want to understand everything the script is doing
and when I looked at it in my text editor (gedit in Ubuntu) I saw a
problem. With that editor the only valid thing in pick is what's
between two quotes in an echo command. Anything else in pink has
something wrong in front of it--a syntax error. In gedit everything in
the script after $(pwd) is pink. There's something wrong, and I'd
like to find it before I start.
Maybe the syntax highlighting in that version of gedit is missing
or broken. Try vim and see how it looks ('syntax on' in ~/.vimrc or
/etc/vimrc). I use a black background, with ':colorscheme elflord'
I didn't see anything unusual when I pasted that line into a script.
Not that vim's highlighting is perfect, it occasionally gets
confused but usually only when I scroll a long way through a long
script.
It's also, of course, possible that there is an apparent error
_before_ this which makes the highlighter confused.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Possible Syntax Error in Current Package User Hint Build Script
On Sat, Oct 12, 2013 at 04:59:04PM -0500, Dan McGhee wrote:
On 10/12/2013 03:01 PM, Ken Moffat wrote:
Maybe the syntax highlighting in that version of gedit is missing
or broken. Try vim and see how it looks ('syntax on' in ~/.vimrc or
/etc/vimrc). I use a black background, with ':colorscheme elflord'
I didn't see anything unusual when I pasted that line into a script.
Not that vim's highlighting is perfect, it occasionally gets
confused but usually only when I scroll a long way through a long
script.
That was one of my first thoughts and so I loaded up a script that I
knew worked and looked at it. It was fine. BTW it was the build script
you helped me with a few years ago. You taught me how to extract the
package name from a tar archive not knowing what the final extender
was--gz, tz, bz, bz2. If you're interested, I've got that down to one
line now instead of four since tar -xf works for all the stuff that I've
tested.
Yeah - I think I've still got that in my functions. As you say, it
hasn't been needed for a few years. The problem is knowing when the
last system with an old version of tar has gone. I know, I'll claim
I'm retaining it in case I ever have to build from a debian system
joke/.
My thought was, If there's something wrong in that line, the cd...
line, then if I edit it, I might get all the pretty colors back in the
rest of the script. The offensive character I found when I removed it
is the following $(pwd). When I remove the gedit indicates that the
syntax is OK. The problem, and it's not really a problem, is that this
exact line is the first in every function call of the script for _make),
_check) and _install). I understand the command because it puts you in
the right directory to run ./configure, make and install.
When I first saw this line, I thought that the purpose of all the was
to keep the shell from expanding things execpt a few special
characters. As a matter of fact, after I did some more editing just
know, I discovered that it's the combination of () and with $pwd that
causes the problem. Either set of characters *used alone* works. In
combination everything after ...d) including the is pink in gedit. I
know that last was a highly technical statement of the analysis. :)
I wonder if the first escapes the first ( and the last is seen as an
unresolved quote. Well, at least I found the problem, even though the
syntax sin escapes me--no pun intended, but when I read it, it's not a
bad one.
The script has been recently edited. I don't know how recently tested.
Hopefully, we can get the situation corrected.
Parentheses can be a pain. In metaflac all tag values are input in
double-quoted strings, but I've never managed to get parentheses in
a tag - I did once manage \( which wasn't at all what I wanted, but
every other attempt got an error report from bash.
Similarly, a parenthesised subshell which is commented by # in a
here document (e.g. the command to get the libxul sdk in firefox's
mozconfig in the BLFS book) *is* evaluated by bash - took me a long
while to work out where the message :
Package libxul was not found in the pkg-config search path.
Perhaps you should add the directory containing `libxul.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libxul' found
was coming from when I built firefox without xulrunner :)
But it's all about learning.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Errata for LFS 7.4
On Tue, Oct 08, 2013 at 07:42:49PM -0500, William Harrington wrote: On Oct 8, 2013, at 7:02 PM, Steve Crosby wrote: Changelog lists host system requirements changes for kernel to 2.6.34, http://www.linuxfromscratch.org/lfs/view/stable/chapter01/changelog.html Indeed, Not sure why Sincerely, William Harrington The initial discussion was on lfs-dev on 6th July, starting at http://www.mailarchive.com/lfs-...@linuxfromscratch.org/msg18826.html if I've manually copied the link correctly (I'm on my netbook, need to use a tty to be able to _read_ my mail, don't have gpm). The value of --enable-kernel= was set to 2.6.34 in r10302. It got downgraded to 2.6.32 in r10327 in August, and obviously the log was overlooked. I don't recall why it got downgraded, and I couldn't find the reason in my mailboxes (which is not to say that it wasn't discussed). Personally I don't have anything running such an old kernel at the moment - everything is now on 3.10-rc or newer :) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Getting su in Chapter 5
On Mon, Oct 07, 2013 at 05:09:52PM -0500, Dan McGhee wrote:
I use the more_control hint in my builds. I need su before I start
working in Ch. 6. It's used to go back and forth between 'root' and a
'package_user.' When coreutils still supplied su, the procedure was
just to copy it to /tools/bin after installing coreutils to the build
chain. Su itself was not installed because user 'lfs' is the installer
and coreutils wanted to install it suid root. In the 'package users'
system, there is no need for it to be suid root, but it's needed before
the installation of shadow in Ch. 6.
One option is to install 'shadow' at the beginning of Ch. 6, but that
leads to some hiccups down the road. They're not insurmountable, but
they can be frustrating. I'm want to install only su from shadow
before I get to Ch. 6. My problem is that I know only enough about
make and make install to make me dangerous, and I get bogged down
reading the documentation.
Knowing that there are some packages in LFS that will either make one
target or install one target or copy the desired binary from the source
directory, I looked in the configure and makefile and just couldn't see
a way to do what I wanted. After I compiled it, I found all the
programs shadow installs in a directory called src. In it are sets of
files in the form filename.{,c,o}. Of course, in my situation I am
interested in only su, su.c and su.o. At this point can I just copy su
to /tools/bin? Do I need the other two files? If so, where do they go?
I'm extremely reluctant to encourage people to use that hint (over
the years, the lists have seen many problems and often the users
have neglected to mention they are using it until after a lot of
investigation). But I see people are still using versions of it, so
here goes -
You don't need to install the .c file, it's the source code.
Similarly, the .o is object code from the compile - it then has to
be linked before you can execute ('run') it.
Probably, src/su will not need any further libs. But when you get
to desktop packages they often rely on their own libraries. To be
sure, run 'ldd' on src/su and confirm that it only uses system
libraries (if it uses others, they will probably be marked as 'not
found' if shadow isn't installed - I'm assuming you are already in
chroot, so system libs will be in /tools apart from the vdso).
Alternatively, I have a question about how to use make install. The
following is part of the output from ./install-sh --help:
Usage: ./install-sh [OPTION]... [-T] SRCFILE DSTFILE
or: ./install-sh [OPTION]... SRCFILES... DIRECTORY
or: ./install-sh [OPTION]... -t DIRECTORY SRCFILES...
or: ./install-sh [OPTION]... -d DIRECTORIES...
In the 1st form, copy SRCFILE to DSTFILE.
In the 2nd and 3rd, copy all SRCFILES to DIRECTORY.
In the 4th, create DIRECTORIES.
The way I see this is that I'll get what I want if I run make install
su /tools/bin
Is this correct? Of course, I'm back to the copy mode if I can't
install this as user lfs. I do not want it suid.
Without looking at the Makefile(s), I'm reluctant to assume that
'make install' will do the same thing as ./install-sh. Perhaps it
does.
The usual way to look at what gets installed is to run 'make
DESTDIR=/path/to/somewhere install [ optional args ]' - once you get
into DESTDIR installs for looking at what is installed you will find
some packages use other variables (often INSTALLROOT or something
like that) - if shadow is such a package,then running *as a user*
will fail. So try it as a user, to a directory which that user can
write to.
If/when it is installed there, use ldd to confirm that it doesn't
need any not-present libraries.
But two more comments:
First, why not use --prefix=/tools when you configure it ?
Second, ISTR that su is a problem. My notes show that I tested the
code from
http://wiki.linuxfromscratch.org/hints/browser/trunk/PREVIOUS_FORMAT/more_control_and_pkg_man.txt?rev=904
last September (Bryan pointed to it last year, and I was
experimenting with building as a user to do DESTDIR LFS installs (so
I could log the files without accidentally doing a real install if
the package didn't respect DESTDIR - e.g. glibc uses INSTALLROOT or
similar). That didn't work for me (segfaulted when run as a user).
I perhaps tried su from the last version of coreutils - I'm not
sure. In the end, for BLFS I went through sudo (PITA, no added
security IMHO) and then found a (slow, voluminous) way of logging
all the files at the start of a package and after it completed, and
from that noting what got installed and what was updated -
My method still gives me erroneous 'updated' files if the first
attempt to install fails (usually from fubars in my scripts, e.g.
hard-coded filenames/versions - static libs, usually - getting
renamed or deleted) - but then anyone who writes scripts needs to
expect failures, and to learn *how* their own
Re: [lfs-support] Getting su in Chapter 5
On Mon, Oct 07, 2013 at 11:59:00PM +0100, Ken Moffat wrote: The usual way to look at what gets installed is to run 'make DESTDIR=/path/to/somewhere install [ optional args ]' - once you get into DESTDIR installs for looking at what is installed you will find some packages use other variables (often INSTALLROOT or something like that) - if shadow is such a package,then running *as a user* will fail. So try it as a user, to a directory which that user can write to. OK, so you can't try a DESTDIR install as a normal user because you are root and 'su' doesn't exist. Build outside the new system as user lfs and do a DESTDIR, e.g. to /home/lfs/somewhere or /tmp/somewhere. The same for su from old coreutils (my notes show that I had to build all of coreutils to get su linked - there might be a shorter series of commands - but NOT which old version of coreutils last contained 'su'. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] GCC specs file contains reference to /lib/ld-linux.so on a 64 bits machine
On Fri, Oct 04, 2013 at 11:15:30PM +0200, Afshin wrote: Hi LFS Team I've read in the LFS book v7.4 at the section “6.10. Adjusting the Toolchain” that is a good idea to visually inspect the GCC specs file and that's what I did. I've noticed that there are 2 references to /lib/ld-linux.so even if I'm using a 64 bits machine. So I replaced them by /lib64/ld-linux-x86-64.so.2. Am I wrong or there is really a mistake somewhere or maybe I made something wrong during the construction of the temporary system? /lib64/ld-linux-x86-64.so.2 is correct. ISTR that the book has a note that the filename may vary, but I'm not going to look up the details - I've already misled one person this week :) Generally do you have any feedback on the building of LFS on a 64 bits machine? Before upgrading to the 7.4 I was using LFS 6.4 on a 32 bits machine and had no such a problem. I've been using 64-bit on LFS since before it was officially supported. In the early days, a few BLFS packages such as jpegsrc.v6b (sic) got confused and required their config files (e.g. config.guess) to be updated. Other occasional packages such as popt insisted on using /usr/lib64 instead of /usr/lib. Everything was solveable. The current LFS method of symlinking /lib64 to /lib isn't as pure or clean, but it works ok. I read somewhere that using ldconfig is not recommended but I was obliged to use it to go ahead as I was stuck for 2 days on the compilation of the package file (problem to find the shared library libz). What do you mean by the package file ? Anyway, that sounds as if you made a mistake in installing libz : libz.so.1.2.8 should end up in /lib, with a symlink from /lib/libz.so.1 and another from /usr/lib/libz.so. This is a difference between 32-bit i686 and 64-bit : the static libz.a cannot be used in a shared 64-bit library, so the link fails if a shared libz isn't found. In 32-bit the link with libz.a will succeed, which might not be what you want. I use Debian 7 (wheezy) installed in a Vmware fusion VM which is in turn installed on an Apple iMac. Maybe glibc/gcc are too recent on my machine to build the temporary system... Best Regards Afshin LOL. A debian release too recent. After picking myself up from the floor, I suggest that building in a vm, and indeed using that hardware [ broken UEFI implementations have been noted on the kernel list, and each new version seems to bring problems with HID devices not being recognized by the kernel, until someone adds the fix ] are more likely to cause problems. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 6.17. GCC-4.8.1 - Linker search paths
On Mon, Sep 30, 2013 at 11:52:07PM -0500, Bruce Dubbs wrote: It can match if there is more than one SEARCH entry on the line. See below. You are right, of course. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 6.17. GCC-4.8.1 - Linker search paths
On Tue, Oct 01, 2013 at 03:27:22PM +1300, Craig Magee wrote: High folks, I'm building 7.4 Stable in 64-bit. GCC compiled, checked, and installed. The dummy file compiles. Tests show search paths for correct places for header files. However, grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' returns only: SEARCH_DIR(/usr/lib) SEARCH_DIR(/lib); while the book tells me to expect: SEARCH_DIR(/usr/x86_64-unknown-linux-gnu/lib64) SEARCH_DIR(/usr/local/lib64) SEARCH_DIR(/lib64) SEARCH_DIR(/usr/lib64) SEARCH_DIR(/usr/x86_64-unknown-linux-gnu/lib) SEARCH_DIR(/usr/local/lib) SEARCH_DIR(/lib) SEARCH_DIR(/usr/lib); Any advice on where I went wrong would be greatly appreciated. Thanks. Does the book tell you to expect that ? My local copy of 7.4 says that your results are correct. I think you might have been looking at a different version of the book, or a different page, along the way. In particular, that grep for '.*/usr/lib' cannot possibly match '/usr/x86_64-unknown-linux-gnu/lib'. I'm looking at 6.10 - are you looking at a different page ? ĸen, still up, and apparently making off-topic progress using an *old* bootloader version on ppc with LFS-7.4 :-) -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 6.17. GCC-4.8.1 - Linker search paths
On Tue, Oct 01, 2013 at 04:41:28PM +1300, Craig Magee wrote: On 1 October 2013 16:09, Ken Moffat zarniwh...@ntlworld.com wrote: On Tue, Oct 01, 2013 at 03:27:22PM +1300, Craig Magee wrote: However, grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' returns only: SEARCH_DIR(/usr/lib) SEARCH_DIR(/lib); while the book tells me to expect: SEARCH_DIR(/usr/x86_64-unknown-linux-gnu/lib64) SEARCH_DIR(/usr/local/lib64) SEARCH_DIR(/lib64) SEARCH_DIR(/usr/lib64) SEARCH_DIR(/usr/x86_64-unknown-linux-gnu/lib) SEARCH_DIR(/usr/local/lib) SEARCH_DIR(/lib) SEARCH_DIR(/usr/lib); Any advice on where I went wrong would be greatly appreciated. Thanks. Does the book tell you to expect that ? My local copy of 7.4 says that your results are correct. I think you might have been looking at a different version of the book, or a different page, along the way. In particular, that grep for '.*/usr/lib' cannot possibly match '/usr/x86_64-unknown-linux-gnu/lib'. Ah, I didn't think to take the time decoding the regular expression as they confuse the heck out of me. I copypasta'd it. http://www.linuxfromscratch.org/lfs/view/stable/chapter06/gcc.html It definitely states the block of text I quoted. Would the expected output listed for i686 systems also be incorrect? SEARCH_DIR(/usr/i686-pc-linux-gnu/lib) SEARCH_DIR(/usr/local/lib) SEARCH_DIR(/lib) SEARCH_DIR(/usr/lib); Ah, I was looking at 6.10 (Adjusting the toolchain), not 6.17. Interesting. In my logs I keep the actual output from dummy.log and that does have all of those. But I don't see how that (same) regexp can possibly return the first two results that we show. OTOH, I'm hours past my bedtime, maybe I'm missing something obvious. I'll defer to Matt or Bruce if they comment in the next few hours. At the moment it looks like such an obvious fubar that I would expect _someone_ to have noticed it, so I guess I'm probably out on my own again and leading you astray ;-) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Boot Issues
On Thu, Sep 26, 2013 at 05:43:51PM -0400, Casey Daniels wrote: Thanks for the info, but followed the instructions and as usual I get the grub rescue prompt which is a total different issue and question. But I tried what I have been trying to get the normal boot menu up set prefix(hd0,??) insmod normal normal now its saying no such partition. I ls at the rescue prompt and it shows the (HD0) but it gives no partitions to go along with it. Please don't top post, we hate it. You said this was variously a thumb drive and an SD card (you had a different issue with the real disk). You also said that you created an MSDOS partition table, but did you also create partitions, or are you trying to use the whole of /dev/sdX as a single filesystem ? If you do have partitions, then grub _might_ work with insmod ext2 set root='(hd0,msdosN)' where N is the partition number containing /boot - and presumably if /boot isn't a separate partition you would need to point to /boot/vmlinuz-whichever instead of just vmlinuz (dunno, I always have a separate /boot partition on my x86 machines). That _might_ be enough to solve the grub side of the problem, but you will still need to do something to let the kernel find the filesystem whichever disk it appears as (typically, use an initramfs, I believe). Just in case this isn't clear, the stick or external drive might be /dev/sdb or /dev/sdc at the moment, but it could shouw up as /dev/sda even if there is a real disk currently there, it all depends on which appears first and the order is unreliable across different kernels / different configs. So the intramfs has to contain enough of a system to then be able to mount the stick or external drive, e.g. by UUID (generally, the kernel doesn't understand UUIDs although the situation on GPT drives is, I think, slightly different). But I don't have experience in booting from removable drives/sticks. I suggest that you change your plans: 1. Get it to boot on the spinning-rust /dev/sda. That will allow you to prove that the completed system is usable. If you can't get this to work, please report the error(s) in detail, along with your partitioning. You WILL also need a rescue CD in case things become broken. 2. Study the various posts which google finds about booting to a removable disk / memory stick. There are a number of different (and probably incompatible) solutions. In particular, look at the 'About initramfs' page in BLFS : http://www.linuxfromscratch.org/blfs/view/svn/postlfs/initramfs.html although that doesn't specifically talk about booting from external usb drives. http://www.linuxquestions.org/questions/linux-from-scratch-13/booting-lfs-from-usb-stick-897465/ might have something useful in it (for the grub suggestions). There have been many threads here over the years, but the mail archives aren't available so I can no longer point you to them. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] chroot into the temporary ...?
On Wed, Sep 25, 2013 at 08:41:37AM +0800, Wiky wrote: hi, It reads 'That is, we chroot into the temporary mini Linux system, ..' in Section6.1 of LFS7.4. but when i run 'sudo chroot /mnt/lfs', Why do you think that 'sudo' is the command to run here ? Do we build sudo in chapter 5 (/tools) ? it returns 'chroot: failed to run command `/bin/bash': No such file or directory'. Of course /mnt/lfs/bin/bash not exists and then I tried 'sudo chroot /mnt/lfs/tools', it also 'chroot: failed to run command `/bin/bash': No such file or directory',but /mnt/lfs/tools/bin/bash exists. I really have no idea with the problem,maybe I have missed something in Ch5? Thanks in advance and sorry for my English. Apart from using sudo instead of su, why doesn't /bin/bash exist in /mnt/lfs ? If you are following the book, we create the /mnt/lfs/bin/bash symlink in section 6.6 - and we enter chroot *after* that, not in section 6.1. I'm sure that reading the book is *hard* for people who don't have English as a native language, but you seem to be making false assumptions about what the book says. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Man Pages and Man-DB
On Sun, Sep 22, 2013 at 09:38:04PM -0400, Casey Daniels wrote: I think I know the answer, but searched a bit and couldn't find a direct answer, but would there be any situation someone can think of where not installing Man-Pages (6.8) and Man-DB (6.56) could cause problems? Looked through the dependices for the Base LFS system and didn't see any issues, but I'm guessing there is some package somewhere that I'll ended up wanting to install that requires it. The system I'm making really doesn't have any need for Man Pages since its a server that no one really should be logged directly on it. Thank You AFAICS things should be fine without them. For a server, the usual reason to have them is probably to help with debugging the setup. Many packages install a few man pages of their own, but that doesn't mean you have to read them. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Error building gcc pass 2 in ch.5
On Wed, Sep 18, 2013 at 09:39:01PM +0200, hans kaper wrote: After failing to be able to use the tools from LFS 7.3 in 7.4, I decided to build the tools from the book 7.4. I soon ran into another problem: after building the tools up and until Binutils pass 2 without errors, I got the following error building GCC, pass 2: i686-lfs-linux-gnu-g++ -c -fomit-frame-pointer -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.8.1/gcc -I../../gcc-4.8.1/gcc/build -I../../gcc-4.8.1/gcc/../include -I../../gcc-4.8.1/gcc/../libcpp/include -I/mnt/lfs/sources/gcc-build/./gmp -I/mnt/lfs/sources/gcc-4.8.1/gmp -I/mnt/lfs/sources/gcc-build/../gcc-4.8.1/mpfr/src -I/mnt/lfs/sources/gcc-4.8.1/mpc/src -I../../gcc-4.8.1/gcc/../libdecnumber -I../../gcc-4.8.1/gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc-4.8.1/gcc/../libbacktrace\ -o build/genconstants.o ../../gcc-4.8.1/gcc/genconstants.c In file included from ../../gcc-4.8.1/gcc/genconstants.c:28:0: ../../gcc-4.8.1/gcc/system.h:205:20: fatal error: cstring: No such file or directory # include cstring ^ compilation terminated. The file cstring is not found. I assume it has to be somewhere in the gcc-build but I don't know why not. I deleted the tools and started anew, with the same result. The md5sum for GCC is correct and so are the system-requirements. The build-directories were deleted from /source after the pass 1-build. Any idea what is wrong? Google thinks you didn't install libstdc++v3 : http://www.linuxquestions.org/questions/linux-from-scratch-13/gcc-error-building-tools-on-7-4-rc1-chapter-5-10-gcc-4-8-1-pass-2-a-4175475181/ ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] lfs7.0 5.7 installation glibc. configure: WARNING: using cross tools not prefixed with host triplet
On Mon, Sep 16, 2013 at 05:36:20PM +0200, andreas graeper wrote:
book-version is 7.0, see subject.
And that, in linux terms, is ancient history - we've had four more
releases, a lot of things have changed.
the testprogram is linked against /tools/lib/libgcc_s.so
libgcc_s and libstdc++ are linked from /usr/lib to /tools/lib
That sounds correct
why libstdc++ was build ?
when it is build, is it done with c-compiler or with the wrong (host-)
g++-compiler ?
At that time, we built it with the C compiler. In 7.4, gcc-4.8.1
is used : 4.8 needs c++ which is why Bruce mentioned.
I don't understand why you are questioning why libstdc++ was built.
The system needs a c++ compiler, and that needs libstdc++.
what is libgcc_s ? google shows only error messages ('not found' and so on)
.
The most likely answer I can find is at
http://unix.stackexchange.com/questions/1812/what-does-libgcc-s-so-contain
i.e. it's a gcc runtime library.
could this problem get solved by 're-adjusting the toolchain' (6.10) before
this test (glibc make install in 6.9) ?
thanks in advance
andreas
I guess the error message about cross-compilation means that
somewhere you are still using the cross-compiler which was built
in gcc pass 1, or else that something went seriously wrong with the
instructions in gcc pass 2.
I'm going to stick my neck out and suggest that you didn't delete
the existing source and -build directories when you came to Pass 2 ?
It is essential to use clean source, and empty -build directories
where those are used, for *every* package.
If that guess is correct you will be better to start again. Nobody
remembers the details of a 2-year-old set of instructions, and the
system will be out of date. So I suggest that you use the 7.4 book.
Check the host requirements and update anything which is too old.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] gcc error
On Sun, Sep 08, 2013 at 09:48:53AM +0800, Rob Chua wrote: I'm having problems with gcc can you help me with this error? true DO=all multi-do # make make[3]: Leaving directory `/sources/gcc-build/i686-pc-linux-gnu/libitm' make[2]: Leaving directory `/sources/gcc-build/i686-pc-linux-gnu/libitm' make[1]: Target `check-target' not remade because of errors. make[1]: Leaving directory `/sources/gcc-build' make: *** [do-check] Error 2 make: Target `check' not remade because of errors. what does this mean? It means there was at least one error in the gcc testsuite. Libitm was the last subdirectory in which check ran, but the error(s) could be in any of the subdirectories. But you have already reported the errors and got a response from Bruce. What is your problem ? Is it the wording Target 'check'not remade because of errors.? That's just how the gcc testsuite works : the Makefiles list targets for check (e.g. do-check) and in normal 'make' style they have to be updated if any dependency changed. But this doesn't happen if you had an error (if it did, I guess that 'make check' would loop for ever). ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] ABOUT LFS
On Sat, Sep 07, 2013 at 05:40:27PM -0700, Pwn Me wrote: i have a question.. how can i edit the PATH=tools/bin:/bin:/usr/bin to PATH=tools/bin:/bin:/usr/bin:/tools/sbin:/sbin:/usr/sbin? 'coz i tried to use export to edit this command and when i reboot the system, the PATH thing goes back to the original syntax.. :/ After looking at the name you use for your email account, I have to ask why don't you just run everything as root ? - it will make it much easier for people to own your system ;-) I'm joking, but I start to wonder if you are trolling. For a safer system, limiting privileges is a good idea. To shut down a *desktop* box, I'm happy using a hack to let a user run 'shutdown' - but I'm the only user of those machines, and I can only run the user shutdown script from a tty (not an xterm, nor when using ssh to connect to a system). Some other people use 'sudo' and allow (some) normal users to shutdown, others run desktop environments where ConsoleKit gives permissions to whoever is at the physical machine. Every alternative method has its own advantages an disadvantages. Also, the /tools part of the PATH should be unnecessary after you have completed chapter 6 of LFS. If you need to go back in to chroot to edit some files, chroot /mnt/lfs should work fine - if it doesn't, you've got other problems. In any case, why would you prefer to run the programs from /tools/sbin in preference to /sbin or /usr/sbin ? - hint: a program will be run from the first directory which contains a program of that name. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 6.17 GCC-4.7.2 error :(
On Sat, Aug 31, 2013 at 06:50:35PM -0700, Pwn Me wrote: thanks for the reply.. all were marked as FAIL my processor is Intel® Core™2 Duo CPU T6400 @ 2.00GHz × 2 i'm working in Linux Ubuntu 13.04 i can't find the kernel version. :3 And did you have anything listing the details from the tests ? I'm not familiar with libitm, but I assume that each test which fails will create a file showing the expected result and the actual result. The kernel version should be available from 'uname -r' but that distro is recent enough. Did you make the /bin/sh link to bash before you started building LFS ? If you are using dash as the shell on the host, it can trigger all sorts of problems. I'm not expecting that to cause a problem in chroot, but your problem is uncommon. Core 2 is a perfectly common i686 processor - I wondered if you were running on something unusual. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 6.17 GCC-4.7.2 error :(
On Sat, Aug 31, 2013 at 05:21:31PM -0700, Pwn Me wrote: now i'm stuck with this kind of errors. when i type make -k check.. it appears: === libitm Summary === # of unexpected failures15 # of unresolved testcases14 # of unsupported tests1 make[4]: *** [check-DEJAGNU] Error 1 make[4]: Leaving directory `/sources/gcc-build/i686-pc-linux-gnu/libitm/testsuite' make[3]: *** [check-am] Error 2 make[3]: Target `check' not remade because of errors. make[3]: Leaving directory `/sources/gcc-build/i686-pc-linux-gnu/libitm/testsuite' make[3]: Entering directory `/sources/gcc-build/i686-pc-linux-gnu/libitm' true DO=all multi-do # make make[3]: Leaving directory `/sources/gcc-build/i686-pc-linux-gnu/libitm' make[2]: *** [check-recursive] Error 1 make[2]: Target `check' not remade because of errors. make[2]: Leaving directory `/sources/gcc-build/i686-pc-linux-gnu/libitm' make[1]: *** [check-target-libitm] Error 2 make[1]: Target `check-target' not remade because of errors. make[1]: Leaving directory `/sources/gcc-build' make: *** [do-check] Error 2 make: Target `check' not remade because of errors. i'm afraid to proceed to next step because of this.. can you help me guys please? :( thanks by the way. Did you log it ? If so, which tests were marked as FAIL ? If you didn't, it is possible there might have been other failures in other directories. But assuming these libitm failures are the only problem - is there anything in gcc-4.7.2/libitm/testsuite which records what failed ? You might do better looking from the host system, where you will have 'less' or 'view'. Errors in libitm seem to be uncommon. What is your processor, your host distro, and your kernel version ? I've had a look at google - your results look surprisingly close to http://gcc.gnu.org/ml/gcc-bugs/2013-06/msg00695.html which was on OSX not linux. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
