Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Mon May 09, 2022 6:49 Post subject:
Ive locked the thread to prevent offtopic remarks and moved such pre-existing comment to moderators forums. In addition, the nature of some replies were conducive to a opposing forums rules standpoint. We (myself included) must all do better as a community to improve general user experience in these boards.
If any other moderator wants to reopen thread and delete/move this post, feel free to do so.
If any community members wish to have this topic reopened, please do not hesitate to ask any of the active moderators via PM, citing a good reason for request, e.g. adding important information that would benefit the community regarding the subject discussed or to edit their previous replies, etc...
I wonder whether I can avoid the uClibc trouble while I always use unbound on Linksys WRT1900ACS, or dnscrypt dns on Netgear R6250 (bad performance for unbound)
Joined: 08 May 2018 Posts: 14244 Location: Texas, USA
Posted: Tue Jun 21, 2022 15:28 Post subject:
Follow-up update:
I have not carefully inspected current publicly released toolchains, other than noticing there are uClibc toolchains in the archive, but this commit makes me go, "hmmm..."
If you also inspect all of these makefiles, there are references to uclibc; mainly dependent on configuration files - userland binaries may be unaffected, but kernels may not be.
Also verified that FT has indeed made commits for the patches:
Maybe it's just as you have alluded to, for putting it in a staging directory, and nothing more. I'm sure it would be a pain in the ass to remove all references to uClibc if it is not in use, however, I think the Linux 2.4 and Linux 2.6 firmware images may still require uClibc if they are still using the factory firmware binary blobs. I could be wrong, but without confirmation...