OK, I have looked into this in more detail.
On the plus side:
Providing I have static libraries available, I can use static linking.
This makes binaries that run on buster and bookworm, at the cost of being slightly larger.
On the negative side:
No libmosquitto.a, so I would have to build it, and that means I have issues with SSL as described above.
In addition, one of the libraries I use heavily is third-party, (the excellent BASS library, see http://un4seen.com) and is not (and I'm guessing won't ever be) available as a static library.
Since I am NOT making binaries for distribution outside (and in most cases, am happy to release source via github), it would be simpler to reinstall bookworm on the affected machines (and the others).
Most of them are headless, so are Lite plus some runtime dependencies (like mosquitto) plus my code, this is probably less painless.
I have bookworm 32-bit lite running on a Pi ZeroW, and Pi 2 machines (anything lower than Pi3 [except 02W] doesn't get a full-blown GUI), so I know that all works, and having resolved some bookworm touchscreen issues (hardware issue), I think that really is my best option.
I have four "backbone" machines (dns/dhcp server, internal http server running some internal sites, a PLEX media server, and an external-facing NGINX web server) that absolutely have to run, and the most important, the dns/dhcp one is already upgraded. The others should be relatively easy, although I may have to fight with PLEX to register the server again.
In my searching, I was pointed at something that uses symbol versioning (a feature in the assembler, a psuedo-op .symver) to change a requested symbol from, say, malloc@GLIBC_2_34 to malloc@GLIBC_2_13.
Obviously, you'd have to apply this to all of glibc, and there are issues with libstdc++ which I need to look at, but it's on my list for later consideration, but for now, I'm taking the path of least resistance (even though, as any ST:TNG fan knows, resistance is futile!).
On the plus side:
Providing I have static libraries available, I can use static linking.
This makes binaries that run on buster and bookworm, at the cost of being slightly larger.
On the negative side:
No libmosquitto.a, so I would have to build it, and that means I have issues with SSL as described above.
In addition, one of the libraries I use heavily is third-party, (the excellent BASS library, see http://un4seen.com) and is not (and I'm guessing won't ever be) available as a static library.
Since I am NOT making binaries for distribution outside (and in most cases, am happy to release source via github), it would be simpler to reinstall bookworm on the affected machines (and the others).
Most of them are headless, so are Lite plus some runtime dependencies (like mosquitto) plus my code, this is probably less painless.
I have bookworm 32-bit lite running on a Pi ZeroW, and Pi 2 machines (anything lower than Pi3 [except 02W] doesn't get a full-blown GUI), so I know that all works, and having resolved some bookworm touchscreen issues (hardware issue), I think that really is my best option.
I have four "backbone" machines (dns/dhcp server, internal http server running some internal sites, a PLEX media server, and an external-facing NGINX web server) that absolutely have to run, and the most important, the dns/dhcp one is already upgraded. The others should be relatively easy, although I may have to fight with PLEX to register the server again.
In my searching, I was pointed at something that uses symbol versioning (a feature in the assembler, a psuedo-op .symver) to change a requested symbol from, say, malloc@GLIBC_2_34 to malloc@GLIBC_2_13.
Obviously, you'd have to apply this to all of glibc, and there are issues with libstdc++ which I need to look at, but it's on my list for later consideration, but for now, I'm taking the path of least resistance (even though, as any ST:TNG fan knows, resistance is futile!).
Statistics: Posted by SteveSpencer — Sat Apr 27, 2024 12:45 pm