uClibc-ng support?

[wbx-github]

Feature or enhancement

Proposal:

Hi, I am the maintainer of uClibc-ng (https://uclibc-ng.org) and have a question. In commit c163d7f0b67a568e9b64eeb9c1cbbaa127818596 uClibc-ng support was silently disabled. Is there any reason for that?

uClibc-ng is regular released and still have an userbase not only for noMMU targets. It is still supported as an alternative C library in Buildroot.

Thanks for any response.

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

[Eclips4]

cc @erlend-aasland

[zware]

As far as I can tell, ~~the change was not intentional. However, it's not~~[^1] uClibc(-ng) has never been officially supported and we have no testing of it. If the patch to fix support is small and self-contained it has a high chance of being accepted, but the chances of it breaking again are also fairly high.

[^1]: I originally missed that in the mentioned commit, there's an explicit if defined(__UCLIBC__) with an unconditional error.

[wbx-github]

I am now confused. I cross-compiled Python 3.13.0b1 which includes the change, but it does not break. I even can run python3 inside Qemu-system-arm with my uClibc-ng based system. Is the error only fatal when native compiling python3?

[zware]

Ah, now I do actually see https://github.com/python/cpython/commit/c163d7f0b67a568e9b64eeb9c1cbbaa127818596#diff-84f2c0139db5f7237caa3f5147bc2e01a5206e706f16f5300c5bfffd0f8fcb78R23-R24 (not sure how I missed that before, sorry about that), so it does seem to have been an intentional change. Everything else in my previous message stands, though: we don't have any way to test it, but a small patch fixing uClibc-ng support would likely be accepted.

[vfazio]

We've been using uclibc + Python in BR for a number of years with little issue. I think we had maybe one or two patches, one is implicitly fixed with the triplet detection logic changes as part of 3.13 ($build_os vs $host_os variable usage) and the other is addressed in newer versions of uclibc so shouldn't be an issue.

[vfazio]

I see part of the issue...

In configure.ac:

AC_MSG_CHECKING([for the platform triplet based on compiler characteristics])
if $CPP $CPPFLAGS $srcdir/Misc/platform_triplet.c >conftest.out 2>/dev/null; then
  PLATFORM_TRIPLET=`grep '^PLATFORM_TRIPLET=' conftest.out | tr -d ' 	'`
  PLATFORM_TRIPLET="${PLATFORM_TRIPLET@%:@PLATFORM_TRIPLET=}"
  AC_MSG_RESULT([$PLATFORM_TRIPLET])
else
  AC_MSG_RESULT([none])
fi
rm -f conftest.out

output/build/python3-3.13.0/Misc/platform_triplet.c:36:4: error: #error uclibc not supported
   36 | #  error uclibc not supported
      |    ^~~~~
output/build/python3-3.13.0/Misc/platform_triplet.c:151:1: warning: data definition has no type or storage class
  151 | PLATFORM_TRIPLET=aarch64-linux-LIBC
      | ^~~~~~~~~~~~~~~~
output/build/python3-3.13.0/Misc/platform_triplet.c:151:1: warning: type defaults to ‘int’ in declaration of ‘PLATFORM_TRIPLET’ [-Wimplicit-int]
output/build/python3-3.13.0/Misc/platform_triplet.c:151:18: error: ‘aarch64’ undeclared here (not in a function)
  151 | PLATFORM_TRIPLET=aarch64-linux-LIBC
      |                  ^~~~~~~
output/build/python3-3.13.0/Misc/platform_triplet.c:151:26: error: ‘linux’ undeclared here (not in a function)
  151 | PLATFORM_TRIPLET=aarch64-linux-LIBC
      |                          ^~~~~
output/build/python3-3.13.0/Misc/platform_triplet.c:151:32: error: ‘LIBC’ undeclared here (not in a function)
  151 | PLATFORM_TRIPLET=aarch64-linux-LIBC
      |                                ^~~~
output/build/python3-3.13.0/Misc/platform_triplet.c:151:1: error: expected ‘,’ or ‘;’ at end of input
  151 | PLATFORM_TRIPLET=aarch64-linux-LIBC
      | ^~~~~~~~~~~~~~~~
vfazio@vfazio4 ~/development/buildroot $ echo $?
1

The problem is that if the compile fails, which we are expecting here because there is no "formal" support, it defaults to an empty triplet but does not actually cause the build to error out.