On Mon, Feb 16, 2015 at 06:56:04PM -0500, [email protected] wrote:
> Just finished my 64bit-only LFS 7.6 and preparing to begin BLFS chapter 3.
> My first step includes establishing a capability for copy/paste and
> downloading files to follow BLFS chapter 3 and beyond and there seems to be
> two options for achieving this.  One is to install openssh/openssl and
> access the new BLFS system from a second machine with a desktop, or (2).
> Install GPM, Lynx, wget [as described at the end of the LFS 6.6 book] and
> use the BLFS terminal window.  The first option seemed preferable and since
> openssl is common to both approaches I attempted to install openssl-1.0.1i
> first. 
> 
 If you stick with LFS/BLFS, for your next build you will probably
want to build some more packages before rebooting (e.g. wget,
links).

 But there is one thing I cannot tell from your post - have you
managed to boot the new system, and log in ?  That is generally a
good idea, it proves that not too much is wrong, even if you then go
back to chroot to build the next packages.

 However, you seem to have missed a third option (I'm assuming your
host has a working desktop) - use a term on the host's desktop to
chroot and build, use a browser to read the book, download, and copy
commands from the book, use another term to copy the files to the LFS
system.
> 
> After moving the tar file and patch into /sources I used the LFS chroot
> environment on the Lubuntu host.  Using the instructions in the BLFS book
> for installing openssl-1.0.1i the patch seemed to work fine. The ./config
> command successfully identified the system as "linux-x86_64".  However the
> compilation terminated in an error:  
> 
>  
> 
> Fatal error: sys/cdefs.h: No such file or directory
> 
> #Include <sys/cdefs.h>
> 
> Recipe for target 'cryptlib.o' failed
> 
>  

 Google is vague on this, but the reports for x86 seem to be about
building 32-bit x86 (i686, i386, call it what you will) on 64-bit
x86 (x86_64, amd64).  We do not do that (we are not multilib).
So why does your new LFS system in chroot misconfigure openssl ?

 What do you get if you type, in LFS

ldd $(type -pa bash)

 in particular, is it using /lib64/ld-linux-x86-64.so.2 ?

 Also, what is the output of 'uname -m' in LFS ?  I am expecting
x86_64 and config apparently got that result.

 Can you use clean source (i.e. blow away the openssl directory,
re-extract, re-apply the patch), and then rerun ./config (with your
options) and at the end of the command add ' 2>&1 | tee conflog' and
then after it has configured, check the log to confirm it is x86_64.
All being well, then run 'make 2>&1 | tee buildlog'.

 Assuming that fails again, take a look at _where_ it is failing.
This error is not something I can remember seeing.  You might need
to post some of the log.

 When you sort this out, you should also think about security :
openssl-1.0.1i is rather old.  Current versions are 1.0.1l (for
people using the 1.0.1 series) and 1.0.2.  Looking at
https://openssl.org/news/ 1.0.1{j,k,l} included security fixes,
1.0.1l is only described as bug fixes.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to