[lfs-support] 5.33

Pat Barnes pat.barnes at charter.net
Tue Nov 3 12:54:36 PST 2015


On Tue, 2015-11-03 at 15:22 -0500, Michael Havens wrote:
> 
> On Tue, Nov 3, 2015 at 2:53 PM, Michael Havens <bmike1 at gmail.com>
> wrote:
>         I think maybe a recompile from the section after glibc is in
>         order. I say the chapter after because it appears as if gibc
>         compiled correctly.  Not hearing any responses by tomorrow I
>         will assume the is agreement with my plan.
>         
>         On Tue, Nov 3, 2015 at 12:24 AM, Michael Havens
>         <bmike1 at gmail.com> wrote:
>                 I didn't deviate from the book though. I followed
>                 their instructions to the tee.
>                 
>                 On Mon, Nov 2, 2015 at 10:07 PM, William Harrington
>                 <kb0iic at berzerkula.org> wrote:
>                         On Sun, 01 Nov 2015 17:19:32 -0600
>                         Bruce Dubbs <bruce.dubbs at gmail.com> wrote:
>                         
>                         > > the complete makelog is found:
>                         > >
>                         > > http://pastebin.com/GFtFP9Ng
>                         >
>                         > Well the lines like
>                         >
>                         > /tools/lib/libpthread.so.0: undefined
>                         reference to `__getrlimit at GLIBC_PRIVATE'
>                         
>                         All of the GLIBC_PRIVATE lines seem to me like
>                         you are attempting to use LTO. Are you using
>                         LTO?
>                         
>                         You are only one person out of many who can't
>                         build a complete system without many errors
>                         which you can easily search the last ten years
>                         of archives from many mailing lists. the LFS
>                         devs build every day but use book commands and
>                         don't deviate from the book. When you need
>                         help you explain your deviances from the
>                         book.I think I found the problem! '&&' is
>                         waiting for input. I was taught that what it
>                         does is if the last command exits in anything
>                         other than zero it halts the program. Please,
>                         what does && do?
>                 
>  
>                 I think I found the problem! '&&' is waiting for
>                 input. I was taught that what && does is if the last
>                 command exits in anything other than zero it halts the
>                 program. Please, what does && do?
>                 
>                 I figured this out by not waiting for approval to redo
>                 glibc and when I separately executed a command with
>                 '&&' it went to the next line and presented a '>'.
>                 -- 
>                 :-)~MIKE~(-:

You are correct that && means execute what follows the && only if the
first command is successful. However, if you END a line with &&, then
the shell assumes that there is another command that is forthcoming and
so gives you a prompt, its an implicit line continuation as in:

foo> make &&
> echo "done"

The "done" will only be printed if the make succeeds. The ending of the
line with && required that another command follow, so the shell prompts
you for that something.

Pat
>                 
>         
>         
>         
>         
>         -- 
>         :-)~MIKE~(-:
>         
> 
> 
> 
> 
> -- 
> :-)~MIKE~(-:
> 




More information about the lfs-support mailing list