There needs to be a rethink of the OpenWrt policy that development within OpenWrt is unsupported.
For one thing, development was never totally unsupported. There are an increasing number of -dev library packages, clearly intended to support development. The problem is, the current default of using sstrip on library binaries makes the accompanying -dev packages useless. Having a -dev package with a pkg-config file and headers when the underlying library is sstripped is actually worse than useless.
Some items I would suggest to move forward:
Stop using sstrip by default. Certainly stop its use for all libraries where there are accompanying -dev packages. It is causing more problems than it solves.
Include stubs for the common libraries libdl.a, librtl.a, libresolv.a, and libpthread.a. For those that don't know, these are common libraries that musl included the function of right in its libc. However many build systems try and link against them, causing them to fail. The stubs prevent them from failing. It's 32 bytes worth of file. I'm sure we can pony up the space.
Most importantly, adopt a "some development is officially supported" policy. Otherwise, why have go, gcc, and -dev packages to begin with? We adopt this policy so when a policy decision like using sstrip is contemplated in the future, then the idea that hey, we can't do this or it will break zlib-dev, libxml2-dev, ruby-dev, libncurses-dev, and others is actually part of the discussion.
How about consensus on something simple to start like: All *-dev library packages which are included in the official distribution are officially supported.
It's not that development on OpenWrt is unsupported, but rather that OpenWrt is not self-hosting meaning it cant build itself from the source while running OpenWrt.
It's been like that from the start as OpenWrt isn't a regular distribution, but rather its been specifically targeting routers, AP-s, and switches which are embedded devices with rather limited resources, so the goal was to make the images as small as possible, hence the library stripping.
So, I would ask why does OpenWrt need to be self-hosting as there are a lot of distributions that you can build OpenWrt on, heck you can do it even on macOS?
Not addressing self-hostingness here (though it's not difficult to make it so). I'm addressing limited official support for within-OpenWrt development.
One can strip libraries without using sstrip, which proceeds to lobotomize the library. The difference between the two is pretty small. On platforms where it isn't necessary, it shouldn't be the default.
This isn't the party line. Had a bit of a discussion about a related aspect of this earlier. The party line as I have seen it is that inclusion of development files in and development on OpenWrt is officially not supported.
I admittedly came out swinging (in that thread) harder than was called for, and likely put some people on the defensive. But the policy really does make no sense.
What I am suggesting, though, is: Official support for some development. Support meaning that any "-dev" library package is supported, and will be made to work as intended. Support meaning that easily supplied solutions to common issues, like the musl stubs (all 32 bytes of them), be included with gcc. And a rethink of the cost-benefit of "sstrip" vs "strip --strip-all".
As I mentioned already, OpenWrt is originally and still almost exclusively targeted at routers, AP-s, and switches so there is no reason to "officially" support development on the target devices at all nor there has been any
How will anything change if now it was "officially" supported, but it doesn't really work?
It would require dedicated manpower to keep it working, and I dont think that project itself has that manpower.
It would be great to see some core members chime in.
tl;dr: Routers are only getting more powerful. Using them for more makes sense. Reducing the activation energy to develop FOR OpenWrt by adopting low-cost policies to make it easier to develop ON OpenWrt only makes sense.
To answer the question, the use case boils down to it being far easier to perform in-situ compilation of some sort of interesting or new feature on an OpenWrt device than it is to cross-compile it.
I'm not the only one who does this. I invite anyone with access to look up stats for how often gcc, binutils, make, and golang are installed over all platforms.
I don't think the asks are too expensive:
Asks:
Reduce or remove the use of sstrip on shared libraries, certainly for those libraries which have -dev counterparts
See my analysis on the usage of sstrip vs strip --stripall
Add in stubs for certain libraries to unbreak those build systems that need the existence of libpthread, libnl, librt, etc.
Cost: Four files, 32 bytes total. Can be included in gcc since they would only be used for development.
Create the policy that if the -dev library exists for a library, then its use in development is supported, so that future changes won't break them again.
Selectively (and over time) add a few other -dev libraries. A good candidate is musl-fts, for example.
As an example of this sort of development, I've demonstrated the ability for OpenWrt to self-host. I am also in the middle of determining the viablity of using corosync and dlm_controld on OpenWrt so users can get access to shared-disk filesytems over NBD and ATA-Over-Ethernet. I think this would benefit people using OpenWrt devices for NAS.
Those are just my personal projects. Other people have others. The asks are pretty low, though, compared to the benefits.