[Buildroot] [PATCH 1/1] package/squashfs: bump to version 4.7.4

[Buildroot] [PATCH 1/1] package/squashfs: bump to version 4.7.4

[Fiona Klute via buildroot]

Upstream changelog:
https://github.com/plougher/squashfs-tools/blob/4.7.4/CHANGES.md

Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
---
 package/squashfs/squashfs.hash | 4 ++--
 package/squashfs/squashfs.mk   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/package/squashfs/squashfs.hash b/package/squashfs/squashfs.hash
index c921d638bb..eb9bc34282 100644
--- a/package/squashfs/squashfs.hash
+++ b/package/squashfs/squashfs.hash
@@ -1,5 +1,5 @@
-# Locally computed
-sha256  94201754b36121a9f022a190c75f718441df15402df32c2b520ca331a107511c  squashfs-tools-4.6.1.tar.gz
+# From https://github.com/plougher/squashfs-tools/releases/tag/4.7.4
+sha256  91c49f9a1ed972ad00688a38222119e2baf49ba74cf5fda05729a79d7d59d335  squashfs-tools-4.7.4.tar.gz
 
 # License files
 sha256  8177f97513213526df2cf6184d8ff986c675afb514d4e68a404010521b880643  COPYING
diff --git a/package/squashfs/squashfs.mk b/package/squashfs/squashfs.mk
index f2cb0ab25e..04b328ccab 100644
--- a/package/squashfs/squashfs.mk
+++ b/package/squashfs/squashfs.mk
@@ -4,7 +4,7 @@
 #
 ################################################################################
 
-SQUASHFS_VERSION = 4.6.1
+SQUASHFS_VERSION = 4.7.4
 SQUASHFS_SOURCE = squashfs-tools-$(SQUASHFS_VERSION).tar.gz
 SQUASHFS_SITE = https://github.com/plougher/squashfs-tools/releases/download/$(SQUASHFS_VERSION)
 SQUASHFS_LICENSE = GPL-2.0+
-- 
2.51.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] package/squashfs: bump to version 4.7.4

[Julien Olivain via buildroot]

Hi Fiona,

Thanks for the patch.

On 03/01/2026 12:40, Fiona Klute via buildroot wrote:
> Upstream changelog:
> https://github.com/plougher/squashfs-tools/blob/4.7.4/CHANGES.md
> 
> Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
> ---
[...]
> diff --git a/package/squashfs/squashfs.mk 
> b/package/squashfs/squashfs.mk
> index f2cb0ab25e..04b328ccab 100644
> --- a/package/squashfs/squashfs.mk
> +++ b/package/squashfs/squashfs.mk
> @@ -4,7 +4,7 @@
>  #
>  
> ################################################################################
> 
> -SQUASHFS_VERSION = 4.6.1
> +SQUASHFS_VERSION = 4.7.4

This new version is introducing new build failures. See:
https://gitlab.com/jolivain/buildroot/-/pipelines/2243847808

For reference, the previous version passes test-pkg:
https://gitlab.com/jolivain/buildroot/-/pipelines/2243853301

This is likely due to the new SEEK_DATA usage in lseek(), which
might not be always present or might require _GNU_SOURCE to
be defined. See:
https://man7.org/linux/man-pages/man2/lseek.2.html

Could you have a look, please?

Best regards,

Julien.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] package/squashfs: bump to version 4.7.4

[Fiona Klute via buildroot]

Hi Julien!

Am 04.01.26 um 13:52 schrieb Julien Olivain:
> Hi Fiona,
> 
> Thanks for the patch.
> 
> On 03/01/2026 12:40, Fiona Klute via buildroot wrote:
>> Upstream changelog:
>> https://github.com/plougher/squashfs-tools/blob/4.7.4/CHANGES.md
>>
>> Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
>> ---
> [...]
>> diff --git a/package/squashfs/squashfs.mk b/package/squashfs/squashfs.mk
>> index f2cb0ab25e..04b328ccab 100644
>> --- a/package/squashfs/squashfs.mk
>> +++ b/package/squashfs/squashfs.mk
>> @@ -4,7 +4,7 @@
>>  #
>>
>> ################################################################################
>>
>> -SQUASHFS_VERSION = 4.6.1
>> +SQUASHFS_VERSION = 4.7.4
> 
> This new version is introducing new build failures. See:
> https://gitlab.com/jolivain/buildroot/-/pipelines/2243847808
> 
> For reference, the previous version passes test-pkg:
> https://gitlab.com/jolivain/buildroot/-/pipelines/2243853301
> 
> This is likely due to the new SEEK_DATA usage in lseek(), which
> might not be always present or might require _GNU_SOURCE to
> be defined. See:
> https://man7.org/linux/man-pages/man2/lseek.2.html
> 
> Could you have a look, please?
Looks to me like the toolchains need to be updated. The job log clearly 
shows -D_GNU_SOURCE on the command line. What's noticeable is that the 
failing builds all use

BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/$JOB_NAME-2020.11.2.tar.bz2"

while the passing ones (didn't check all of them, but a handful) use 
Bootlin stable toolchains.

E.g. in the br-arm-full-static one 
arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/unistd.h does not 
define SEEK_DATA at all, with or without _GNU_SOURCE, unlike with a 
current glibc version.

Interestingly musl does *not* require _GNU_SOURCE, unistd.h defines all 
SEEK_* macros unconditionally. I did not check since when though, I 
wouldn't be surprised if a 2020 version would fail, too.

Best regards,
Fiona

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] package/squashfs: bump to version 4.7.4

[Fiona Klute via buildroot]

Am 04.01.26 um 15:43 schrieb Fiona Klute via buildroot:
> Hi Julien!
> 
> Am 04.01.26 um 13:52 schrieb Julien Olivain:
>> Hi Fiona,
>>
>> Thanks for the patch.
>>
>> On 03/01/2026 12:40, Fiona Klute via buildroot wrote:
>>> Upstream changelog:
>>> https://github.com/plougher/squashfs-tools/blob/4.7.4/CHANGES.md
>>>
>>> Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
>>> ---
>> [...]
>>> diff --git a/package/squashfs/squashfs.mk b/package/squashfs/squashfs.mk
>>> index f2cb0ab25e..04b328ccab 100644
>>> --- a/package/squashfs/squashfs.mk
>>> +++ b/package/squashfs/squashfs.mk
>>> @@ -4,7 +4,7 @@
>>>  #
>>>
>>> ################################################################################
>>>
>>> -SQUASHFS_VERSION = 4.6.1
>>> +SQUASHFS_VERSION = 4.7.4
>>
>> This new version is introducing new build failures. See:
>> https://gitlab.com/jolivain/buildroot/-/pipelines/2243847808
>>
>> For reference, the previous version passes test-pkg:
>> https://gitlab.com/jolivain/buildroot/-/pipelines/2243853301
>>
>> This is likely due to the new SEEK_DATA usage in lseek(), which
>> might not be always present or might require _GNU_SOURCE to
>> be defined. See:
>> https://man7.org/linux/man-pages/man2/lseek.2.html
>>
>> Could you have a look, please?
> Looks to me like the toolchains need to be updated. The job log clearly 
> shows -D_GNU_SOURCE on the command line. What's noticeable is that the 
> failing builds all use
> 
> BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/ 
> tarballs/$JOB_NAME-2020.11.2.tar.bz2"
> 
> while the passing ones (didn't check all of them, but a handful) use 
> Bootlin stable toolchains.
> 
> E.g. in the br-arm-full-static one arm-buildroot-linux-uclibcgnueabi/ 
> sysroot/usr/include/unistd.h does not define SEEK_DATA at all, with or 
> without _GNU_SOURCE, unlike with a current glibc version.
> 
> Interestingly musl does *not* require _GNU_SOURCE, unistd.h defines all 
> SEEK_* macros unconditionally. I did not check since when though, I 
> wouldn't be surprised if a 2020 version would fail, too.
Oh, another relevant detail: In uClibc SEEK_DATA support is a fairly 
recent addition (commit July 2024, first tag including it is v1.0.50). 
So uClibc toolchains from 2020 definitely won't work. See: 
https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/include/unistd.h?id=05b11809bd11450aff3d20e43f18415ce58601e7

Best regards,
Fiona

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] package/squashfs: bump to version 4.7.4

[Julien Olivain via buildroot]

Hi FIona,

On 04/01/2026 16:34, Fiona Klute wrote:
> Am 04.01.26 um 15:43 schrieb Fiona Klute via buildroot:
>> Hi Julien!
>> 
>> Am 04.01.26 um 13:52 schrieb Julien Olivain:
>>> Hi Fiona,
>>> 
>>> Thanks for the patch.
>>> 
>>> On 03/01/2026 12:40, Fiona Klute via buildroot wrote:
>>>> Upstream changelog:
>>>> https://github.com/plougher/squashfs-tools/blob/4.7.4/CHANGES.md
>>>> 
>>>> Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
>>>> ---
>>> [...]
>>>> diff --git a/package/squashfs/squashfs.mk 
>>>> b/package/squashfs/squashfs.mk
>>>> index f2cb0ab25e..04b328ccab 100644
>>>> --- a/package/squashfs/squashfs.mk
>>>> +++ b/package/squashfs/squashfs.mk
>>>> @@ -4,7 +4,7 @@
>>>>  #
>>>> 
>>>> ################################################################################
>>>> 
>>>> -SQUASHFS_VERSION = 4.6.1
>>>> +SQUASHFS_VERSION = 4.7.4
>>> 
>>> This new version is introducing new build failures. See:
>>> https://gitlab.com/jolivain/buildroot/-/pipelines/2243847808
>>> 
>>> For reference, the previous version passes test-pkg:
>>> https://gitlab.com/jolivain/buildroot/-/pipelines/2243853301
>>> 
>>> This is likely due to the new SEEK_DATA usage in lseek(), which
>>> might not be always present or might require _GNU_SOURCE to
>>> be defined. See:
>>> https://man7.org/linux/man-pages/man2/lseek.2.html
>>> 
>>> Could you have a look, please?
>> Looks to me like the toolchains need to be updated. The job log 
>> clearly shows -D_GNU_SOURCE on the command line. What's noticeable is 
>> that the failing builds all use
>> 
>> BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/ 
>> tarballs/$JOB_NAME-2020.11.2.tar.bz2"
>> 
>> while the passing ones (didn't check all of them, but a handful) use 
>> Bootlin stable toolchains.
>> 
>> E.g. in the br-arm-full-static one arm-buildroot-linux-uclibcgnueabi/ 
>> sysroot/usr/include/unistd.h does not define SEEK_DATA at all, with or 
>> without _GNU_SOURCE, unlike with a current glibc version.
>> 
>> Interestingly musl does *not* require _GNU_SOURCE, unistd.h defines 
>> all SEEK_* macros unconditionally. I did not check since when though, 
>> I wouldn't be surprised if a 2020 version would fail, too.
> Oh, another relevant detail: In uClibc SEEK_DATA support is a fairly 
> recent addition (commit July 2024, first tag including it is v1.0.50). 
> So uClibc toolchains from 2020 definitely won't work. See: 
> https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/include/unistd.h?id=05b11809bd11450aff3d20e43f18415ce58601e7

Thanks for the extra information. Sorry I overlooked that
_GNU_SOURCE was already there.

This SEEK_DATA usage was introduced in upstream commit:
https://github.com/plougher/squashfs-tools/commit/fffbd0b76d529a9e38ce615f73dbcaafad40ae55
first included in squashfs-tools release 4.7.3 (2025-11-06).

This definition has been in glibc for quite some time:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=798be72d127adf18f382323d0eed0a1e394967f8
included in glibc-2.15 (2011-12-23).

As you pointed out, musl introduced this macro much later, in:
https://git.musl-libc.org/cgit/musl/commit/?id=cbacd638e32a02edbe66c48ae3d1361bc06a492a
in v1.2.3 (2022-04-07).

It was introduced in uclibc in commit:
https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=05b11809bd11450aff3d20e43f18415ce58601e7
in v1.0.50 (2024-08-13).

squashfs-tools does not test the availability of this SEEK_DATA
macro before using it.

Since the uclibc and musl introduced it "recently", updating
toolchains can be difficult. We could eventually restrict
squashfs-tools to glibc only for external toolchains (because
we know internal toolchains will have sufficient uclibc or musl
versions).

Maybe we could also propose an upstream patch to allow
squafs-tools to support other libcs. Some
packages are providing those definitions, if not available.
For example:
https://github.com/util-linux/util-linux/blob/v2.41.3/include/c.h#L522

What do you think?

> Best regards,
> Fiona

Best regards,

Julien.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] package/squashfs: bump to version 4.7.4

[Fiona Klute via buildroot]

Hi Julien!

Am 04.01.26 um 19:46 schrieb Julien Olivain:
> Hi FIona,
> 
> On 04/01/2026 16:34, Fiona Klute wrote:
>> Am 04.01.26 um 15:43 schrieb Fiona Klute via buildroot:
>>> Hi Julien!
>>>
>>> Am 04.01.26 um 13:52 schrieb Julien Olivain:
>>>> Hi Fiona,
>>>>
>>>> Thanks for the patch.
>>>>
>>>> On 03/01/2026 12:40, Fiona Klute via buildroot wrote:
>>>>> Upstream changelog:
>>>>> https://github.com/plougher/squashfs-tools/blob/4.7.4/CHANGES.md
>>>>>
>>>>> Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
>>>>> ---
>>>> [...]
>>>>> diff --git a/package/squashfs/squashfs.mk b/package/squashfs/ 
>>>>> squashfs.mk
>>>>> index f2cb0ab25e..04b328ccab 100644
>>>>> --- a/package/squashfs/squashfs.mk
>>>>> +++ b/package/squashfs/squashfs.mk
>>>>> @@ -4,7 +4,7 @@
>>>>>  #
>>>>>
>>>>> ################################################################################
>>>>>
>>>>> -SQUASHFS_VERSION = 4.6.1
>>>>> +SQUASHFS_VERSION = 4.7.4
>>>>
>>>> This new version is introducing new build failures. See:
>>>> https://gitlab.com/jolivain/buildroot/-/pipelines/2243847808
>>>>
>>>> For reference, the previous version passes test-pkg:
>>>> https://gitlab.com/jolivain/buildroot/-/pipelines/2243853301
>>>>
>>>> This is likely due to the new SEEK_DATA usage in lseek(), which
>>>> might not be always present or might require _GNU_SOURCE to
>>>> be defined. See:
>>>> https://man7.org/linux/man-pages/man2/lseek.2.html
>>>>
>>>> Could you have a look, please?
>>> Looks to me like the toolchains need to be updated. The job log 
>>> clearly shows -D_GNU_SOURCE on the command line. What's noticeable is 
>>> that the failing builds all use
>>>
>>> BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/ 
>>> toolchains/ tarballs/$JOB_NAME-2020.11.2.tar.bz2"
>>>
>>> while the passing ones (didn't check all of them, but a handful) use 
>>> Bootlin stable toolchains.
>>>
>>> E.g. in the br-arm-full-static one arm-buildroot-linux-uclibcgnueabi/ 
>>> sysroot/usr/include/unistd.h does not define SEEK_DATA at all, with 
>>> or without _GNU_SOURCE, unlike with a current glibc version.
>>>
>>> Interestingly musl does *not* require _GNU_SOURCE, unistd.h defines 
>>> all SEEK_* macros unconditionally. I did not check since when though, 
>>> I wouldn't be surprised if a 2020 version would fail, too.
>> Oh, another relevant detail: In uClibc SEEK_DATA support is a fairly 
>> recent addition (commit July 2024, first tag including it is v1.0.50). 
>> So uClibc toolchains from 2020 definitely won't work. See: https:// 
>> cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/include/unistd.h? 
>> id=05b11809bd11450aff3d20e43f18415ce58601e7
> 
> Thanks for the extra information. Sorry I overlooked that
> _GNU_SOURCE was already there.
> 
> This SEEK_DATA usage was introduced in upstream commit:
> https://github.com/plougher/squashfs-tools/commit/ 
> fffbd0b76d529a9e38ce615f73dbcaafad40ae55
> first included in squashfs-tools release 4.7.3 (2025-11-06).
> 
> This definition has been in glibc for quite some time:
> https://sourceware.org/git/? 
> p=glibc.git;a=commitdiff;h=798be72d127adf18f382323d0eed0a1e394967f8
> included in glibc-2.15 (2011-12-23).
> 
> As you pointed out, musl introduced this macro much later, in:
> https://git.musl-libc.org/cgit/musl/commit/? 
> id=cbacd638e32a02edbe66c48ae3d1361bc06a492a
> in v1.2.3 (2022-04-07).
> 
> It was introduced in uclibc in commit:
> https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/? 
> id=05b11809bd11450aff3d20e43f18415ce58601e7
> in v1.0.50 (2024-08-13).
> 
> squashfs-tools does not test the availability of this SEEK_DATA
> macro before using it.
> 
> Since the uclibc and musl introduced it "recently", updating
> toolchains can be difficult. We could eventually restrict
> squashfs-tools to glibc only for external toolchains (because
> we know internal toolchains will have sufficient uclibc or musl
> versions).
> 
> Maybe we could also propose an upstream patch to allow
> squafs-tools to support other libcs. Some
> packages are providing those definitions, if not available.
> For example:
> https://github.com/util-linux/util-linux/blob/v2.41.3/include/c.h#L522
> 
> What do you think?
I've created an upstream issue about the problem, citing your version 
details (thanks!): https://github.com/plougher/squashfs-tools/issues/338

On the Buildroot side I wonder how old toolchains can reasonably be 
before we consider them *too old*. So far I thought the Bootlin stable 
toolchains were the expected baseline, because they're supposed to be 
used for tests unless there's a good reason not to. Personally, I 
wouldn't consider musl 1.2.3 "recent", uClibc-ng 1.0.50 maybe kind of, 
but toolchains from 2020 definitely outdated. I may be influenced by the 
~2 year Debian stable cycle. ;-)

Best regards,
Fiona

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] package/squashfs: bump to version 4.7.4

[Fiona Klute via buildroot]

Am 05.01.26 um 00:42 schrieb Fiona Klute:
> Hi Julien!
> 
> Am 04.01.26 um 19:46 schrieb Julien Olivain:
>> Hi FIona,
>>
>> On 04/01/2026 16:34, Fiona Klute wrote:
>>> Am 04.01.26 um 15:43 schrieb Fiona Klute via buildroot:
>>>> Hi Julien!
>>>>
>>>> Am 04.01.26 um 13:52 schrieb Julien Olivain:
>>>>> Hi Fiona,
>>>>>
>>>>> Thanks for the patch.
>>>>>
>>>>> On 03/01/2026 12:40, Fiona Klute via buildroot wrote:
>>>>>> Upstream changelog:
>>>>>> https://github.com/plougher/squashfs-tools/blob/4.7.4/CHANGES.md
>>>>>>
>>>>>> Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
>>>>>> ---
>>>>> [...]
>>>>>> diff --git a/package/squashfs/squashfs.mk b/package/squashfs/ 
>>>>>> squashfs.mk
>>>>>> index f2cb0ab25e..04b328ccab 100644
>>>>>> --- a/package/squashfs/squashfs.mk
>>>>>> +++ b/package/squashfs/squashfs.mk
>>>>>> @@ -4,7 +4,7 @@
>>>>>>  #
>>>>>>
>>>>>> ################################################################################
>>>>>>
>>>>>> -SQUASHFS_VERSION = 4.6.1
>>>>>> +SQUASHFS_VERSION = 4.7.4
>>>>>
>>>>> This new version is introducing new build failures. See:
>>>>> https://gitlab.com/jolivain/buildroot/-/pipelines/2243847808
>>>>>
>>>>> For reference, the previous version passes test-pkg:
>>>>> https://gitlab.com/jolivain/buildroot/-/pipelines/2243853301
>>>>>
>>>>> This is likely due to the new SEEK_DATA usage in lseek(), which
>>>>> might not be always present or might require _GNU_SOURCE to
>>>>> be defined. See:
>>>>> https://man7.org/linux/man-pages/man2/lseek.2.html
>>>>>
>>>>> Could you have a look, please?
>>>> Looks to me like the toolchains need to be updated. The job log 
>>>> clearly shows -D_GNU_SOURCE on the command line. What's noticeable 
>>>> is that the failing builds all use
>>>>
>>>> BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/ 
>>>> toolchains/ tarballs/$JOB_NAME-2020.11.2.tar.bz2"
>>>>
>>>> while the passing ones (didn't check all of them, but a handful) use 
>>>> Bootlin stable toolchains.
>>>>
>>>> E.g. in the br-arm-full-static one arm-buildroot-linux- 
>>>> uclibcgnueabi/ sysroot/usr/include/unistd.h does not define 
>>>> SEEK_DATA at all, with or without _GNU_SOURCE, unlike with a current 
>>>> glibc version.
>>>>
>>>> Interestingly musl does *not* require _GNU_SOURCE, unistd.h defines 
>>>> all SEEK_* macros unconditionally. I did not check since when 
>>>> though, I wouldn't be surprised if a 2020 version would fail, too.
>>> Oh, another relevant detail: In uClibc SEEK_DATA support is a fairly 
>>> recent addition (commit July 2024, first tag including it is 
>>> v1.0.50). So uClibc toolchains from 2020 definitely won't work. See: 
>>> https:// cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/include/ 
>>> unistd.h? id=05b11809bd11450aff3d20e43f18415ce58601e7
>>
>> Thanks for the extra information. Sorry I overlooked that
>> _GNU_SOURCE was already there.
>>
>> This SEEK_DATA usage was introduced in upstream commit:
>> https://github.com/plougher/squashfs-tools/commit/ 
>> fffbd0b76d529a9e38ce615f73dbcaafad40ae55
>> first included in squashfs-tools release 4.7.3 (2025-11-06).
>>
>> This definition has been in glibc for quite some time:
>> https://sourceware.org/git/? 
>> p=glibc.git;a=commitdiff;h=798be72d127adf18f382323d0eed0a1e394967f8
>> included in glibc-2.15 (2011-12-23).
>>
>> As you pointed out, musl introduced this macro much later, in:
>> https://git.musl-libc.org/cgit/musl/commit/? 
>> id=cbacd638e32a02edbe66c48ae3d1361bc06a492a
>> in v1.2.3 (2022-04-07).
>>
>> It was introduced in uclibc in commit:
>> https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/? 
>> id=05b11809bd11450aff3d20e43f18415ce58601e7
>> in v1.0.50 (2024-08-13).
>>
>> squashfs-tools does not test the availability of this SEEK_DATA
>> macro before using it.
>>
>> Since the uclibc and musl introduced it "recently", updating
>> toolchains can be difficult. We could eventually restrict
>> squashfs-tools to glibc only for external toolchains (because
>> we know internal toolchains will have sufficient uclibc or musl
>> versions).
>>
>> Maybe we could also propose an upstream patch to allow
>> squafs-tools to support other libcs. Some
>> packages are providing those definitions, if not available.
>> For example:
>> https://github.com/util-linux/util-linux/blob/v2.41.3/include/c.h#L522
>>
>> What do you think?
> I've created an upstream issue about the problem, citing your version 
> details (thanks!): https://github.com/plougher/squashfs-tools/issues/338

Update: The upstream maintainer has added a fallback similar to the 
util-linux one [1]. However a new issue has been reported since about 
corrupted images with all-zero files [2], so I think it's best to delay 
the update until that's resolved.

> On the Buildroot side I wonder how old toolchains can reasonably be 
> before we consider them *too old*. So far I thought the Bootlin stable 
> toolchains were the expected baseline, because they're supposed to be 
> used for tests unless there's a good reason not to. Personally, I 
> wouldn't consider musl 1.2.3 "recent", uClibc-ng 1.0.50 maybe kind of, 
> but toolchains from 2020 definitely outdated. I may be influenced by the 
> ~2 year Debian stable cycle. ;-)
With the upstream fallback merged the question isn't critical any more, 
but I think it'd be generally useful to have a documented answer.

Best regards,
Fiona


[1] 
https://github.com/plougher/squashfs-tools/commit/9ac89115cc0a3acc71c5d34d7e2ee9379159807a
[2] https://github.com/plougher/squashfs-tools/issues/339

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] package/squashfs: bump to version 4.7.4

[Thomas Petazzoni via buildroot]

Hello Fiona,

On Tue, 6 Jan 2026 14:52:07 +0100
Fiona Klute <fiona.klute@gmx.de> wrote:

> > I've created an upstream issue about the problem, citing your version 
> > details (thanks!): https://github.com/plougher/squashfs-tools/issues/338  
> 
> Update: The upstream maintainer has added a fallback similar to the 
> util-linux one [1]. However a new issue has been reported since about 
> corrupted images with all-zero files [2], so I think it's best to delay 
> the update until that's resolved.
> 
> > On the Buildroot side I wonder how old toolchains can reasonably be 
> > before we consider them *too old*. So far I thought the Bootlin stable 
> > toolchains were the expected baseline, because they're supposed to be 
> > used for tests unless there's a good reason not to. Personally, I 
> > wouldn't consider musl 1.2.3 "recent", uClibc-ng 1.0.50 maybe kind of, 
> > but toolchains from 2020 definitely outdated. I may be influenced by the 
> > ~2 year Debian stable cycle. ;-)  
> With the upstream fallback merged the question isn't critical any more, 
> but I think it'd be generally useful to have a documented answer.

On the gcc version, we do have a fairly clear policy, but it's true we
don't have such a policy on the C library. We try to reasonably support
older toolchains as we recognize people may be using somewhat old
toolchains to support specific HW, or just because they "fear"
switching to a newer toolchain. So in the case of squashfs, when there
is a relatively easy fallback solution, it's always good to have (and
good for upstream, as it makes their project more broadly "compatible").

I don't know if we want a policy that says "toolchains with components
older than X years are not supported. Can be a topic for the upcoming
Buildroot Developers Meeting though.

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot