Now ngIRCd requires at least GNU autoconf 2.61 and automake 1.10, the
requirements of commit 67e882d4 have been too restrictive:
19.2 67e882d4 now
---------- --------- --------- ---------
autoconf >=2.50 >=2.67 >=2.61
automake >=1.6 >=1.11 >=1.10
The tools required now are supported by Debian GNU/Linux 4.0 "Etch",
RedHat Enterprise Linux 5, and Mac OS X 10.6.x for example.
I read the changelogs of autoconf and automake, and I think ther's nothing
that prevents it from working with these older versions; and we don't want
to force users to upgrade without real benefits.
Please note: the recommended versions are still autoconf 1.11.x and the
most recent autoconf release that works with automake 1.11.x!
We don't expect the GNU'ish behaviour of of malloc() and realloc() and never
implemented the replacement functions rpl_malloc()/rpl_realloc() -- so these
test result in linking failues on systems that don't have a GNU'ish malloc()
and realloc() even though we don't require it!
Introduced by commit 47ad9afc.
If gai_strerror() isn't available, use a macro that simply returns
a static error message (regardless of the real error code).
For example, GNU libc 2.0.7 doesn't implement gai_strerror().
Don't use isdigit() function any more, because it only checks the
first character of the variable value and because it doesn't know
about the minus sign which is required e.g. for "Group = -1".
Now the ngIRCd release/version number is deduced from the "current"
annotated GIT tag; see "git describe --help" for details. This is the
same scheme the Linux kernel uses and gives much more details version
numbers for interim releases and inofficial source archives generated
using "make dist".
Please note: the version number is only updated it the autogen.sh
script is run; so after pulling in and pushing out new commits, you
should run ./autogen.sh!
Allows to defer/queue signal processing for execution on the next
event dispatch call, i.e. we can perform any signal action in
normal, non-signal context.
Example uses:
- Reload everything on HUP without writing a global "SIGHUP_received"
variable
- Dump status of internal Lists on SIGUSR1, etc.
from bugzilla #105:
"ngircd-16 works great under openbsd4.7/i386, but it segfaults on
openbsd4.7/amd64."
Caused by missing function prototypes and the resulting truncation of
pointer to int.
Lets try to catch these bugs during compilation instead of SIGSEGV.
This solves warning messages of autoconf on e.g. FreeBSD 8:
configure: WARNING: netinet/ip.h: present but cannot be compiled
configure: WARNING: netinet/ip.h: check for missing prerequisite headers?
dpkg-shlibdeps: warning: dependency on libnsl.so.1 [..]
(they use none of its symbols).
As shown via commit 2b14234abc
(dpkg-shlibdeps: warning: dependency on libnsl.so.1) and the
following revert of that commit, we cannot simply drop
the AC_CHECK_LIB(nsl). Although -lnsl is indeed unneeded
when glibc is used, some platforms (e.g. Solaris) need it.
Use AC_SEARCH_LIBS instead to only link when the library exports
a particular symbol.
Test for sockaddr_in.sin_len and initialize it to the correct value
which some systems (notably Mac OS X) require.
Note: this code path is only relevant when not using getaddrinfo().
Both getaddrinfo() and getnameinfo() are now used always when available, and
not only when compiling ngIRCd with support for IPv6.
This not only enables ngIRCd to handle multiple addresses per hostname when
compiled without support for IPv6, but fixes binding ngIRCd to IP addresses
on Mac OS X (and probably other BSD-based systems) as well: these systems
require that sockaddr_in is zeroed out and sockaddr_in.sin_len is set to
sizeof(sockaddr_in) like that:
src/ipaddr/ng_ipaddr.c, line 54:
assert(ip_str);
+ memset(addr, 0, sizeof *addr);
+ addr->sin4.sin_len = sizeof(addr->sin4);
addr->sin4.sin_family = AF_INET;
But this would break all the systems not using sockaddr_in.sin_len, for
example Linux -- so we assume that all these systems provide getaddrinfo()
and use that for now.
This patch fixes --with-openssl and --with-gnutls and enables both to
accept path names, so that you can use "./configure --with-XXX=/path".
All the other --with-XXX parameters support this already.
Starting with GNU automake 1.11 "AM_SILENT_RULES([yes])" is available to
make the build process less verbose ("Linux 2.6 style") which helps to
spot warning and error messages.
So we use it if it is available.
