| Newsgroups |
gmane.linux.lfs.support |
| Message-ID |
<[email protected]> |
On 8/18/26 08:11, Rainer Fiebig ([email protected] via lfs-support Mailing
List) wrote:
> Am 18.08.26 um 13:00 schrieb Pocket ([email protected] via
> lfs-support Mailing List):
>>
>>
>> On 8/18/26 03:18, Rainer Fiebig ([email protected] via lfs-support Mailing
>> List) wrote:
>>> Am 18.08.26 um 03:56 schrieb Pocket ([email protected] via
>>> lfs-support Mailing List):
>>>>
>>>>
>>>> On 8/17/26 17:10, Rainer Fiebig ([email protected] via lfs-support Mailing
>>>> List) wrote:
>>>>> Am 17.08.26 um 22:26 schrieb Pocket ([email protected] via
>>>>> lfs-support Mailing List):
>>>>>>
>>>>>>
>>>>>> On 8/17/26 14:54, md ([email protected] via lfs-support Mailing
>>>>>> List) wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Do I understand correctly that you took the x86_64 (default) LFS
>>>>>>> branch and
>>>>>>> patched it to build on arm64 (aarch64)?
>>>>>>
>>>>>> Yes that is correct
>>>>>>
>>>>>>> Could you comment how many changes were needed compared to this
>>>>>>> failed
>>>>>>> attempt
>>>>>>> https://github.com/marcindulak/jhalfs-ci/issues/1 from 2022?
>>>>>>>
>>>>>>
>>>>>> gcc and binutils, used gcc flags is the brunt of the changes.
>>>>>> added one sed for the lib64 issue.
>>>>>>
>>>>>>
>>>>>>> The question to the LFS maintainers:
>>>>>>> What is the state of arm64 support in LFS and JHALFS
>>>>>>> (https://www.linuxfromscratch.org/alfs/)?
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Marcin
>>>>>>>
>>>>>>
>>>>>> The answer you will seek will be we only do x86_64/amd64
>>>>>
>>>>> Would be understandable. They even had to drop the SysV-version for
>>>>> lack of man-/editor-power.
>>>>>
>>>>> But congrats on your achievement! However, I do think that you should
>>>>> tell us the SBU for your Pi-5. Seems that I'm not the only one who is
>>>>> interested in that. Now that your build is complete, just run the
>>>>> binutils-build again with a DESTDIR-installation and let us know. Or
>>>>> would that lock-up your device for too long? Thanks.
>>>>>
>>>>> Rainer
>>>>>
>>>>>>
>>>>>>
>>>>
>>>> This is the information I have on the binutils=pass-1 build
>>>> It is the log file which is created at the beginning of the build
>>>> and I do a touch when the compile is complete.
>>>>
>>>> stat 035-binutils-pass1
>>>> File: 035-binutils-pass1
>>>> Size: 188096 Blocks: 368 IO Block: 4096 regular
>>>> file
>>>> Device: 0,55 Inode: 9603841 Links: 1
>>>> Access: (0644/-rw-r--r--) Uid: ( 1000/ pocket) Gid: ( 1000/
>>>> pocket)
>>>> Access: 2026-08-16 07:47:23.332251322 -0400
>>>> Modify: 2026-08-13 18:18:50.776579859 -0400
>>>> Birth: 2026-08-13 18:16:19.955848609 -0400
>>>>
>>>> So Modify time - Birth time gives about 2 minutes.
>>>
>>> I just built binutils-2.46.0 on my Ryzen 5700G BLFS-system, using the
>>> instructions for an LFS-pass-1-build. The build was scripted,
>>> explicitly "make -j1" and included unpacking and a DESTDIR-installation.
>>> From the log:
>>>
>>> Di 18 Aug 2026 08:23:01 CEST
>>> ****************************
>>> './binutils-2.46.0.tar.xz' -> '/usr/src/binutils-2.46.0.tar.xz'
>>> 08:23:01 - binutils-2.46.0.tar.xz
>>> 08:25:19 - binutils-2.46.0 installed
>>>
>>> That's about 2:18 min.
>>>
>>> According to [1], the 5700G's single-thread-performance is 3,282.
>>> That of the ARM Cortex-A76 is 1,341 [2]
>>>
>>> So I think that under the same conditions the SBU of an ARM Cortex-A76
>>> system would be about twice that of an AMD 5700G system. Which is
>>> better than I expected. Thanks.
>>>
>>> Rainer
>>>
>>>
>>> [1] https://www.cpubenchmark.net/single-thread
>>> [2] https://www.cpubenchmark.net/single-thread/page4
>>>
>>>
>>
>> The build doesn't have the time for unpacking, it is just the running of
>> the script
>>
>>
>> cat 035-binutils-pass1
>> mkdir -v build
>> cd build
>>
>> ../configure --prefix=$LFS/tools \
>> --with-sysroot=$LFS \
>> --target=$LFS_TGT \
>> --disable-nls \
>> --enable-gprofng=no \
>> --disable-werror \
>> --enable-new-dtags \
>> --enable-default-hash-style=gnu
>>
>> make
>>
>> make install
>>
>> Still don't know why it matters
>
> 1) To get an idea of how long a build will take, of course. That may be
> especially valuable information for first-time-users. Take for instance
> gcc-15.2.0: according to LFS-13.0, the build will take approx. 45 SBU,
> including the tests. To some people (including me) it makes a
> difference whether one has to reckon with 45 min or 3 hours for that.
> One may therefore decide to not run the tests. Or take qtwebengine with
> 360 SBU (-j1). You may not want to build that at all.
I have built qtwebengine, in fact several times
>
> Build-times are also good to know if your box automatically goes into
> standby after a certain time. If you have set that value to a default
> of 45 min, for instance, and the build will take 60 min, you better
> adapt that value.
>
Maybe you shouldn't do that
> 2) To compare the performance of devices. Old box and new box, for
> instance. Or I for one found it interesting that you can build binutils
> in ~5 min with a Pi 5. And not 50 min, as I assumed before. ;)
Well it isn't the stone age any more......
> Rainer
ARM is not _86_64, YMMV
What's not to like about 16GB memory?
Men must know their limitations - Clint Eastwood
--
Hindi madali ang maging ako
--
http://lists.linuxfromscratch.org/sympa/info/lfs-support
Unsubscribe: See the above information page