Am Mittwoch, den 31.01.2018, 19:16 +0100 schrieb Pierre Labastie: > On 31/01/2018 18:57, Thomas Trepl wrote: > > Am Mittwoch, den 31.01.2018, 18:48 +0100 schrieb Pierre Labastie: > > > On 31/01/2018 18:16, thomas wrote: > > > > Hi all, > > > > > > > > does (B)LFS "officially" support i686 platforms or did we > > > > silently > > > > drop > > > > 32-bit? There were a few comments about this question in > > > > Sept/Oct > > > > last year as > > > > Bruce brought this up. I cannot find a final decision. > > > > > > > > I ask this question because of the issue occured by upgrading > > > > binutils to 2.30 > > > > with which grub2 cannot be compiled [1]. Since there are no > > > > other > > > > complains > > > > than from i686 systems, it looks like that this issue does not > > > > occur on x86_64 > > > > systems. If LFS supports 32bit, shouldn't we then refuse > > > > upgrading > > > > packages to > > > > version which do not compile on all platforms? > > > > > > > > I know, there is that good feeling of living on the bleeding > > > > edge - > > > > but what > > > > does make us feel that we have to have the most recent version > > > > in > > > > the book? > > > > The intention of the book is to show how things work - that can > > > > be > > > > pretty much > > > > achieved with not-that-new version too. This allows us to stay > > > > on a > > > > previous > > > > version if the new one does not work proper. Making a comment > > > > in > > > > the package's > > > > chapter why this is not upgraded to the last version right now > > > > should be > > > > sufficient. > > > > > > > > Yes, there may be security issues fixed in newer versions. But > > > > is > > > > that that > > > > much relevant for a LFS system where we hardly care about > > > > security > > > > fixes? > > > > > > > > Personally, i do recompiling LFS on 32bit for some of my older > > > > machines. It's > > > > as fast as for 64bit as I'm doing it in a VM (which is not > > > > realy > > > > much slower > > > > than bare metal). So compile time isn't that important to me, i > > > > think its not > > > > an argument at all. I'd be kind of sad if 32bit support would > > > > be > > > > dropped. > > > > > > > > Whats your opinion? > > > > > > Looks like all the devs (except you maybe) only compile on > > > x86_64, so > > > 32-bit > > > support has not been dropped, but it is much less tested. For the > > > binutils > > > issue, have you tried my suggestion on support? > > > > > > Pierre > > > > Yes, I placed a message on the grub-bug-list with a lot of logs > > (see > > link http://lists.gnu.org/archive/html/bug-grub/2018-01/msg00006.ht > > ml). > > > > To my text above, to make long text short: Shouldn't we downgrade > > to > > binutils-2.29.1 for a while (until a fix comes up somehow)? > > > > Sorry, I meant "my suggestion in my answer to the other Thomas on > lfs-support". Sometimes unifying names has disadvantages :-)
> You may want to try adding two flags to binutils' configure: > --enable-64-bit-bfd > --enable-targets=x86-64 --enable-targets=x86_64 results in a configure error but the --enable- 64-bit-bfd did work. You guys are so ingenious! What did you do to discover this? configure --help doesn't show those switches. Grub compiles fine with that. Will do another clean build, but for now it looks promising... -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
