Running Asus DSL-N14U as AP, network storage and print server

[The Man They Call Jayne]

So, I have one of these and my purpose is to run it as an AP, network storage and print server. I'll document what little I've learned and what I need, in case someone is interested.
I'm having a problem posting this, so I'll try posting it in parts.

So, what is this thing, then? Asus DSL-N14U is a big-endian MIPS device. The stock firmware runs a 2.6 kernel.
Linux DSL-N14U 2.6.22.15 #1 SMP Sat Nov 30 02:26:27 CST 2019 mips unknown
In case it isn't immediately obvious, it is a DSL modem. Wireless CAT suggests the processor is Ralink RT63365E. (The router version, RT-N14U, apparently runs a different processor, MediaTek MT7620N.)

Based on talk on the internet about ASUS routers, DSL-N14U is slightly different from other ASUS devices. Possibly because of it being MIPS, there is no nvram command-line tool, which many resources around the internet talk extensively about in relation to ASUS WRT. The cgi-bin/ scripts reference nvram functions but apparently it only exists as functions in some libraries. From what I can tell, instead of nvram there's tcapi. Tcapi is less useful because it always requires a node name and I haven't seen a list anywhere. Looking at some of the scripts, there are nodes such as Apps_Entry and Wanduck_COMMON. There's also USB_<Something I can't remember right now>. Apparently the part before the underscore seems to be enough, so e.g. Apps and USB are also accepted.

So, I'm running the device as an AP with it's LAN port connected to my actual modem LAN port. It doesn't have an AP mode as such but I basically just disabled DHCP and use the same subnet as the modem. The modem runs the DHCP and that works fine, because they're on the same subnet. I obviously still filter the MAC addresses on both devices.

Incidentally, if anyone else is running more than one router on their LAN, I very much suggest changing all their IP addresses to something else than 192.168.1.1.
That way, you'll be spared of any address conflicts, if you ever need to factory reset any of them. AFAIK, most, if not all, devices default to that address.

For the file storage, I simply stuck a 32 GB USB memory stick on it as I don't anticipate much use for it. It's NTFS, because I'm running Windows on my computer (yes, I know), and that choice does disallow the use of some features like links. Remains to be seen whether that becomes a problem.

 

[The Man They Call Jayne]

As for custom scripting, I first couldn't get custom scripts to run (tried what was described in jarpatus/asuswrt_scripts on GitHub) - even on the original 1.1.0.4 firmware.
Updating the firmware to stock 1.1.2.3_805 and installing Download Master also installed the apps_init_run.sh script and created the init.d system on the flash drive.
After that, the procedure described by jarpatus runs stuff on startup without problems - you just need the init.d/S99scriptname and a /opt/lib/ipkg/info/scriptname.control file containing the line Enabled: yes. (99 and scriptname being whatever you wish.)

One thing to note, though, is that Download Master gets downloaded and installed from the internet. At least DSL-N14U requires that it detects a WAN connection for the install to work. I tried setting a 0.0.0.0/0 route to my modem but to no avail, although setting a route to the near-by NTP server worked for that service. What worked for DM install was setting the WAN to Ethernet WAN (and enabling it). I simply connected the chosen Ethernet WAN port to the modem LAN too and then I gave it a different IP address and also another MAC address (I simply incremented the last byte on the LAN one) on Special Requirement from ISP so that the modem wouldn't accidentally route those WAN packets to the LAN address.
I disconnected the WAN port cable once I was done but I might change to using that one instead. It'd be more proper but I haven't tested what it does to the AP clients' DHCP, for example. I also haven't even tested whether DM works with the LAN or the WAN port. I just feel that while the WAN port is more likely to "work", it may also bring with it all sorts of complications I don't actually need, since I have the separate modem to handle that stuff.

After installing the Download Master, things look like this:

# ls -lF /
drwxrwxr-x    2 admin    root          577 Nov 29  2019 bin/
drwxrwxr-x    4 admin    root           64 Nov 29  2019 boaroot/
drwxrwxrwt    5 admin    root         2280 Oct 24 11:27 dev/
lrwxrwxrwx    1 admin    root            8 Nov 29  2019 etc -> /tmp/etc/
lrwxrwxrwx    1 admin    root            9 Nov 29  2019 home -> /tmp/home/
drwxrwxr-x    3 admin    root         2245 Nov 29  2019 lib/
lrwxrwxrwx    1 admin    root           11 Nov 29  2019 linuxrc -> bin/busybox*
lrwxrwxrwx    1 admin    root            8 Nov 29  2019 mnt -> /tmp/mnt/
lrwxrwxrwx    1 admin    root            8 Nov 29  2019 opt -> /tmp/opt/
dr-xr-xr-x   85 admin    root            0 Jan  1  2000 proc/
drwxrwxr-x    3 admin    root           20 Nov 29  2019 rom/
lrwxrwxrwx    1 admin    root           14 Nov 29  2019 root -> /tmp/home/root/
drwxrwxr-x    2 admin    root          684 Nov 29  2019 sbin/
drwxr-xr-x   10 admin    root            0 Jan  1  2000 sys/
drwxrwxrwt   14 admin    root          780 Oct 24 14:41 tmp/
drwxrwxr-x    3 admin    root          302 Nov 29  2019 userfs/
drwxr-xr-x    8 admin    root          103 Nov 29  2019 usr/
lrwxrwxrwx    1 admin    root            8 Nov 29  2019 var -> /tmp/var/
#

# ls -lF /opt/
-rwxrwxrwx    1 admin    root        13018 Oct 20 19:59 S50asuslighttpd.1*
-rwxrwxrwx    1 admin    root        65672 Oct 20 19:59 S50downloadmaster.1*
drwxrwxrwx    1 admin    root         4096 Oct 17 02:39 bin/
drwxrwxrwx    1 admin    root            0 Oct 17 02:37 doc/
drwxrwxrwx    1 admin    root            0 Oct 23 10:24 etc/
drwxrwxrwx    1 admin    root            0 Oct 17 02:39 include/
drwxrwxrwx    1 admin    root        28672 Oct 17 02:39 lib/
drwxrwxrwx    1 admin    root            0 Oct 17 02:36 sbin/
drwxrwxrwx    1 admin    root            0 Oct 17 02:38 share/
drwxrwxrwx    1 admin    root            0 Oct 17 02:39 tmp/
drwxrwxrwx    1 admin    root            0 Oct 17 02:36 usr/
#

# mount
/dev/mtdblock3 on / type squashfs (ro)
proc on /proc type proc (rw)
tmpfs on /tmp type tmpfs (rw,noatime)
devfs on /dev type tmpfs (rw,noatime)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/sda1 on /tmp/mnt/sda1 type ufsd (rw,nodev,noatime,nls=utf8,fmask=0,dmask=0,force)
#

# ls -lF /lib/modules/
drwxrwxr-x    3 admin    root           23 Nov 29  2019 2.6.22.15/
-rwxrwxr-x    1 admin    root         9748 Nov 29  2019 brg_shortcut.ko*
-rwxrwxr-x    1 admin    root        83496 Nov 29  2019 hw_nat.ko*
-rwxrwxr-x    1 admin    root        24372 Nov 29  2019 igmpsnoop.ko*
-rwxrwxr-x    1 admin    root        10860 Nov 29  2019 mldsnooping.ko*
-rw-rw-r--    1 admin    root         6112 Nov 29  2019 module_sel.ko
-rw-rw-r--    1 admin    root         5736 Nov 29  2019 modules.dep
-rw-rw-r--    1 admin    root        97792 Nov 29  2019 raeth.ko
-rw-rw-r--    1 admin    root      2180144 Nov 29  2019 rt5390ap.ko
-rwxrwxr-x    1 admin    root      1244344 Nov 29  2019 tc3162_dmt.ko*
-rw-rw-r--    1 admin    root       104612 Nov 29  2019 tc3162l2sar.ko
-rw-rw-r--    1 admin    root       118808 Nov 29  2019 tccicmd.ko
-rwxrwxr-x    1 admin    root         5392 Nov 29  2019 tcfullcone.ko*
-rw-rw-r--    1 admin    root        41692 Nov 29  2019 tcledctrl.ko
-rwxrwxr-x    1 admin    root         8052 Nov 29  2019 tcportbind.ko*
-rw-rw-r--    1 admin    root        24536 Nov 29  2019 tcvlantag.ko
drwxrwxr-x    2 admin    root          448 Nov 29  2019 usbhost/
#

If you want to log stuff yourself, you can write to /var/log/messages. You'll have to use the logfile format or it'll e.g. break (and stop) dmesg output on that line. You get the correct format by something like date "+%Y-%m-%d %H:%M:%s [Informational] scriptname[$$]: logmessage" >> /var/log/messages. The problem with that is that it's an ordinary file that seems to get rotated to the device log rather erratically, possibly only when the there's another update. You can also do echo logmessage >> /dev/kmsg , which gets your message on the log immediately, but the downside is that the device log shows the entry as coming from the kernel i.e. the scriptname[PID] part simply reads kernel.

Edit: Moved the mount information here and removed the post it was originally in.
Edit: Added listing of /lib/modules

 

[The Man They Call Jayne]

Why am I talking about custom scripts anyway? Well, I have a GDI printer, HP LaserJet 1018. It requires the firmware to be downloaded before printing (just once after being turned on). That's simple: cat sihp1018.dl >> /dev/lp0. So, I need to daemonize a script to monitor the attachment and detachment of the printer. One way to do it is to read and monitor the device log at /var/log/currLogFile. USB attach and remove events are shown there. (I already have a somewhat working script to that effect that keeps state by doing tail -n 1 in the main shell to control how far the subshell reads, which allows it to also control the starting position. The idea being that you can then start reading the log from the beginning and not miss the printer appearing before the script is run.) But it turns out you don't have to do that, because the printer state is also tracked by one of the tcapi variables: one can simply execute tcapi get USB usb_path_lp0 to see whether the printer is currently connected.
And, yes, you can have both the printer and the storage connected. I, for example, have a cheap Hama 4-port USB 2.0 hub allowing me to do just that.

Of course, having the firmware loaded on the printer still only allows printing from network clients that talk it's language i.e. the clients that have installed the drivers for the printer. If you have the drivers, the LPR printing works fine for me at least when byte counting is enabled. It's just that a big part of the reason for me to have a print server is to be able to print directly from tablets and phones and such and that means having an lpd that supports input filtering so that the print server can do the conversion. The stock firmware lpd doesn't even have printcap.
I'm looking to see if I can use CUPS but the problem with that is that the only prebuilt packages I can find for big-endian MIPS are from Entware and for kernel version 3.4. That might require some wrangling and, anyway, it's a big leap from 2.6, so.... (If someone wants to provide some packages...)

 

[The Man They Call Jayne]

Why am I using the stock firmware? Well, quite frankly it still seems like less of a hassle, in a way. I'm looking to get a working setup. I'm not looking for a hobby. The stock firmware works for me, except for the printer driver requirement and that might be fixable. Or not. We'll see. I'll try to post updates if I can get anywhere with it.
I don't have the cross-compile environment set up. I don't want to start setting one up on Windows, if it even is possible, and I won't start running Linux just for that. I also don't want to compile firmwares as it is exactly the kind of thing that can suck up all your time and require a lot of work, if anything goes even slightly wrong.
As for existing firmware binaries, I don't think there are builds available for DSL-N14U or RT63365E. There are OpenWRT builds for RT-N14U but it looks like a sufficiently different device that it could be a cause for some serious headaches or bricking.
TBH, I might feel differently about a custom firmware, though, if a working prebuilt firmware was available for the device but I'm not looking to become a guinea pig for a long alpha-stage development project, if you get what I mean.
Though I'd like the printer on the network, I've managed so far without it and, at the end of the day, can do so in the future.

 

[The Man They Call Jayne]

I tried extracting some packages from Entware mipssf-k3.4 repo on an arbitrary directory on the device, along with a bunch of libraries listed as dependencies. I figured they wouldn't necessarily require much of an install and, if they ran, I could probably figure out launching a more complex software like CUPS. Well, whether busybox or something simpler like just invoking diff3, I ran into incompatibilities. After playing around for a bit, I managed to turn the -sh: not found into a bit more informative can't handle reloc type 0x2f from the linker and then I managed to graduate to FATAL: kernel too old using the linker from Entware. So, those packages are obviously a no-go. I'm sure most people already knew that but I thought I'd still try it.

Getting them to run would require obtaining a firmware with a version 3.4 kernel. Unfortunately in terms of firmwares, there's no clear support in anything. OpenWRT has some ramips builds but nothing for this particular chip so who knows whether they'd work. It's mt7620 build would be for RT-N14U, the router version. Likewise, Padavan firmware apparently also has a RT-N14U target. I haven't looked very hard but I suppose there isn't much support for xDSL modems in general. Obviously I have no need for the DSL functionality but having a completely different chip from a different manufacturer seems like something that would constitute a problem for a firmware.

So, at this point I'm looking wistfully towards the Optware-ng GitHub and wishing their packages were also built to big-endian MIPS as well as towards the Entware repository and wishing they had packages built for 2.6 kernel. DSL-N14U just doesn't seem to be popular enough a platform and architecture for this stuff (anymore?).

In order to get a generic (IPP?) print server, I either keep looking (and request) for those packages or set up a cross-compiler environment for that purpose. I suppose I could try to find another router or device for that purpose but the point of this exercise is that I have this thing and there's potential use for it. Of course, given that this device has a print server of some kind, that other device wouldn't actually have to support USB printers: it could simply run CUPS or something and share a generic format spooler queue which it would translate to ZjStream format and print on the printer on this device. It would be weird and screwy and inefficient to do something like that but, then again, who cares if it works?

But, yeah, I'll try to update here if there's anything to update. I might e.g. post the printer firmware upload scripts (startup and the "daemon") here once I'm happy with them. Maybe someone else also gets some use out of them.

In conclusion, any Entware and Optware packages built for big-endian MIPS and 2.6 kernel, etc., are gladly received. Specifically, CUPS and HPLIP and their prerequisites would be nice, if anyone has them. Also, the combination of ghostscript, foo2zjs(-wrapper) and nc (or similar) would IMO allow listening on a raw socket for a generic format like PS and translating it for the printer. Raw socket printing might not be that widely supported but it's still better supported on e.g. handheld devices than GDI drivers.

 

[The Man They Call Jayne]

Okay, here are the scripts. They should work.
I'm assuming the filenames are shown here..? If so, remove the trailing .txt.
If not, each file lists their own name.

Edit: The init.d script vanished. Let's see if I can get it uploaded too..
Edit 2: Putting it in CODE tags didn't work, splitting it in parts didn't work. Had to change instances of <something> inside it (in comments) to *something*. That worked. I guess they weren't properly escaped. Removed the post about CODE errors. The Oops! We ran into some problems. gave the following error (in case some admin is interested):
"Blocked aria-hidden on an [...] element because its descendant retained focus. The focus must not be hidden from assistive technology users. Avoid using aria-hidden on a focused element or its ancestor. Consider using the inert attribute instead, which will also prevent focus. For more details, see the aria-hidden section of the WAI-ARIA specification at https://w3c.github.io/aria/#aria-hidden."
Edit 3: Updated and fixed the scripts. Now it runs at startup..
Edit 4: Fixed some embarrassing mistakes on the scripts, now version 0.3. I hope I don't have to touch them again.

 

[The Man They Call Jayne]

So, I thought I'd give cross-compiling a go. Ended up with running Ubuntu 24.04 LTS on WSL. The integration with the Windows host just makes things easier. Going by tutorials and using old versions and "full" virtual machines becomes a headache very soon, especially when you realize the versions of SSL/TLS (etc.) they use are now deprecated by the whole world so a simple act of downloading stuff can become a bit problematic. Yes, I tried Centos 6.7 (the last one with any packages available) on VirtualBox and it didn't integrate the desktop. You get all the "fun" of having to set up an OS from scratch and it just was unwieldy to use. Nevermind that all the old dependency versions cause problems too. The reason for trying the old Linux in the first place was that it was referenced in GitHub firmware sources for DSL-N14U (antoniovazquezblanco/asus_dsl-n14u_gpl and smx-smx/asuswrt-rt) and there'd be less version-related problems. (There's a mips-linux-uclibc cross-toolchain for Gentoo (jlaunonen/mips-linux-uclibc) as well.)

For cross-compiling, you need a sysroot and there are a couple of options for it. You need the kernel headers and the system libraries and the C library, etc. The kernel headers are the easy part. You can get Linux kernel 2.6.22 sources from kernel.org and install the headers with env KBUILD_OUTPUT=/opt/mips-build/linux-headers O=/opt/mips-build/linux-headers/ ARCH=mips make headers_install (edit: or something like that) (some redundancy there but there is conflicting documentation and you want to be doubly sure not to pollute the system headers). You'll you get errors for getline since the scripts seem to use their own internal getline function. The solution is to do s/getline/getline2/g on scripts/unifdef.c. Then the headers install nicely.

After that you could channel mcilloni's "Cross compiling made easy, using Clang and LLVM" and simply copy all the lib/ and include/ directories from the device, add uClibc headers and get a full sysroot from it. You could also get the kernel headers and compile uClibc (maybe even uClibc-ng). Note, though that, according to crosstool-ng notes, "uClibc (not uClibc-ng) produces invalid binaries when compiled with GCC5 or newer (noticed at least on the i686 architecture)". That is not good unless you want to build and install an old version of GCC. (I haven't explored these options.)
In the end, I was lazy and simply downloaded and extracted toolchain/mips-linux-uclibc.tgz from antoniovazquezblanco/asus_dsl-n14u_gpl on GitHub as sysroot.

Since we're cross-compiling, the easy way would be to have LLVM/clang working because it cross-compiles natively. It would sidestep the whole issue of having to actually build and configure a GCC cross-compiler yourself. So, that's what I'm going with, if I can make it work.

I did consider doing the cross-compile on Windows. The huge upside would be not accidentally and silently linking the cross-compiled binaries with the system libraries and headers. Also, I am running a Windows host. Unfortunately, there are complications. First of all, no builds of newest LLVM 21.1.0 I could find had mips target built, though 18.1.0 did. Secondly, the lack of build tools and having to hunt them down and then set them up to work on Windows when everything assumes Unix is a headache I don't want to deal with. Fourth, symlinks. Most importantly, though, fifth, Linux kernel sources have idiotic filenames. Whatever one's personal opinion might be on case-insensitive filesystems, I think we can all agree that having files with only case difference in the same directory is pure stupidity. Compare that to e.g. someone writing functions in their program separated only by a case difference in their names. Just... No. (The Ubuntu installed LLVM version 18 by default, by the way, with a bunch more targets built.)

I made some symlinks to some (bin)tools (mcilloni) in a ${LLVM_BINS}/ directory I defined and was able to compile a static build of helloworld with clang -B${LLVM_BINS} -target mips-jayne-linux-uclibc --sysroot=/opt/mips-build/mips-linux-uclibc -muclibc -O3 -static -o hello-static hello.c, with and without -mcpu=mips32r2. The static builds of helloworld run on DSL-N14U but dynamically linked ones die with a segfault. That could be problem, nevermind that a single call to printf isn't exactly a high hurdle. Let's see how this goes.

 

[The Man They Call Jayne]

Ok. I tried writing, compiling and running a more complex program (attached), because you need to get rid of the controlling console for a daemon. It's not a problem when launched by system init, but if you run the script on the command-line, well, eventually you will log out and then the console goes away, terminating all programs on that console...
The program compiles and an earlier version of it actually ran when statically linked. (Don't know if it worked, though. Did not get that far.) This version, though, now segfaults. I'll have to check the memory stick file system. (Edit: I screwed up, see the below post.)
Methinks I need to build a proper sysroot. Not looking forward to it - especially since I have no idea what most of the options on the uClibc configuration are. Also, I'm no longer at all sure how I installed the kernel headers.
Edit: updated daemonic to the latest version, see the post below.
Edit2: updated it again

 

[The Man They Call Jayne]

Obviously I screwed up something both with the program and while compiling it. I forgot to put the symlink directory in path so it used the GCC system linker, etc., which is to say that the static builds do still seem to work fine. That might not be enough for building CUPS, though. Building sysroot may thus still be on the cards.

Checked the file system on the USB stick too and it was okay. Considered moving to ext2/ext3 but WSL doesn't make that easy and NTFS still seems to work.

This is the current full set of the scripts (daemonic on the post above as only 5 attachments are allowed) and some small tools for daemonization and logging. I found it easier to just write my own, simply compiled, simple versions than to start looking at the millions of similar existing tools and how they are compiled. Also, why not, right? I'm lazy so I haven't actually tested these versions yet. So YMMV.

I think some more signals may need to be handled in daemonic and that it could actually be better to install dummy handlers (or re-enable the signals) rather than ignore them, because exec*() inherits the ignore state for signals whereas all the handlers are reset to their defaults. So, if someone were to use the tool and expect to receive signals like SIGCHLD (e.g. after themselves forking)...

It might actually be worth it to rewrite the daemon in C in order to simplify daemonization and logging and to just keep everything in one place and to only rely on tcapi and libc rather than a bunch of external factors. You could read tcapi with popen()/pipe() and fscanf()/getline() and do everything else inside the program itself. E.g. a lot of the string handling is due to having to call external programs (and allowing customization merely by being a script).

Edit: updated axe

 

[The Man They Call Jayne]

Diving a bit deeper, I think the following means that both the system and the added (Optware?) binaries on DSL-N14U are compiled with -mcpu=mips32r2 and that they are O32 binaries (or it would say N32), which might be the default for mips and mips32r2:

$ file busybox --brief
ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped
$ file openssl --brief
ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, interpreter /opt/lib/ld-uClibc.so.0, stripped

What's fun is that interpreter part. That's a specific loader (linker) being forced. Apparently you can specify that in the source code with const char interp_section[] __attribute__((section(".interp"))) = "/opt/lib/ld-uClibc.so.0";. It does seem to work, because when I specified a non-existent loader, I got not found. Neither loader on the device seems to work for our dynamic links. However, I figured there's a chance you could make dynamically linked stuff work by cross-compiling a loader (somewhat) matching the compiler, namely the linker from the 18.1.3 version of LLVM. There are instructions at https://llvm.org/docs/HowToCrossCompileLLVM.html. Anything to keep things easy and avoid building my own sysroot, I guess.

One of the prerequisites is missing from the sysroot, though, namely libz. I got the 1.3.1 version sources from zlib.net and set up some environment variables, PATH to LLVM binaries, wrappers and symbolic links, SYSROOT=/opt/mips-build/mips-linux-uclibc/, CFLAGS=-march=mips -mcpu=mips32r2 -muclibc, TARGET=mips-jayne-linux-uclibc (possibly more related to the LLVM build). Configuring Zlib is easy: CHOST="mips-linux" CC=mips-linux-gcc ./configure --prefix=/opt/mips-build/mips-linux-uclibc but you have to add --undefined-version in the LDSHARED linker options at line 235 of configure in order to build the shared library. After that, the Zlib shared library gets built. Of course, I have absolutely no idea whether the resulting libraries work but let's just assume so.

Of course, that isn't enough to build the LLVM linker. Using set(CMAKE_C_COMPILER mips-linux-clang) and set(CMAKE_CXX_COMPILER mips-linux-clang++) gets me further but the build grinds to a halt with libstdc++ version must be at least 7.4.. The sysroot only provides libstdc++.so.6.0.10. So, either use an older LLVM version that is happy with that or build a new sysroot. I'll probably try with an older LLVM version first.

Updated axe and daemonic in above posts.

 

[The Man They Call Jayne]

Using set(LLVM_FORCE_USE_OLD_TOOLCHAIN true) gets you past the version problem, though now we require libatomic. (Undefined references to functions like __atomic_is_lock_free should be resolved by linking to libatomic, which is usually installed alongside libstdc++. )
Setting set(CLANG_DEFAULT_RTLIB compiler-rt) to get --rtlib=compiler-rt on CFLAGS gets you past undefined references on libatomic, but then it wants the library itself. With set(HAVE_CXX_ATOMICS_WITHOUT_LIB true) and set(HAVE_CXX_ATOMICS64_WITHOUT_LIB true) you get past that (and 64-bit undefined references).
Now there's "just" a couple of CMake deprecation warnings, LLD error for get_property could not find TARGET clang-resource-headers (that goes away when enabling clang as a project too) and a CMake warning about Using std::regex with exceptions disabled is not fully supported. That gets the configuration done.
Cool. Now the build phase ignores everything and runs /usr/bin/cc. Oh great.

 

[The Man They Call Jayne]

Setting CC and CXX on environment to match our CMake definitions gets me the right compilers. Makes me wonder what is the point of having those definitions in CMake if they just get ignored. (Are they using the Linux model of development where things aren't fully coordinated so that nothing really works like they're supposed to and you always have to fiddle badly-documented switches in order to get things to limp along?)

In any case, now I can compile libcxx, libcxxapi, libunwind and compiler-rt, I think. I'm not sure they have separate install targets, though. Of course, now using the old libcstd++ comes back to bite us with a bunch of missing std:: templates in trying to compile clang.

So... Do I want to compile a new libcstd++ in order to get lld built in the hopes that using it fixes dynamic linking? Or do I want to try to build and scrape up a new sysroot in the hopes that it works better with the linkers on DSL-N14U? Even there I have options like would uClibc-ng work better or would it be just another incompatibility? Or do I just try to build statically-linked CUPS?
What sucks is that none these options are actually guaranteed to work, so there isn't even a choice for a-lot-of-work-but-at-least-it'll-work. In the end I could end up exploring every choice and still end up with none of them working. I think the fastest possible way to get this done is to just try building CUPS.

It does occur to me that I still have an old Soekris net4801 somewhere. The current version of NetBSD still supports i386 target so I could just install it and run CUPS, etc., on it. Given that it would all be current versions (and x86), you could compile all sorts of things for it a lot easier. Using it would feel like quitting but it would work. Of course, it only has a USB 1.1 port on it so it might sort of make sense to keep the printer connected to the DSL-N14U on only do the IPP (PS, PDF?) translation on the net4801, though sort of not. If nothing else, I've already somewhat demonstrated that you can run stuff on DSL-N14U factory firmware, at least as long as you link your executables statically and as long as you have DM installed (or as long as ASUS still provides a way to install it). I think this is the route to go if I give up on the DSL-N14U. For now, though, we'll see.