Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

2018-05-20 Thread Paul Rogers 
> >>> I'm still on 48, and admit/agree that firefox upgrades are always 
> >>> something I face with some trepidation.  I like the KISS principle, which 
> >>> seems foreign in Mozillaland.  If it weren't for compatibility/usability 
> >>> issues I might go with something else.  What I want from the WWW and what 
> >>> devlopers want to push on me are two very different things!  ;-(
> >>
> >>
> >> I have switched to Pale moon, which I find simpler and just as safe as
> >> Firefox.
> >>
> >> Just my 2c's worth
> >> da kiwi
> > 
> > When I last looked at Pale moon (last year), I was under the
> > impression that it needed a much older version of gcc than we were
> > then using ?

I looked at it within the last couple months but decided not to persue it at 
this time.  Don't remember exactly why, but probably something to do with a 
bunch of extra dependencies.

-- 
Paul Rogers
paulgrog...@fastmail.fm
Rogers' Second Law: "Everything you do communicates."
(I do not personally endorse any additions after this line. TANSTAAFL :-)
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

2018-05-19 Thread chris 

On 20/05/18 10:06, Ken Moffat wrote:

On Sun, May 20, 2018 at 08:29:14AM +1200, chris wrote:




I'm still on 48, and admit/agree that firefox upgrades are always something I 
face with some trepidation.  I like the KISS principle, which seems foreign in 
Mozillaland.  If it weren't for compatibility/usability issues I might go with 
something else.  What I want from the WWW and what devlopers want to push on me 
are two very different things!  ;-(



I have switched to Pale moon, which I find simpler and just as safe as
Firefox.

Just my 2c's worth
da kiwi


When I last looked at Pale moon (last year), I was under the
impression that it needed a much older version of gcc than we were
then using ?

Its developers have started basilisk, but that doesn't seem to have
formal releases.

ĸen


Interesting.  Thank you
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

2018-05-19 Thread Ken Moffat 
On Sun, May 20, 2018 at 08:29:14AM +1200, chris wrote:
> 
> 
> > I'm still on 48, and admit/agree that firefox upgrades are always something 
> > I face with some trepidation.  I like the KISS principle, which seems 
> > foreign in Mozillaland.  If it weren't for compatibility/usability issues I 
> > might go with something else.  What I want from the WWW and what devlopers 
> > want to push on me are two very different things!  ;-(
> 
> 
> I have switched to Pale moon, which I find simpler and just as safe as
> Firefox.
> 
> Just my 2c's worth
> da kiwi

When I last looked at Pale moon (last year), I was under the
impression that it needed a much older version of gcc than we were
then using ?

Its developers have started basilisk, but that doesn't seem to have
formal releases.

ĸen
-- 
This email was written using 100% recycled letters.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

2018-05-19 Thread chris 




I'm still on 48, and admit/agree that firefox upgrades are always something I 
face with some trepidation.  I like the KISS principle, which seems foreign in 
Mozillaland.  If it weren't for compatibility/usability issues I might go with 
something else.  What I want from the WWW and what devlopers want to push on me 
are two very different things!  ;-(



I have switched to Pale moon, which I find simpler and just as safe as 
Firefox.


Just my 2c's worth
da kiwi
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

2018-05-19 Thread Paul Rogers 
> Since that was a reply to my reply, I'll bite:

Thanks for doing so.  I like having reports from travellers on the road ahead.  
;-)

> 
> I prefer to run current versions of graphical browsers, or their
> engines (e.g. qtwebewngine for falkon, webkitgtk if somebody uses a
> browser based on that) because of the many vulnerabilities which
> eventually become known.

Pointing out a fundamental difference.  Even when I've had to solder up my 
personal computer and rewrite the BIOS, still, I've always been a "computer 
user", interested in what it does for me, what I can do with it, not so much 
what it *is*.

> 
> My preferred browser for general use is firefox, building recent
> versions of that with less than 8GB is painful because of the
> amount of swapping - even if the drive is an SSD.

I'm still on 48, and admit/agree that firefox upgrades are always something I 
face with some trepidation.  I like the KISS principle, which seems foreign in 
Mozillaland.  If it weren't for compatibility/usability issues I might go with 
something else.  What I want from the WWW and what devlopers want to push on me 
are two very different things!  ;-(

> being able to support a system or 3 years, but changes in glibc
> (fixes of historic vulnerabilities) and then in firefox made that

If it weren't for need to protect myself from exploits, I don't think I'd need 
to update nearly this often.  Even so, I trail.

> not possible for me.  Gradually I have added to my machines, and I
> realised that for me there was no benefit to updating anything older
> than the previous release.

I tend not to update old versions, but I do occasionally use them as was, if 
not for high-exposure activities.  If it did a job for me once, it can do the 
job for me still.

> 
> The point is that for current software, with the continuing changes
> in C++ and other flavour of the month languages, the more horsepower
> and memory, the greater the chance that it might build.

Being retired on limited income, keeping up to date with hardware is not 
possible--to often it involves a total chaneover in "infrastructure".  I have a 
buddy working for Intel that in a former job was sometimes able to bring me 
some of their or a coworker's discarded "garbage".  Worked for me.

> But of course my machines are more of the 'my lab' flavour - a
> heterogenous collection, and I expect to build on each of them
> rather than build on one and then roll out the binaries.

I preserve the option of rebuilding, but fundamentally that's a waste of time 
and effort for me.  I try to make binary installations as much as possible.

> 
> Yet again, I have managed to write ambiguously.  What I meant was

Happens to us all.

> that I continue to update the current and previous releases for
> known vulnerabilities, just in case I have to use those old systems
> when I've managed to trash the current one and need to recover from
> backups.  So I have successfully updated both 8.2 and 8.1 systems.
> 
> ĸen

My approach is to keep a couple bootable versions on each box, but I suspect my 
versions are a bit more stable than yours.  I try to make milestones and 
respect them, forking more than updating.

-- 
Paul Rogers
paulgrog...@fastmail.fm
Rogers' Second Law: "Everything you do communicates."
(I do not personally endorse any additions after this line. TANSTAAFL :-)
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

2018-05-19 Thread DOMINIQUE VAYSSAIRAT 
Hello,

Did you try the exactly commands as inside the lfs book 8.2 :

cp -v configure{,.orig} &&  
sed 's:/usr/local/bin:/bin:' configure.orig > configure &&

./configure --prefix=/tools --with-tcl=/tools/lib  
--with-tclinclude=/tools/include &&

make

try  if you have multi-proc configured on you VM 




> Le 14 mai 2018 à 17:10, Admin  a écrit :
> 
> Hello,
> 
> I am following the lfs book 8.2, using Debian-9.4.0 (64bit - amd64) inside a 
> VMWare Workstation 14.
> All the steps leading upto 5.11 (Tcl-core-8.6.8) worked out fine.
> With 5.11 (tcl), I am stuck with a strange problem. I don't see anyone 
> mentioning this.
> 
> Essentially, when I run make from inside unix folder, I am stuck at the 
> compilation of '/mnt/lfs/sources/tcl8.6.8/generic/tclStubLib.c'
> The make is just sitting idle and no further activity - no errors, nothing. I 
> am just stuck!
> 
> Without completing this step, I can't even go to next step Expect-5.45.4.
> Please help!
> 
> 
> (I have also tried to enable 64bit support with a modified configure command, 
> but no difference...)
> ./configure --prefix=/tools $([ $(uname -m) = x86_64 ] && echo --enable-64bit)
> 
> 
> 
> Here is what I tried:-
> tar -xvf tcl8.6.8-src.tar.gz
> cd tcl8.6.8
> 
> cd unix
> ./configure --prefix=/tools
> 
> make
> 
> 
> 
> 
> The output from the configure is here -- 
> 
> lfs@debian-9-vm:/mnt/lfs/sources/tcl8.6.8/unix$ ./configure --prefix=/tools   
>   
> checking whether to use symlinks for manpages... no
> checking whether to compress the manpages... no
> checking whether to add a package name suffix for the manpages... no
> checking for gcc... gcc
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables... 
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ANSI C... none needed
> checking for inline... inline
> checking how to run the C preprocessor... gcc -E
> checking for egrep... grep -E
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking dirent.h... yes
> checking float.h usability... yes
> checking float.h presence... yes
> checking for float.h... yes
> checking values.h usability... yes
> checking values.h presence... yes
> checking for values.h... yes
> checking for stdlib.h... (cached) yes
> checking for string.h... (cached) yes
> checking sys/wait.h usability... yes
> checking sys/wait.h presence... yes
> checking for sys/wait.h... yes
> checking dlfcn.h usability... yes
> checking dlfcn.h presence... yes
> checking for dlfcn.h... yes
> checking sys/param.h usability... yes
> checking sys/param.h presence... yes
> checking for sys/param.h... yes
> checking if the compiler understands -pipe... yes
> checking for pthread_mutex_init in -lpthread... yes
> checking for pthread_attr_setstacksize... yes
> checking for pthread_atfork... yes
> checking for building with threads... yes
> checking for sin... no
> checking for main in -lieee... no
> checking for main in -linet... no
> checking net/errno.h usability... no
> checking net/errno.h presence... no
> checking for net/errno.h... no
> checking for connect... yes
> checking for gethostbyname... yes
> checking how to build libraries... shared
> checking for tclsh... /usr/bin/tclsh8.6
> checking zlib.h usability... no
> checking zlib.h presence... no
> checking for zlib.h... no
> checking for ranlib... ranlib
> checking if 64bit support is requested... no
> checking if 64bit Sparc VIS support is requested... no
> checking if compiler supports visibility "hidden"... yes
> checking if rpath support is requested... yes
> checking system version... Linux-4.9.0-6-amd64
> checking for dlopen in -ldl... yes
> checking for ar... ar
> checking for cast to union support... yes
> checking for build with symbols... no
> checking for required early compiler flags...  _LARGEFILE64_SOURCE
> checking for 64-bit integer type... using long
> checking whether byte ordering is bigendian... no
> checking for getcwd... yes
> checking for mkstemp... yes
> checking for opendir... yes
> checking for strtol... yes
> checking for waitpid... yes
> checking for strerror... yes
> checking for getwd... yes
> checking for wait3... yes
> checking for uname... yes
> checking for realpath... yes
> checking for getnameinfo... yes
> checking for getaddrinfo... yes
> checking for freeaddrinfo... yes
> checking for

Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

2018-05-18 Thread Ken Moffat 
On Fri, May 18, 2018 at 11:45:21PM +0100, Ken Moffat wrote:
> 
> Gradually I have added to my machines, and I
> realised that for me there was no benefit to updating anything older
> than the previous release.
> 
Yet again, I have managed to write ambiguously.  What I meant was
that I continue to update the current and previous releases for
known vulnerabilities, just in case I have to use those old systems
when I've managed to trash the current one and need to recover from
backups.  So I have successfully updated both 8.2 and 8.1 systems.

ĸen
-- 
This email was written using 100% recycled letters.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

2018-05-18 Thread Ken Moffat 
On Fri, May 18, 2018 at 02:51:00PM -0700, Paul Rogers wrote:
> 
> > ...  But if you want to go on to build a desktop with a modern
> > graphical browser then 8GB RAM (and even with that, maybe swap if you
> > are doing other things during the compilation) is more comfortable.
> > 
> > For a server, it probably varies between different packages.  Some
> > are fairly light to build.
> > 
> > So no, for LFS-only, 6GB should be adequate.  And I suspect many
> > ...
> 
> Just as a data point, I'm running 7.10, XCFE, Firefox, LibreOffice on an old 
> Conroe Core2-Duo 6700 (non E-), 4GB.  This is my "daily driver".  It's "fast 
> enough", and that's all I need.  I don't need a computer so fast it will 
> finish things before I've got it all thought out, if you know what I mean.  
> Sometimes it can be a good thing when one can't just "brute force it" and has 
> to do it with some finesse.
> 
> I'll do building on an old 12GB i7-940, so's I can use -j8.
> 
Since that was a reply to my reply, I'll bite:

I prefer to run current versions of graphical browsers, or their
engines (e.g. qtwebewngine for falkon, webkitgtk if somebody uses a
browser based on that) because of the many vulnerabilities which
eventually become known.

My preferred browser for general use is firefox, building recent
versions of that with less than 8GB is painful because of the
amount of swapping - even if the drive is an SSD.

And I used to try to update firefox on previous "released" systems,
sort of in a "it can be done" fashion - I used to like the idea of
being able to support a system or 3 years, but changes in glibc
(fixes of historic vulnerabilities) and then in firefox made that
not possible for me.  Gradually I have added to my machines, and I
realised that for me there was no benefit to updating anything older
than the previous release.

But after firefox-60 came out I decided it would be nice to be able
to update the last-but-two release (8.0) in the spirit of "expecting
users to update the whole system more than once a year is a pain for
them".  So I tried that on my i7 haswell (16GB, SATA SSD), which
builds relatively quickly.  Updated sqlite, nspr, nss. icu,
graphite2, harfbuzz, rustc.  But then firefox failed to build one of
its rust crates.  Adding --verbose to the mach invocation did not
give any more information about why it had failed, and anyway
failures in packaged rust crates are often terminal - if you try to
patch or sed something to fix an error, a hash check will later
decide you didn't build the expected version.

The point is that for current software, with the continuing changes
in C++ and other flavour of the month languages, the more horsepower
and memory, the greater the chance that it might build.

But of course my machines are more of the 'my lab' flavour - a
heterogenous collection, and I expect to build on each of them
rather than build on one and then roll out the binaries.

ĸen
-- 
This email was written using 100% recycled letters.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

2018-05-18 Thread Paul Rogers 
> A little more to report on...I don't know how to understand this - 

Indeed, and that deserves some thought.

> 
> As I mentioned, I repeated the whole exercise - right from setting up a 
> new VM with identical settings. Followed all the steps exactly, once 
> again. And everything is working fine for tcl-8.6.8. It is compiling 
> even with -O2.
> 
> Now I have 2 VMs with identical settings where one fails to compile 
> tcl-8.6.8 with -O2 and the other where it is fine. I don't know how to 
> interpret this. I am accepting that I might have made a mistake in the 
> first instance, but the failure was very subtle, undetectable and I 
> don't know how to understand the peculiar behavior (compiling only with 
> -O2 optimization fails, but -O1 succeeds).

Personally, I *wouldn't* recommend building in a VM.  One just adds one more 
level of uncertainty, the virtual environment.  I prefer "bare iron".  When, as 
it inevitably does, it comes to trouble shooting, one must have someplace solid 
to stand on.

> ...  But if you want to go on to build a desktop with a modern
> graphical browser then 8GB RAM (and even with that, maybe swap if you
> are doing other things during the compilation) is more comfortable.
> 
> For a server, it probably varies between different packages.  Some
> are fairly light to build.
> 
> So no, for LFS-only, 6GB should be adequate.  And I suspect many
> ...

Just as a data point, I'm running 7.10, XCFE, Firefox, LibreOffice on an old 
Conroe Core2-Duo 6700 (non E-), 4GB.  This is my "daily driver".  It's "fast 
enough", and that's all I need.  I don't need a computer so fast it will finish 
things before I've got it all thought out, if you know what I mean.  Sometimes 
it can be a good thing when one can't just "brute force it" and has to do it 
with some finesse.

I'll do building on an old 12GB i7-940, so's I can use -j8.



-- 
Paul Rogers
paulgrog...@fastmail.fm
Rogers' Second Law: "Everything you do communicates."
(I do not personally endorse any additions after this line. TANSTAAFL :-)
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

2018-05-17 Thread Michael Shell 
On Wed, 16 May 2018 21:26:41 -0500
Bruce Dubbs  wrote:

> If it's a true OOM condition, then there should be something in a log. 
> If RAM is short, swap should handle it, although it slows things down.

I agree ... if things otherwise work as they are supposed to.


On Thu, 17 May 2018 17:42:17 -0400
Admin  wrote:

> How real this concern is for lfs? I mean, one of the claims about
> Linux/GNU OS is that it requires very much less resources such that
> even old computers can be made useful again rather than being obsoleted.

I agree with this too. I was thinking that perhaps Tcl-core was triggering
a memory hog type bug/issue with the most recent gcc and that people with
more RAM were not seeing any problem.


On Thu, 17 May 2018 18:03:57 -0400
Admin  wrote:

> Now I have 2 VMs with identical settings where one fails to compile
> tcl-8.6.8 with -O2 and the other where it is fine. I don't know how to
> interpret this. I am accepting that I might have made a mistake in the
> first instance, but the failure was very subtle, undetectable and I don't
> know how to understand the peculiar behavior (compiling only with
> -O2 optimization fails, but -O1 succeeds).

Thanks for letting us know. One possibility was a memory error - the
system made an undetected one byte mistake (in building gcc?) during the
first build.

You could try making a copy of the "bad" system (so you have an unaltered
copy of it to inspect/restore late) then copying over components of the new
system to see which one fixes it. Gcc would be high on the list. e.g., does
copying the gcc executable from the good system to the old one fix the issue
on the "bad" system?


   Cheers,

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

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

2018-05-17 Thread Paul Rogers 
> > You're asking the compiler to "pull out all the stops" to algorithmically 
> > optimize code the programmer clearly did not intend for such optimization.  
> > The programmer is [supposed to be] intelligent, the compiler is not.  And, 
> > as I'm sure we've all seen, some programmers abuse the language trying to 
> > do their own "optimizations".  That's why new version of the compiler 
> > sometimes will not work with some coding practices.  For example, "Please 
> > note the warning under -fgcse about invoking -O2 on programs that use 
> > computed gotos."
> > 
> 
> Paul,
> 
> whilst I agree that increasing optimization does sometimes lead to
> problems, I think you are perhaps missing something important: the
> flags used by the package developer.

You're right.  I was trying to address the more general proposition of adding 
optimizations when building.  IMO, it's generally not a good idea.

-- 
Paul Rogers
paulgrog...@fastmail.fm
Rogers' Second Law: "Everything you do communicates."
(I do not personally endorse any additions after this line. TANSTAAFL :-)
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

2018-05-17 Thread Ken Moffat 
On Thu, May 17, 2018 at 05:42:17PM -0400, Admin wrote:
> > I would not be so certain about this. Today, 6GB RAM is not as much as you 
> > might think. For example, the short C++ code shown here: 
> > https://kristerw.blogspot.com/2017/10/excessive-gcc-memory-usage-for-large.html
> >  
> > requires 8GB of RAM for gcc to compile. 
> 
> How real this concern is for lfs? I mean, one of the claims about Linux/GNU 
> OS is that it requires very much less resources such that even old computers 
> can be made useful again rather than being obsoleted. Also, isn't Debian 
> ported to RaspberryPi, where the system can be compiled on the target itself 
> using GCC toolchain with a lot less resources? 
> 
> Regards
> 

Depends what you want to do - if, for you, LFS is just a learning
experience or a box-ticking exercise (i.e. you don't intend to make
much use of the resulting system) then you can get by with much less
memory.  But if you want to go on to build a desktop with a modern
graphical browser then 8GB RAM (and even with that, maybe swap if you
are doing other things during the compilation) is more comfortable.

For a server, it probably varies between different packages.  Some
are fairly light to build.

So no, for LFS-only, 6GB should be adequate.  And I suspect many
people here started on LFS using old, or re-purposed hardware.  But
LFS expects you to compile things yourself - and with each compiler
release the process takes longer and probably uses more RAM, so
faster hardware becomes useful.

For debian, I have no idea if most of the available binary packages
were built natively or cross-compiled - but I suspect they were
cross-compiled.  Yes, you *can* build them natively, but for most
people using a pi I doubt that doing that for many packages will be
worth the time.

ĸen
-- 
This email was written using 100% recycled letters.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

2018-05-17 Thread Admin 
A little more to report on...I don't know how to understand this - 

As I mentioned, I repeated the whole exercise - right from setting up a new VM 
with identical settings. Followed all the steps exactly, once again. And 
everything is working fine for tcl-8.6.8. It is compiling even with -O2.

Now I have 2 VMs with identical settings where one fails to compile tcl-8.6.8 
with -O2 and the other where it is fine. I don't know how to interpret this. I 
am accepting that I might have made a mistake in the first instance, but the 
failure was very subtle, undetectable and I don't know how to understand the 
peculiar behavior (compiling only with -O2 optimization fails, but -O1 
succeeds).

For now, I am going to proceed with my new VM and go rest of way through 
lfs-8.2, and see if it works.

Thanks everyone for your help.

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

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

2018-05-17 Thread Admin 
> I would not be so certain about this. Today, 6GB RAM is not as much as you 
> might think. For example, the short C++ code shown here: 
> https://kristerw.blogspot.com/2017/10/excessive-gcc-memory-usage-for-large.html
>  
> requires 8GB of RAM for gcc to compile. 

How real this concern is for lfs? I mean, one of the claims about Linux/GNU OS 
is that it requires very much less resources such that even old computers can 
be made useful again rather than being obsoleted. Also, isn't Debian ported to 
RaspberryPi, where the system can be compiled on the target itself using GCC 
toolchain with a lot less resources? 

Regards

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

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

2018-05-16 Thread Bruce Dubbs 

On 05/16/2018 09:18 PM, Michael Shell wrote:

On Tue, 15 May 2018 16:38:37 -0400
Admin  wrote:


BTW, the VM has enough resources - 6G RAM & 128 GB HDD (LFS partition).



I would not be so certain about this. Today, 6GB RAM is not as much as you
might think. For example, the short C++ code shown here:

https://kristerw.blogspot.com/2017/10/excessive-gcc-memory-usage-for-large.html

requires 8GB of RAM for gcc to compile.

Also, gcc requires more memory with increasing levels of optimization. So,
this would explain why -O1 works. Can you increase the VM memory allocation
to say, 12GB and see if that has any effect?


If it's a true OOM condition, then there should be something in a log. 
If RAM is short, swap should handle it, although it slows things down.


I'd be more concerned with the illegal instruction.  Since this seems to 
be the only issue like this we've seen recently, I'd think vmware is the 
prime culprit.


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

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

2018-05-16 Thread Michael Shell 
On Tue, 15 May 2018 16:38:37 -0400
Admin  wrote:

> BTW, the VM has enough resources - 6G RAM & 128 GB HDD (LFS partition).


I would not be so certain about this. Today, 6GB RAM is not as much as you
might think. For example, the short C++ code shown here:

https://kristerw.blogspot.com/2017/10/excessive-gcc-memory-usage-for-large.html

requires 8GB of RAM for gcc to compile.

Also, gcc requires more memory with increasing levels of optimization. So,
this would explain why -O1 works. Can you increase the VM memory allocation
to say, 12GB and see if that has any effect?


  Cheers,

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

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

2018-05-16 Thread Ken Moffat 
On Wed, May 16, 2018 at 03:26:53PM -0700, Paul Rogers wrote:
> > I understand the reluctance to override the CFLAGS. But, as I have 
> > discovered the -O2 flag is causing the trouble. Could anyone point out 
> > to me how do I go about discovering the root cause? 
> 
> You're asking the compiler to "pull out all the stops" to algorithmically 
> optimize code the programmer clearly did not intend for such optimization.  
> The programmer is [supposed to be] intelligent, the compiler is not.  And, as 
> I'm sure we've all seen, some programmers abuse the language trying to do 
> their own "optimizations".  That's why new version of the compiler sometimes 
> will not work with some coding practices.  For example, "Please note the 
> warning under -fgcse about invoking -O2 on programs that use computed gotos."
> 

Paul,

whilst I agree that increasing optimization does sometimes lead to
problems, I think you are perhaps missing something important: the
flags used by the package developer.

In the case of tcl, the default CFLAGS it uses start with -O2.  From
the OP's report, this package does respect any CFLAGS passed to it,
so what (s)he was doing is *reducing* the optimization.

ĸen
-- 
This email was written using 100% recycled letters.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

2018-05-16 Thread Paul Rogers 
> I understand the reluctance to override the CFLAGS. But, as I have 
> discovered the -O2 flag is causing the trouble. Could anyone point out 
> to me how do I go about discovering the root cause? 

You're asking the compiler to "pull out all the stops" to algorithmically 
optimize code the programmer clearly did not intend for such optimization.  The 
programmer is [supposed to be] intelligent, the compiler is not.  And, as I'm 
sure we've all seen, some programmers abuse the language trying to do their own 
"optimizations".  That's why new version of the compiler sometimes will not 
work with some coding practices.  For example, "Please note the warning under 
-fgcse about invoking -O2 on programs that use computed gotos."

Optimizations, especially the higher levels, when they work, produce code that 
does not have a clear correspondance to the source code and is not debuggable.  
And sometimes they may produce code that fails at "edge conditions".  

In my opinion, they should be considered "the cherry on top".  When the code is 
complex and not your own, the uncertainty of what got optimized how and where 
is not worth the generally minor speed benefits.  I never add optimization 
options when building LFS unless the instructions say to.  If the programmer 
knows it's OK and adds it to the makefile parameters, fine.  I don't presume to 
know better, that it would work when (s)he didn't use it.

-- 
Paul Rogers
paulgrog...@fastmail.fm
Rogers' Second Law: "Everything you do communicates."
(I do not personally endorse any additions after this line. TANSTAAFL :-)
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

2018-05-16 Thread Admin 
> I wonder if gcc has become confused about the CPU which vmware is
> presenting to it, and is trying to use instructions which are not
> actually supported.
> 

If this were the case, wouldn't the crash be reported by the system - core-dump 
or something for using an illegal instruction?

But your point may be valid.
The Host machine is i7-7820X CPU @ 3.60GHz (8 cores) with 32GB RAM running 
Windows 8.1
The VM is configured with 2 cores per processor and 2 processors == total 4 
processor cores with 4GB RAM running Debian 9.4.0 64-bit.

Here is the output of lscpu from within the VM:- 

Architecture:  x86_64
CPU op-mode(s):32-bit, 64-bit
Byte Order:Little Endian
CPU(s):4
On-line CPU(s) list:   0-3
Thread(s) per core:1
Core(s) per socket:2
Socket(s): 2
NUMA node(s):  1
Vendor ID: GenuineIntel
CPU family:6
Model: 85
Model name:Intel(R) Core(TM) i7-7820X CPU @ 3.60GHz
Stepping:  4
CPU MHz:   3600.058
BogoMIPS:  7199.99
Hypervisor vendor: VMware
Virtualization type:   full
L1d cache: 32K
L1i cache: 32K
L2 cache:  1024K
L3 cache:  11264K
NUMA node0 CPU(s): 0-3
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm 
constant_tsc arch_perfmon nopl xtopology tsc_reliable nonstop_tsc eagerfpu pni 
pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 
3dnowprefetch invpcid_single kaiser fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 
invpcid rtm mpx avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd 
avx512bw avx512vl xsaveopt xsavec xsaves arat


Everything seems to be in order and as expected. 

Also, curiously enough, GCC in the VM (Debian-9) seems to have no problems with 
-O2. I am able to complete all the steps in pass-1. Its only in the pass-2 when 
I am using the rebuilt version of gcc from $LFS/tools as the book says, is 
where the trouble seems to start.

To understand the issue, I am going to repeat the whole exercise - right from 
setting up the VM up to the tcl-8.6.8 and see, if the problem is repeatable.

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

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

2018-05-16 Thread Ken Moffat 
On Wed, May 16, 2018 at 10:58:17AM -0400, Admin wrote:
> Sorry for the 'top-post' - didn't realize I was doing that. Hopefully this 
> should be OK now.
> 
> I understand the reluctance to override the CFLAGS. But, as I have discovered 
> the -O2 flag is causing the trouble. Could anyone point out to me how do I go 
> about discovering the root cause? 
> 

I wonder if gcc has become confused about the CPU which vmware is
presenting to it, and is trying to use instructions which are not
actually supported.

But I've no idea how vmware can be configured.

Perhaps using lscpu (or the output of '/proc/cpuinfo' for 1 core)
will show that the host and the vm report differently, particularly
in the flags.  But -O2 should normally offer non-fancy generic
optimizations.

ĸen
-- 
This email was written using 100% recycled letters.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

2018-05-16 Thread Admin 
Sorry for the 'top-post' - didn't realize I was doing that. Hopefully this 
should be OK now.

I understand the reluctance to override the CFLAGS. But, as I have discovered 
the -O2 flag is causing the trouble. Could anyone point out to me how do I go 
about discovering the root cause? 

Given that, all the steps prior to 5.11 (tcl) were smooth sailing (the 
instructions are great and crystal clear), and all the 'tests' with the 
tool-chain build were OK. Running gcc on my build machine (a VM running 
Debian-9.4.0 amd64), with -O2 flag is not a problem, as the earlier steps 
indicate. So, it makes me believe that, tool-chain built in the earlier section 
in pass-1 could be problematic, despite the fact that all the steps went 
through exactly as described. The end result of those steps (actual built 
binaries) in some way, are faulty (especially the optimizer).

How do I go about discovering and correcting that?

Also, I don't think using a VM is a problem in this case, since all the 
resources are adequate (RAM, Disk space etc), the host (Windows 8.1) running 
the guest (Debian 9), which is my build machine, seem to be chugging along fine 
without any apparent hiccups.

Regards.

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

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

2018-05-15 Thread Bruce Dubbs 

On 05/15/2018 09:46 PM, Admin wrote:

OK. Some more progress

I replaced the make calls with
make CFLAGS='-O1 -g -fPIC'

and everything seems to work fine, even the tests also ran OK - no errors (some 
tests were skipped by the script, but failed=0)


With this, I am wondering is anything wrong in overriding the CFLAGS in this 
way and what is the problem with -O2 flag starting from chapter 5.11 (I didn't 
face this problem in earlier steps)? Has anyone faced this issue so far?
Does this also mean that from now on 5.11+, I need to always override the 
CFLAGS in order for the rest of the lfs system to complete?


Please don't top post on this mailing list.

I do not know why you had a problem with tcl.  We don't do a lot with 
vmware.  On normal hardware, there is no problem with tcl.  I recommend 
not changing CFLAGS unless you run into an error.


  -- Bruce

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

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

2018-05-15 Thread Admin 
Thanks Ken.

Actually, I made some progress on the causes of the hang and observed that GCC 
optimization flag -O2 is causing the problem.

When I manually remove -O2 and replace it with -O1 (line 6559 & line 7380 in 
configure script in unix folder) then the compilation seems to proceed properly.

However, I know this is a bad solution, since the make gets stuck down the line 
for package itcl4.1.1 for the same reason. The optimize flag is -O2 in that 
configure script.

I wonder, why the -O2 should have problem in my configuration. 

BTW, the VM has enough resources - 6G RAM & 128 GB HDD (LFS partition).


Thx



​​

‐‐‐ Original Message ‐‐‐

On May 15, 2018 3:58 PM, Ken Moffat  wrote:

> ​​
> 
> On Mon, May 14, 2018 at 11:10:36AM -0400, Admin wrote:
> 
> > Hello,
> > 
> > I am following the lfs book 8.2, using Debian-9.4.0 (64bit - amd64) inside
> > 
> > a VMWare Workstation 14.
> > 
> > All the steps leading upto 5.11 (Tcl-core-8.6.8) worked out fine.
> > 
> > With 5.11 (tcl), I am stuck with a strange problem. I don't see anyone
> > 
> > mentioning this.
> > 
> > Essentially, when I run make from inside unix folder, I am stuck at the
> > 
> > compilation of '/mnt/lfs/sources/tcl8.6.8/generic/tclStubLib.c'
> > 
> > The make is just sitting idle and no further activity - no errors,
> > 
> > nothing. I am just stuck!
> 
> When a program just sits there doing nothing, finding out why can be
> 
> hard. Two suggestions:
> 
> 1.  Do you have plenty of memory available to the VM, and enough
> 
> space on the disk image (in the VM, 'top' and 'df' but also on the
> 
> host 'top'.
> 
> 2.  Install strace to the debian host in the VM, remove the current
> 
> tcl directory and retry, with the change I suggest below.
> 
> 3.  And, I suppose you could also check the system logs of both the
> 
> VM and the host system in case there were segmentation faults or
> 
> similar.
> 
> 
> > Without completing this step, I can't even go to next step Expect-5.45.4.
> > 
> > Please help!
> > 
> > (I have also tried to enable 64bit support with a modified configure
> > 
> > command, but no difference...)
> > 
> > ./configure --prefix=/tools $([ $(uname -m) = x86_64 ] && echo
> > 
> > --enable-64bit)
> > 
> > Here is what I tried:-
> > 
> > tar -xvf tcl8.6.8-src.tar.gz
> > 
> > cd tcl8.6.8
> > 
> > cd unix
> > 
> > ./configure --prefix=/tools
> > 
> > make
> 
> Instead of 'make', 'strace -o mytrace make'.
> 
> Then, when it is running and apparently stalled, look at 'top' in
> 
> both the VM and the host to see if anything is happening, and if not
> 
> kill strace with Ctrl-C. Then look at the mytrace file - it will
> 
> probably be long and tedious, and perhaps repetitive (e.g. poll
> 
> commands while something waits for input).
> 
> Because the hang appears to be in gcc, you might need to retry,
> 
> adding -ff to the strace options (in front of -o) to get the
> 
> details. If so, you will get more than one trace file, each with a
> 
> PID number - in that case you want the one which invokes gcc (details
> 
> of the program should be at the start of each strace file).
> 
> FWIW, your configure output seems to be ok.
> 
> ĸen
> 
> 
> -
> 
> This email was written using 100% recycled letters.
> ---
> 
> http://lists.linuxfromscratch.org/listinfo/lfs-support
> 
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> 
> Unsubscribe: See the above information page
> 
> Do not top post on this list.
> 
> A: Because it messes up the order in which people normally read text.
> 
> Q: Why is top-posting such a bad thing?
> 
> A: Top-posting.
> 
> Q: What is the most annoying thing in e-mail?
> 
> http://en.wikipedia.org/wiki/Posting_style


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

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

2018-05-15 Thread Ken Moffat 
On Mon, May 14, 2018 at 11:10:36AM -0400, Admin wrote:
>Hello,
>I am following the lfs book 8.2, using Debian-9.4.0 (64bit - amd64) inside
>a VMWare Workstation 14.
>All the steps leading upto 5.11 (Tcl-core-8.6.8) worked out fine.
>With 5.11 (tcl), I am stuck with a strange problem. I don't see anyone
>mentioning this.
>Essentially, when I run make from inside unix folder, I am stuck at the
>compilation of '/mnt/lfs/sources/tcl8.6.8/generic/tclStubLib.c'
>The make is just sitting idle and no further activity - no errors,
>nothing. I am just stuck!

When a program just sits there doing nothing, finding out why can be
hard.  Two suggestions:

1. Do you have plenty of memory available to the VM, and enough
space on the disk image (in the VM, 'top' and 'df' but also on the
host 'top'.

2. Install strace to the debian host in the VM, remove the current
tcl directory and retry, with the change I suggest below.

3. And, I suppose you could also check the system logs of both the
VM and the host system in case there were segmentation faults or
similar.

>Without completing this step, I can't even go to next step Expect-5.45.4.
>Please help!
>(I have also tried to enable 64bit support with a modified configure
>command, but no difference...)
>./configure --prefix=/tools $([ $(uname -m) = x86_64 ] && echo
>--enable-64bit)
>Here is what I tried:-
>tar -xvf tcl8.6.8-src.tar.gz
>cd tcl8.6.8
>cd unix
>./configure --prefix=/tools
>make

Instead of 'make', 'strace -o mytrace make'.

Then, when it is running and apparently stalled, look at 'top' in
both the VM and the host to see if anything is happening, and if not
kill strace with Ctrl-C.  Then look at the mytrace file - it will
probably be long and tedious, and perhaps repetitive (e.g. poll
commands while something waits for input).

Because the hang appears to be in gcc, you might need to retry,
adding -ff to the strace options (in front of -o) to get the
details.  If so, you will get more than one trace file, each with a
PID number - in that case you want the one which invokes gcc (details
of the program should be at the start of each strace file).

FWIW, your configure output seems to be ok.

ĸen
-- 
This email was written using 100% recycled letters.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

[lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

2018-05-14 Thread Admin 
Hello,

I am following the lfs book 8.2, using Debian-9.4.0 (64bit - amd64) inside a 
VMWare Workstation 14.
All the steps leading upto 5.11 (Tcl-core-8.6.8) worked out fine.
With 5.11 (tcl), I am stuck with a strange problem. I don't see anyone 
mentioning this.

Essentially, when I run make from inside unix folder, I am stuck at the 
compilation of '/mnt/lfs/sources/tcl8.6.8/generic/tclStubLib.c'
The make is just sitting idle and no further activity - no errors, nothing. I 
am just stuck!

Without completing this step, I can't even go to next step Expect-5.45.4.
Please help!

(I have also tried to enable 64bit support with a modified configure command, 
but no difference...)
./configure --prefix=/tools $([ $(uname -m) = x86_64 ] && echo --enable-64bit)

Here is what I tried:-
tar -xvf tcl8.6.8-src.tar.gz
cd tcl8.6.8

cd unix
./configure --prefix=/tools

make

The output from the configure is here --

lfs@debian-9-vm:/mnt/lfs/sources/tcl8.6.8/unix$ ./configure --prefix=/tools
checking whether to use symlinks for manpages... no
checking whether to compress the manpages... no
checking whether to add a package name suffix for the manpages... no
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for inline... inline
checking how to run the C preprocessor... gcc -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dirent.h... yes
checking float.h usability... yes
checking float.h presence... yes
checking for float.h... yes
checking values.h usability... yes
checking values.h presence... yes
checking for values.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking sys/wait.h usability... yes
checking sys/wait.h presence... yes
checking for sys/wait.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking if the compiler understands -pipe... yes
checking for pthread_mutex_init in -lpthread... yes
checking for pthread_attr_setstacksize... yes
checking for pthread_atfork... yes
checking for building with threads... yes
checking for sin... no
checking for main in -lieee... no
checking for main in -linet... no
checking net/errno.h usability... no
checking net/errno.h presence... no
checking for net/errno.h... no
checking for connect... yes
checking for gethostbyname... yes
checking how to build libraries... shared
checking for tclsh... /usr/bin/tclsh8.6
checking zlib.h usability... no
checking zlib.h presence... no
checking for zlib.h... no
checking for ranlib... ranlib
checking if 64bit support is requested... no
checking if 64bit Sparc VIS support is requested... no
checking if compiler supports visibility "hidden"... yes
checking if rpath support is requested... yes
checking system version... Linux-4.9.0-6-amd64
checking for dlopen in -ldl... yes
checking for ar... ar
checking for cast to union support... yes
checking for build with symbols... no
checking for required early compiler flags...  _LARGEFILE64_SOURCE
checking for 64-bit integer type... using long
checking whether byte ordering is bigendian... no
checking for getcwd... yes
checking for mkstemp... yes
checking for opendir... yes
checking for strtol... yes
checking for waitpid... yes
checking for strerror... yes
checking for getwd... yes
checking for wait3... yes
checking for uname... yes
checking for realpath... yes
checking for getnameinfo... yes
checking for getaddrinfo... yes
checking for freeaddrinfo... yes
checking for gai_strerror... yes
checking for struct addrinfo... yes
checking for struct in6_addr... yes
checking for struct sockaddr_in6... yes
checking for struct sockaddr_storage... yes
checking for getpwuid_r... yes
checking for getpwuid_r with 5 args... yes
checking for getpwnam_r... yes
checking for getpwnam_r with 5 args... yes
checking for getgrgid_r... yes
checking for getgrgid_r with 5 args... yes
checking for getgrnam_r... yes
checking for getgrnam_r with 5 args... yes
checking for gethostbyname_r... yes
checking for gethostbyname_r with 6 args... yes
checking for gethostbyaddr_r... yes
checking for gethostbyaddr_r with 7 args... no
checking for gethostbyaddr_r with 8 args... yes
checking termios.h usability... yes
checking termios.h presence... yes
checking for termios.h... yes
checking