On August 9, 2017 6:51:44 AM CDT, Wayne Blaszczyk <wblas...@bigpond.net.au> 
wrote:
>On Wed, 2017-08-09 at 08:15 +0200, Thierry Nuttens wrote:
>> 2017-08-09 7:00 GMT+02:00 Bruce Dubbs <bruce.du...@gmail.com>:
>> > Ken Moffat wrote:
>> > 
>> > > ĸen, beginning to think building from scratch is coming to an
>end,
>> > > except when we can match random git/svn versions of everything.
>> > 
>> > 
>> > Don't get discouraged yet.  I have seen reports of success with
>some
>> > relatively minor fixes (version numbers) that should be
>incorporated in the
>> > release version of gcc.
>> > 
>> > It does seem unusual though that the changes in binutils-2.29
>prevent
>> > glibc-2.25 from being built with gcc-7.1.
>> > 
>> >   -- Bruce
>> > 
>> > --
>> > http://lists.linuxfromscratch.org/listinfo/lfs-dev
>> > FAQ: http://www.linuxfromscratch.org/faq/
>> > Unsubscribe: See the above information page
>> 
>> I totally agreed with Bruce. Its really not that bad, you can find
>all
>> the result of my working in progress with the coming tool chain
>(glibc
>> 2.26 +binutils 2.29 + GCC7.2-RC ) The major point is that
>> GCC7.2-RC-wathever have to be renamed to 7.1.1 and retar so
>> 
>
>I don't think you need to rename and retar anything.
>I found that you just need to set
>--with-gxx-include-dir=/tools/$LFS_TGT/include/c++/7.1.1 when building
>Libstdc++.
>
>Wayne.
>
>
>> My work in progress and the concerned logs for each part
>> 
>> Chapter 5:
>> 
>> https://github.com/NuTyX/core/tree/master/chroot
>> http://download.nutyx.org/logs/x86_64/development/chroot/
>> 
>> Chapter6:
>> https://github.com/NuTyX/core/tree/master/base
>> http://download.nutyx.org/logs/x86_64/development/base/
>> 
>> BLFS
>> https://github.com/NuTyX/core/tree/master/cli
>> http://download.nutyx.org/logs/x86_64/development/cli/
>-- 
>http://lists.linuxfromscratch.org/listinfo/lfs-dev
>FAQ: http://www.linuxfromscratch.org/faq/
>Unsubscribe: See the above information page

You don't, but we use the version string on our existing instructions. I've 
also managed to get the loop in local-threads.h (sp? I'm not in front of it 
ATM). make -d revealed that it was comparing to files in the include directory 
one level higher. Finding these files to be older than the recently rebuilt 
file forced another rebuild... Though undesirable, this is actually ok the 
first 300 or so times that it happens, but it does eventually lead to a 
recursive loop. This following a successful make, but without obsolete nls, 
hence the need for rebuild. Keep in mind, this is all from memory as I'm not in 
front of the machine at this time, so corrections are welcome. I'll be digging 
into that issue this evening if others don't beat me to it.

--DJ
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

Reply via email to