This may impact builds on Debian 8, but that version has been out of
support for over three years. I didnt test it, but since using this
helper is the preferred method it may actually help builds on older
versions.
When building on win32 systems, simply add the win32 specific functions
to the libn2n.a, which simplifies the commands needed.
By moving the win32 source code into the src directory, the source code
is better consolidated.
If there is a way to turn off the mingw insistence that it will rewrite
the filename it was given in the "-o" options, I have not been able to
find it. I could easily handle all the moves or renames at the end of
the build process if I could turn off this feature. Especially since it
means that make often thinks that the file has not been built (the
filename that make knows about is not the file that actually gets built
by the mingw gcc, so the if-newer tests that make applies will always
fail)
It looks to me that the correct way to address this build wrinkle is
simply to add the win32 functions to the libn2n when building a win32
output, then there is no additional magic library juggling required for
the win32 case
There is a minor change - after this, the macos man pages are also
installed into the /usr/local PREFIX. This seems like the correct
location to me.
Longer term, the usual autotools process of installing everything into
/usr/local should be used. Files installed in /usr should be done by
a package management tool, so this default makes sense to use.
Not all struct sockaddr are going to have the sa_family as their first field.
Since there is a named structure member, we can simply use that and let
the compiler sort it out.
This fixes a bug with at least FreeBSD and allows us to remove the
special case for Apple.
Some versions of autoconf (eg, the one included with Ubuntu 20.04 -
which is GNU Autoconf 2.69) will produce a configure script that
requires finding the install-sh script in either a short list of parent
directories or the defined AUX_DIR (This new requirement was probably
triggered by the use of the cross-compile features in configure.ac)
Newer versions flexibly identify which of the support scripts are
actually needed (from the list of config.guess, config.sub, install-sh)
and only check for those ones that are needed.
When the `./autogen.sh` runs `autoreconf -i`, it should have copied the
required aux scripts, but for some reason this is not happening.
Once we are not supporting the older autoconf, we should revisit this
config option as these auxiliary scripts should normally not be checked
into a version control system, for the same reasons that configure
shouldn’t be. For now, we ensure that all three scripts are available
and we have set the AC_CONFIG_AUX_DIR() to point to them
If the older autoconf is used, it will report the error:
configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."
Which is included here for search engines.