Re: LFS-R13.0 on RPI 4 and 5

Pocket ([email protected] via lfs-support Mailing List) <[email protected]>
Newsgroups gmane.linux.lfs.support
Message-ID <[email protected]>

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


-- 
Hindi madali ang maging ako

-- 
http://lists.linuxfromscratch.org/sympa/info/lfs-support
Unsubscribe: See the above information page
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.