[lfs-support] GCC build first pass: mpc build looks for libgmp.la in the wrong place

2013-10-22 Thread Hazel Russman
I am trying to build a 64-bit lfs-7.4 system using a host system based on Slackware-14. Currently I am having a problem with the first pass of building gcc. During the internal build of libmpc, a search is made for /usr/lib64/libgmp.la. It is not found, so the build crashes. libtool: link: ar

Re: [lfs-support] GCC build first pass: mpc build looks for libgmp.la in the wrong place

2013-10-25 Thread Hazel Russman
On Tue, 22 Oct 2013 10:16:53 -0500 Bruce Dubbs wrote: > Hazel Russman wrote: > > I am trying to build a 64-bit lfs-7.4 system using a host system > > based on Slackware-14. Currently I am having a problem with the > > first pass of building gcc. During the internal build of

[lfs-support] glibc build in LFS7.4.

2013-11-06 Thread Hazel Russman
My Chapter 6 glibc check gave four errors. Three of them (getaddrinfo4, annexc and run-conformtest) are expected but the fourth in globtest is not mentioned in the book. Here is the immediate context: /bin/sh globtest.sh /sources/glibc-build/ ' /sources/glibc-build/elf/ld-linux-x86-64.so.2 --libra

Re: [lfs-support] GCC build first pass: mpc build looks for libgmp.la in the wrong place

2013-12-04 Thread Hazel Russman
On Mon, 2 Dec 2013 12:01:38 + (UTC) Thomas Kupper wrote: > G'day, > > I was coming across that error while trying to cross compile mpc for > later use with gcc using Optware building system (nothing to do with > LFS I agree). In my case it was mpc which did complain but mpfr was > the one ca

Re: [lfs-support] GCC build first pass: mpc build looks for libgmp.la in the wrong place

2013-12-04 Thread Hazel Russman
On Wed, 04 Dec 2013 11:57:14 + lf...@cruziero.com (akhiezer) wrote: > > Date: Wed, 4 Dec 2013 11:40:23 + > > From: Hazel Russman > > To: lfs-support@linuxfromscratch.org > > Subject: Re: [lfs-support] GCC build first pass: mpc build looks for > >

Re: [lfs-support] GCC build first pass: mpc build looks for libgmp.la in the wrong place

2013-12-06 Thread Hazel Russman
On Thu, 05 Dec 2013 18:08:56 + lf...@cruziero.com (akhiezer) wrote: > Sanity-checks: > --- > * your host-os (Slackware 14.0) is 64-bit (what does 'uname -a' show)? x86_64 as expected. > * _prior_ to your creation of the symlink that you note below, did > '/usr/lib64/libgmp.la' exist in th

Re: [lfs-support] GCC build first pass: mpc build looks for libgmp.la in the wrong place

2013-12-07 Thread Hazel Russman
On Fri, 06 Dec 2013 21:05:51 + lf...@cruziero.com (akhiezer) wrote: > > Just to check: did you use underscores there - i.e. in the above > > --with_gmp_include=$(pwd)/gmp and --with_gmp_lib=$(pwd)/gmp/.libs > > ; or did you use hyphens/dashes thus: > > --with-gmp-include=$(pwd)/gmp --with-

Re: [lfs-support] GCC build first pass: mpc build looks for libgmp.la in the wrong place

2013-12-07 Thread Hazel Russman
On Sat, 7 Dec 2013 14:13:49 -0600 William Harrington wrote: > > On Dec 7, 2013, at 1:38 PM, Hazel Russman wrote: > > > On a full Slackware install, no one would notice this. Who is going > > to root around in archive files looking for bad dependency paths > > when e

Re: [lfs-support] GCC build first pass: mpc build looks for libgmp.la in the wrong place

2013-12-08 Thread Hazel Russman
On Sun, 08 Dec 2013 13:48:41 + lf...@cruziero.com (akhiezer) wrote: > Hmmm. Three slightly-indirect observations (hopefully not too > off-topic ;) ): -- > * can you post the output, please, of each of: > $ ls -latrF /usr/lib64/lib{gmp,mpc,mpfr}* -rwxr-xr-x 1 root root 77656 Feb 8 2011 /u

Re: [lfs-support] GCC build first pass: mpc build looks for libgmp.la in the wrong place

2013-12-11 Thread Hazel Russman
On Mon, 09 Dec 2013 19:13:08 + lf...@cruziero.com (akhiezer) wrote: > Should also have double-checked the following related info. Does your > host-os look the same as these - no need to post if yes to all: > $ ls -latrF /usr/lib64/libmp.* > -rwxr-xr-x 1 root root 275184 May 27 2012 /usr/lib64

Re: [lfs-support] GCC build first pass: mpc build looks for libgmp.la in the wrong place

2013-12-17 Thread Hazel Russman
On Tue, 17 Dec 2013 15:11:29 + lf...@cruziero.com (akhiezer) wrote: > Hazel, > > > I gather that you've sent a reply - in which you substantially or > completely solve the issue - that hasn't reached the list yet since > the weekend: it might be the attachment that's causing the trouble; > c

[lfs-support] ACL check errors: are they important?

2014-04-21 Thread Hazel Russman
I am building a 7.5 LFS with systemd and currently working through chapter 6. Having successfully installed coreutils, I rebuilt acl and ran the test suite. Initially I got 47 errors! According to BLFS, the acl test suite requires a daemon user who is also in the bin group (currently section 6.6 o

Re: [lfs-support] ACL check errors: are they important?

2014-04-21 Thread Hazel Russman
On Mon, 21 Apr 2014 18:32:49 +0200 "Armin K." wrote: > Drop the "root-tests", they are broken anyways. I couldn't even get > them to run with daemon user present. > I didn't do the root tests. These were the standard ones invoked with "make tests" though of course I was logged in as root when I

Re: [lfs-support] ACL check errors: are they important?

2014-04-21 Thread Hazel Russman
On Mon, 21 Apr 2014 19:25:10 +0200 Pierre Labastie 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 beginn

Re: [lfs-support] ACL check errors: are they important?

2014-04-22 Thread Hazel Russman
On Mon, 21 Apr 2014 22:14:31 +0100 Ken Moffat wrote: > From memory (so, I might be wrong) the book doesn't ever create a > 'users' group in LFS... > > 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

Re: [lfs-support] ACL check errors: are they important?

2014-04-22 Thread Hazel Russman
On Tue, 22 Apr 2014 13:42:58 +0200 Pierre Labastie wrote: > It seems that the "bin" group membership > of the "daemon" user is not needed. Could you confirm? Confirmed. It is also not necessary to set real home directories or shells for the bin and daemon users as specified in BLFS. /dev/null an