GCC 15 is not released yet and is scheduled for April/May 2025.
We now have a ./configure check. If a func() declaration is interpreted
as meaning 0 arguments, so C23 style, then we now add -std=gnu17 to
CFLAGS. If not, then we don't set an explicit C standard version.
Closes https://bugs.unrealircd.org/view.php?id=6495
Ignore these for entire src/dns.c.
Quoting https://github.com/c-ares/c-ares/pull/732#issuecomment-2028454381:
"Those deprecated functions will remain available until there is an ABI
break, which honestly will likely never happen. It's more to encourage
integrators to move to the more modern functions."
Also, keep in mind that several of these 'deprecations' happened in early 2024
while the new function was introduced in March 2020, like for ares_getaddrinfo().
That isn't all that long ago, only 4 years. So we would need compatibility code
for both the old and new function for a while.
So: we can look into that in some major new UnrealIRCd version, nothing urgent,
and perhaps by then it is long enough that we don't need the fallback to older
functions.
for this is that system argon2 is often much slower (2x slower
on Ubuntu and Debian, for instance), which is not good.
You can still use the system library with the configure option:
--with-system-argon2
Actually I presume 'make install' properly removes the file first
before installing a new one, but.. not entirely sure. Better safe
than sorry.
We have had new reports of someone who had the original UnrealIRCd
crash while building the new UnrealIRCd. Similar to what we had
a few years ago, which was caused by a 'cp' instead of an rm+cp.
This because with simple cp the existing file contents is changed
and the processes holding the .so file open (usually mmapped)
suddenly have the new .so file loaded in effect, which causes a
crash whenever next function is called in that library.
We now rm explicit before 'make install' so running processes
simply have that fd point to a deleted file, which is fine.
Bram Matthys