For the SBBS binaries, set @executable_path and
@executable_path/../${LIBODIR} so they can all be in one dir, or
they can be in the build output dirs and still work.

For utilities, set to @executable_path and
@executable_path/../../${LIBODIR} for the same reason.

With this, we shouldn't need to fiddle with DYLD_LIBRARY_PATH

Remove the -E linker flag.
This should not be needed anymore, and isn't supported on macOS.

Have shared libraries include their full path.
This allows linked dylibs to work from where they were built, so
as long as you don't build the binaries on a CI machine, then try
to run them on a users machine (*cough*), it'll work out.

Use the correct rpath argument format on macOS.
It uses -rpath, not --rpath.

This technically fixes issue 137 which specifically asked for
"backslash", but backspace (^H) and tab (^I) along with CR (^M)
still do a different thing than they do on Atari keyboards.

Further, CTRL-Q and CTRL-S are used by SyncTERM for Quit and Menu
respectively, so someone expecting all the Atari "stuff" to work
will still be disappointed.

This is a general problem with non-PC emulation (ie: Prestel, Atari,
and Commodore) that really needs some kind of general solution.

Specifically, ARROW POINTING UPWARDS THEN NORTH WEST

Kind of a shot in the dark here: Max (WESTLINE) is reporting HEAP CORRUPTION
debug assertion in websrvr.dll. In the 2 instances reported, a long (336
char) JSON "query value" was logged by apparent spam-bot trying to create a
a new user account ("send-me-free-stuff" is one of the JSON properties).

JS_NewStringCopyZ() can return NULL in a low memory situation, though I don't
know that explains possible heap corruption.

This way, when an error occurs, it will at least terminate the
session instead of requiring you to disconnect yourself.

This partially addresses issue 174, assuming it's actually telnets.

Apple GNU make treats unescaped # in variables as starting a comment.
But GNU grep >= v3.8 will spew a warning with an extra backslash there.

GNU grep >= 3.8 complains and it's highly confusing.
Thanks for sticking with it Dan_C.

Way faster with release builds. :D

Presumably, this is broken because I cross-compile.

...But Win64 isn't.  It crashes somewhere in the decoding function,
and I have no idea why... it doesn't seem to be because of the thread
thing.

I assume it's because of the cross-built win64 libs, but I can't really
be sure. :(

So, we can't use threads with these libs. :(
This is going to be a pain to build these due to the dependencies.

This can't happen, and it breaks the thread stuff.

Just statically link it here, I'm not interested in adding another
DLL into the archive, and there's no good reason to NOT support it.

An alternative to using PPM, relies on libjxl from the JPEG.
JPEG XL is a superior modern format that supports both lossy and
lossless compression and does an excellent job at both.

The format also supports multiple frames (ie: animation), so can
be used for Cool Stuff in the future.

As an example, a large image that is 130MB in PPM format is only
6.8MB in JPEG XL format using the default quality settings of
ImageMagick (whatever they are).

All the scripts I used this in previously had a read_apc() function.

Commands are added.

This allows us to avoid needing a large number of extra libraries,
and it appears sRGB (ie: what we want) is the default anyway.

These are useful for trouble-shooting/experimenting with file share modes
and region locks, so make them easier to build.

Order of options no longer matters.

This also supports static linking for OSs that don't have sane ways
of sharing libraries system-wide.

With this, my fancy intro is quite usable...

Uses libjxl, makes the video demo more possible.

Does not yet have a feature test sequence, documentation, support
in the gmake build system, runtime linking, etc.  Just a quick
hack.

It also looks like I can parallize the decode, should should also
help things out.

It was badly broken, especially with large files... we now don't
try console.write() unless there's enough space in
console.output_buffer_space.

On my system (debug build of Synchronet), the most I can push through
console.write() over telnet is about 1.9MB/s.  My release build of
SyncTERM can consume about 4MB/s of string data, so Synchronet is the
choke point in my setup here. (SSH is much worse)

My super-cool demo thing ends up needing about 90 seconds to preload
all the cache stuff, so it's simply not useable, even locally. :(

If I use client.socket.send(), I can unlock the Synchronet throughput,
but I can't remember if client.socket is the passthru socket with SSH
or not... and there's no way to synchronize the socket with the console
at the end of the send (console has flush(), Socket doesn't, and even if
it did, it wouldn't flush through to the output buffer).