Apple has significantly changed the way `perl` is structured in macOS
Mojave/10.14, which is due to ship stable this month. The `perl`
restructuring has been an issue for a while but I recently obtained
confirmation from Apple the changes were intentional & consequently not
something that was going to be walked back before Mojave reaches its
stable release.
As of 10.14 the Perl headers are moving inside the SDK, instead of
residing in `/System` directly. There's a flag to tell Clang to look
inside the SDK without projects having to explicitly locate the SDK &
fiddle with the location themselves, which is `-iwithsysroot`, and
that's what `perl` outputs now when `configure` checks
`perl -MExtUtils::Embed -e ccopts`:
```
-g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -fstack-protector -iwithsysroot /System/Library/Perl/5.18/darwin-thread-multi-2level/CORE
```
The latter bit of that was previously
`-I/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE`. The
problem here is that `configure` filters out flags that start with a
lowercase `i` and consequently the Perl elements fail to build. This
tiny patch fixes that issue, restoring Perl support to `irssi` when
built on macOS 10.14.
A side-effect of 8deb618 is that `/save` may replace configuration files
that are symlinks with regular files. Fix this by resolving all
symlinks before renaming the temporary file.
Fixes#888.
Previously we showed that there was a topic set when using /topic, just
an empty one. This was different than how we show such topics when
initially joining a channel. Now we say that the topic is unset in both
cases.
Don't use errno if it is not set and show the default error message
instead. This prevents messages like "SSL handshake failed: Success"
from being shown.
This is modeled after glib's g_file_set_contents. It doesn't use that
function directly because the writing is done with GIOChannel
streaming-like writes and g_file_set_contents expects the whole thing to
be in-memory.
Main differences with g_file_set_contents:
- complete lack of win32 special casing (cygwin/WSL should work though)
- no fallocate() (linux only, but we don't know the size upfront, anyway)
- always calls fsync (glib skips it on btrfs or when not overwriting)
Other than that, it's the same old mkstemp + fsync + rename.
This is a simple change which might fix#130
The lookup_servers are also disconnected if the lookup/SSL handshake doesn't succeed in time. I'm not perfectly sure if this is the master fix but it does seem to be an issue that servers can be stuck in lookup, especially for SSL. See the issue for a reproducer
