Re: [Buildroot] [PATCH v4 RESEND 1/3] package/python-cramjam: new package

[Flaviu Nistor <flaviu.nistor@gmail.com>]

On Sun, Oct 11, 2026 at 1:09 PM, Peter Korsgaard wrote:
>Hi,
>
> >> +++ b/package/python-cramjam/Config.in
> >> @@ -0,0 +1,9 @@
> >> +config BR2_PACKAGE_PYTHON_CRAMJAM
> >> +	bool "python-cramjam"
> >> +	depends on !BR2_ARM_CPU_ARMV5
> 
>> Why? Perhaps you mean BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS?
>
>I saw that you were explicitly not testing with our default armv5
>kernel, so I gave it a try and the code indeed seems to be buggy:
>
>Reading symbols from python3...
>(gdb) run -c 'import cramjam'
>Starting program: /usr/bin/python3 -c 'import cramjam'
>[Thread debugging using libthread_db enabled]
>Using host libthread_db library "/lib/libthread_db.so.1".
>random: python3: uninitialized urandom read (24 bytes read)
>
>Program received signal SIGSEGV, Segmentation fault.
>0xb68e42dc in strcmp () from /lib/libc.so.6
>(gdb) bt
>#0  0xb68e42dc in strcmp () from /lib/libc.so.6
>#1  0xb6ca6584 in _PyImport_ResolveNameWithPackageContext (name=0x0)
>    at Python/import.c:846
>#2  0xb6b7385c in _PyModule_CreateInitialized (module=0xb6701808,
>    module_api_version=<optimized out>) at Objects/moduleobject.c:233
>#3  0xb6348018 in ?? ()
>   from /usr/lib/python3.14/site-packages/cramjam/cramjam.cpython-314-arm-linux-gnueabi.so
>Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>(gdb) random: crng init done
>info registers
>r0             0x0                 0
>r1             0xb670b3d4          3060839380
>r2             0x0                 0
>r3             0x0                 0
>r4             0x0                 0
>r5             0xb670b3cc          3060839372
>r6             0xb6848508          3062138120
>r7             0x8                 8
>r8             0xb6701808          3060799496
>r9             0xbebaa064          3199901796
>r10            0xb6f0d538          3069236536
>r11            0xb6767f48          3061219144
>r12            0xb6ec4a40          3068938816
>sp             0xbeba9e50          0xbeba9e50
>lr             0xb6ca6584          3066717572
>pc             0xb68e42dc          0xb68e42dc <strcmp+84>
>cpsr           0x60000010          1610612752
>
>So presumably something is not initialized to cause this null pointer
>exception. The fact that PyImport_ResolveNameWithPackageContext gets
>called with a null pointer is already odd.
>
>Care to report it upstream? I see that there is in the mean time a 2.13
>release.

I saw a related issue reported with a similar topic that it can't be tested
on 32-bit architectures. This is way I specified depends on !BR2_ARM_CPU_ARMV5,
since at that time I found no other solution. I have tested today and version
2.14.0 (released today) does not have this issue any more, so it runs on armv5.
James Hilliard just send a bump for 2.14.0, so for v5 I will not include this.
Here is the link to the bump:
https://lore.kernel.org/all/20261013164254.1476592-6-james.hilliard1@gmail.com/

Thanks for support,
Flaviu

>
>-- 
>Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot