Re: [lfs-support] Proposed Changes to LFS Book

2014-01-16 Thread D. Birch
On 16 January 2014 00:59, Ken Moffat zarniwh...@ntlworld.com wrote:

 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


I have returned to LFS a number of times, I use the whole experience as a
learning resource and yes, it still is too advanced for me, but I would
appreciate the additional slightly more wordy text, because it aids my
understanding of the process of sanitizing.


 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).


Ditto here, this increases my ability to Google something meaningful.


  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

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


[lfs-support] GCC-$.8.1 Configure fatal errors

2014-01-16 Thread William Darryl Jackson
Greetings, back in GCC-4.8.1 again section 5.5.1 - after re-reading 
everything I decided to do as suggested to try to find out why I am 
having so much difficulty with this 'make'.


In the config.log I found the following fatal errors:

Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5)
configure:4212: $? = 0
configure:4201: gcc -V 5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:4212: $? = 4
configure:4201: gcc -qversion 5
gcc: error: unrecognized command line option '-qversion'
gcc: fatal error: no input files
compilation terminated.

It is also failing while checking for versions .10 and .11 of ISL:

conftest.c:10:25: fatal error: isl/version.h: No such file or directory.

After the the configure appears to complete successfully. Should I be 
concerned about either of these two failures?


Thanks,

William
-- 
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-$.8.1 Configure fatal errors

2014-01-16 Thread William Harrington

On Jan 16, 2014, at 9:46 AM, William Darryl Jackson wrote:

 After the the configure appears to complete successfully. Should I  
 be concerned about either of these two failures?

 Thanks,

 William

No, it is testing a system for which compiler is installed and which  
options to include for the build. If configure fails, then it is a  
problem. If configure exits in success, then it is fine.

You will see lots of failed tests in the config.log. It doesn't mean  
the configure script failed.

Sincerely,

WIlliam Harrington
-- 
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-$.8.1 Configure fatal errors

2014-01-16 Thread Pierre Labastie
Le 16/01/2014 16:49, William Darryl Jackson a écrit :
 On 01/16/2014 10:46 AM, William Darryl Jackson wrote:
 Greetings, back in GCC-4.8.1 again section 5.5.1 - after re-reading 
 everything I decided to do as suggested to try to find out why I am 
 having so much difficulty with this 'make'.

 In the config.log I found the following fatal errors:

 Thread model: posix
 gcc version 4.7.2 (Debian 4.7.2-5)
 configure:4212: $? = 0
 configure:4201: gcc -V 5
 gcc: error: unrecognized command line option '-V'
 gcc: fatal error: no input files
 compilation terminated.
 configure:4212: $? = 4
 configure:4201: gcc -qversion 5
 gcc: error: unrecognized command line option '-qversion'
 gcc: fatal error: no input files
 compilation terminated.

 It is also failing while checking for versions .10 and .11 of ISL:

 conftest.c:10:25: fatal error: isl/version.h: No such file or directory.

 After the the configure appears to complete successfully. Should I be 
 concerned about either of these two failures?
Hello William,

The configure script tries a lot of things to guess the capabilities 
of the system. Sometimes, an error contains some informations that are 
usefull to determine those capabilities. For example, to test if a 
header file (say xxx.h) can be accessed, it runs gcc on a small C 
program, which contains a line:
#include xxx.h

Then, if gcc ends with an error, configure interprets it as xxx.h being 
not acessible, and may stop or not, depending whether xxx.h is required 
or not. Meanwhile, you'll see the error message of gcc, somthing like:
cannot find xxx.h or whatever.

It does not mean that configure found an error. So the outpur you see is 
not configure errors, but negative tests. You do not have to be worried 
about that.

So, go ahead, and run make.

Cross fingers
Pierre

-- 
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-$.8.1 Configure fatal errors

2014-01-16 Thread Fernando de Oliveira
Em 16-01-2014 13:37, Pierre Labastie escreveu:
 Le 16/01/2014 16:49, William Darryl Jackson a écrit :
 On 01/16/2014 10:46 AM, William Darryl Jackson wrote:
 Greetings, back in GCC-4.8.1 again section 5.5.1 - after re-reading 
 everything I decided to do as suggested to try to find out why I am 
 having so much difficulty with this 'make'.

 In the config.log I found the following fatal errors:

 Thread model: posix
 gcc version 4.7.2 (Debian 4.7.2-5)
 configure:4212: $? = 0
 configure:4201: gcc -V 5
 gcc: error: unrecognized command line option '-V'
 gcc: fatal error: no input files
 compilation terminated.
 configure:4212: $? = 4
 configure:4201: gcc -qversion 5
 gcc: error: unrecognized command line option '-qversion'
 gcc: fatal error: no input files
 compilation terminated.

 It is also failing while checking for versions .10 and .11 of ISL:

 conftest.c:10:25: fatal error: isl/version.h: No such file or directory.

 After the the configure appears to complete successfully. Should I be 
 concerned about either of these two failures?
 Hello William,
 
 The configure script tries a lot of things to guess the capabilities 
 of the system. Sometimes, an error contains some informations that are 
 usefull to determine those capabilities. For example, to test if a 
 header file (say xxx.h) can be accessed, it runs gcc on a small C 
 program, which contains a line:
 #include xxx.h
 
 Then, if gcc ends with an error, configure interprets it as xxx.h being 
 not acessible, and may stop or not, depending whether xxx.h is required 
 or not. Meanwhile, you'll see the error message of gcc, somthing like:
 cannot find xxx.h or whatever.
 
 It does not mean that configure found an error. So the outpur you see is 
 not configure errors, but negative tests. You do not have to be worried 
 about that.


 Cross fingers
 Pierre
 

Thank you very much, Pierre. I had learned by experience rudiments of
you what you wrote, but this is a very good explanation and hpoe to get
it organized in my mind. :-)

-- 
[]s,
Fernando
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


[lfs-support] Two suspected bugs

2014-01-16 Thread parmenides
Hi,

I am build the LFS 7.4 following the book, and find two suspected bugs:

(1) In Preface, vii. Host System Requirements,
the version of tar is required 1.18, but this version does not support
xz format at all.As such, the following command will fail:
tar Jxvf foo.tar.xz
Although using xz first then tar will work, I think it is recomended to
upgrade tar to support new options.

(2) In chapter 5, 5.7. Glibc-2.18
I got the following warning:

configure: WARNING:
*** These auxiliary programs are missing or incompatible versions: autoconf
*** some features will be disabled.
*** Check the INSTALL file for required versions.

I seems that there should be some requirements of autoconf.

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Two suspected bugs

2014-01-16 Thread Chris Staub
On 01/16/14 13:00, parmenides wrote:
 Hi,

 I am build the LFS 7.4 following the book, and find two suspected bugs:

 (2) In chapter 5, 5.7. Glibc-2.18
 I got the following warning:

 configure: WARNING:
 *** These auxiliary programs are missing or incompatible versions: autoconf
 *** some features will be disabled.
 *** Check the INSTALL file for required versions.

 I seems that there should be some requirements of autoconf.

No, Autoconf is not needed. That is just warning, not an error.

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Two suspected bugs

2014-01-16 Thread William Harrington

On Jan 16, 2014, at 12:00 PM, parmenides wrote:

 (2) In chapter 5, 5.7. Glibc-2.18
 I got the following warning:

 configure: WARNING:
 *** These auxiliary programs are missing or incompatible versions:  
 autoconf
 *** some features will be disabled.
 *** Check the INSTALL file for required versions.

 I seems that there should be some requirements of autoconf.

This has been stated at the support list numerous times.

GLIBC does not require autotools on the host for it to build.

Ignore the warning.

Sincerely,

WIlliam Harrington
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Two suspected bugs

2014-01-16 Thread William Harrington

On Jan 16, 2014, at 1:04 PM, William Harrington wrote:

 The New short option -J (alias for --lzma) was put in 1.20.90 which is
 in 1.22.

This didn't make it,

Also for the release note: http://freecode.com/projects/tar/releases/295528

Sincerely,

William Harrington
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


[lfs-support] Gcc-4.8.1 Section 5.5.1 - libmpfr

2014-01-16 Thread William Darryl Jackson

Greetings,

My first pass of make produced the following error:

checking for MPFR... no
configure: error: libmpfr not found or uses a different ABI (including 
static vs shared).

make[1]: *** [configure-mpc] Error 1
make[1]: Leaving directory `/mnt/lfs/sources/gcc-build'
make: *** [all] Error 2

I have triple-checked my configure syntax.

Any thoughts,

William
-- 
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-4.8.1 Section 5.5.1 - libmpfr

2014-01-16 Thread Pierre Labastie
Le 16/01/2014 22:15, William Darryl Jackson a écrit :
 Greetings,
 
 My first pass of make produced the following error:
 
 checking for MPFR... no
 configure: error: libmpfr not found or uses a different ABI (including static
 vs shared).
 make[1]: *** [configure-mpc] Error 1
 make[1]: Leaving directory `/mnt/lfs/sources/gcc-build'
 make: *** [all] Error 2
 
 I have triple-checked my configure syntax.
 

It seems you already reported that error on January 11th... Have you extracted
and renamed gmp, mpfr and mpc to the source directory
(/mnt/lfs/sources/gcc-4.8.1)?

Regards
Pierre
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


Re: [lfs-support] Building Check-0.9.10 fails and fixed

2014-01-16 Thread Loïc Le Ninan
Davis Abubakr-Sadik Nii Nai dwa2pac at gmail.com writes:

 
 
 Hello list,
 I am trying to build LFS 7.4 stable. The package check-0.9.10 in
 section 5.14 failed to build.
 I got it to build, but would like to ask if anyone has come across
 this problem, and since it's not documented anywhere make it known
 to the list. Also a better fix, is welcome.
[...]
   In file included from libcompat.c:1:0:
   libcompat.h:133:13: error: conflicting types for 'timer_t'
    typedef int timer_t;
    ^
[...]
   make[2]: *** [libcompat.lo] Error 1
   make[2]: Leaving directory `/mnt/lfs/usr/src/check-0.9.10/lib'
   make[1]: *** [all-recursive] Error 1
   make[1]: Leaving directory `/mnt/lfs/usr/src/check-0.9.10'
   make: *** [all] Error 2Status: Resolved



Hello, 

Posting this message for archive, following a thread from last october :
Building Check-0.9.10 fails and fixed. 

This was about a failure in step 5.14 of LFS 7.4, with 'make' complaining
about conflicting types for 'timer_t' in libcompat.h. 

Suggestion was made to patch the source code with a few custom lines in
order to prevent this error from raising. But I am facing this very same
issue right now, and I think it is a deeper problem so I would not recommend
patching. 


'configure' logs this line : checking for ld used by gcc... /usr/bin/ld

My /tools/bin contains : 
- i686-lfs-linux-gnu-gcc with timestamp corresponding to pass 1
- i686-pc-linux-gnu-gcc with timestamp corresponding to pass 2
- gcc (a copy of i686-pc-linux-gnu-gcc from pass 2)
- cc - gcc

export CC=/tools/bin/i686-pc-linux-gnu-gcc before configure  make : it fails. 
export CC=/tools/bin/i686-lfs-linux-gnu-gcc before configure  make : it works. 

So something probably went wrong in gcc pass 2, and it would be best to
start over again from scratch I suppose :-( 

I hope this can help others facing the same problem. 





-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page


[lfs-support] 5.8 Libstdc++-4.8.1

2014-01-16 Thread Louis Rine
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.

I saw that another person on this list also had this error, but that
discussion didn't seem to advance very far.

I was able to compile the dummy program and get the correct response from
the readelf ... | grep command after compiling glibc.

During the configure, it had this stuff:

checking whether ln -s works... yes
checking for x86_64-lfs-linux-gnu-as... x86_64-lfs-linux-gnu-as
checking for x86_64-lfs-linux-gnu-ar... x86_64-lfs-linux-gnu-ar
*checking for x86_64-lfs-linux-gnu-ranlib... x86_64-lfs-linux-gnu-ranlib*
checking whether to enable maintainer-specific portions of Makefiles... no
configure: CPU config directory is cpu/i486
configure: OS config directory is os/gnu-linux
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for fgrep... /bin/grep -F
checking for ld used by x86_64-lfs-linux-gnu-gcc...
/mnt/lfs/tools/x86_64-lfs-linux-gnu/bin/ld

and so forth, so it seems to be finding x86_64-lfs-linux-gnu-ranlib during
the configure run, but not during the make install.

I don't get it. If any of y'all gurus could suggest where my error might
be, I'd be much obliged. After I had this problem the first time, I wiped
the entire lfs partition, re-downloaded the source code, and ran build
again up to this point, and got the same error, so it's clearly something
specific, I just don't know what.

Thanks for any help. :)
-- 
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-4.8.1 Section 5.5.1 - libmpfr

2014-01-16 Thread William Darryl Jackson
On 01/16/2014 04:23 PM, Pierre Labastie wrote:
 Le 16/01/2014 22:15, William Darryl Jackson a écrit :
 Greetings,

 My first pass of make produced the following error:

 checking for MPFR... no
 configure: error: libmpfr not found or uses a different ABI (including static
 vs shared).
 make[1]: *** [configure-mpc] Error 1
 make[1]: Leaving directory `/mnt/lfs/sources/gcc-build'
 make: *** [all] Error 2

 I have triple-checked my configure syntax.

 It seems you already reported that error on January 11th... Have you extracted
 and renamed gmp, mpfr and mpc to the source directory
 (/mnt/lfs/sources/gcc-4.8.1)?

 Regards
 Pierre
You are correct - Pierre, I came to that same conclusion. So I very 
carefully repeated the steps on page 36 to ensure those folders were 
being built correctly (owner/group=lfs) then (delete contents of 
gcc-build; reconfigure, and make) -No change; this error must be 
pointing to something else with my system.

My Internet searches indicate that others have had similar problems, but 
I saw no resolution. What if any is the host interaction at this point? 
Gotta find somewhere else to look.

Thanks,

William
-- 
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

2014-01-16 Thread Ken Moffat
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

2014-01-16 Thread Louis Rine
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...

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

Binutils: (GNU Binutils for Ubuntu) 2.23.2

bison (GNU Bison) 2.5

/usr/bin/yacc - /usr/bin/bison.yacc

bzip2,  Version 1.0.6, 6-Sept-2010.

Coreutils:  8.20

diff (GNU diffutils) 3.2

find (GNU findutils) 4.4.2

GNU Awk 4.0.1

/usr/bin/awk - /usr/bin/gawk

gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3

g++ (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3

(Ubuntu EGLIBC 2.17-0ubuntu5.1) 2.17
grep (GNU grep) 2.14
gzip 1.5
Linux version 3.8.0-23-generic (buildd@batsu) (gcc version 4.7.3
(Ubuntu/Linaro 4.7.3-1ubuntu1) ) #34-Ubuntu SMP Wed May 29 20:22:58 UTC 2013
m4 (GNU M4) 1.4.16
GNU Make 3.81
patch 2.6.1
Perl version='5.14.2';
GNU sed version 4.2.1
tar (GNU tar) 1.26
Texinfo: makeinfo (GNU texinfo) 4.13
xz (XZ Utils) 5.1.0alpha
g++ compilation OK

Which seemed ok, perhaps I missed something there after all?



On Thu, Jan 16, 2014 at 5:23 PM, Ken Moffat zarniwh...@ntlworld.com wrote:

 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

-- 
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

2014-01-16 Thread Ken Moffat
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] 5.8 Libstdc++-4.8.1

2014-01-16 Thread Louis Rine
Ah, I was wondering if dash would make a difference. I will fix that and
try again. Thank you. :)


On Thu, Jan 16, 2014 at 5:53 PM, Ken Moffat zarniwh...@ntlworld.com wrote:

 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

-- 
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

2014-01-16 Thread William Harrington

On Jan 16, 2014, at 5:56 PM, Louis Rine wrote:

 Ah, I was wondering if dash would make a difference. I will fix that  
 and try again. Thank you. :)

It does, and that is why the host system requirements states:

Bash-3.2 (/bin/sh should be a symbolic or hard link to bash)

But that may not be your only issue.

I suggest you check the host system requirements.

Sincerely,

William Harrington
-- 
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-4.8.1 Section 5.5.1 - libmpfr

2014-01-16 Thread Chris Staub
On 01/16/14 18:07, William Darryl Jackson wrote:
 On 01/16/2014 04:23 PM, Pierre Labastie wrote:
 Le 16/01/2014 22:15, William Darryl Jackson a écrit :
 You are correct - Pierre, I came to that same conclusion. So I very
 carefully repeated the steps on page 36 to ensure those folders were
 being built correctly (owner/group=lfs) then (delete contents of
 gcc-build; reconfigure, and make) -No change; this error must be
 pointing to something else with my system.

 My Internet searches indicate that others have had similar problems, but
 I saw no resolution. What if any is the host interaction at this point?
 Gotta find somewhere else to look.

 Thanks,

 William

Type history as the lfs user, and paste every command you have run for 
building GCC, starting with unpacking its source tarball.
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page