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.
* moved dev to version 3.1.1
* introduced n2n-portfwd tool
* moved port-forwarding source to tool
* adjusted tiny things, seemingly works with ./configure's --enable-miniupnp and --enable-natpmp
* adjusted for Windows
* wished for better typing skills
* applied some finishing touch
* typo
* Fix cmake informational log messages
* If the correct library name is used find_library works better
* Re-enable remaining find_library users
* Reorder cmake to make libpcap detection work
* Convert zstd feature to default disable
* All autoconf test use one standard template
To simplify the testing, cross-compilation and repeatable build process,
no configure options are automatically probed for - they all default to
off and are all using the same template.
The --with-x options should be deprecated and replaced with --enable-x
because there is no syntax checking for --with options in autoconf.
There are still some differences between the config options, but this
should provide a starting point.
* Remove unused code from the autoconf
* Remove warnings from default build
* Avoid calling port mapping functions if none are enabled
* Start with all builds in neutral config
* Add more missing code guards
* Adjust code guard location to placate cmake
* UPnP port redirection is supported.
* compile fixes
* compile fix
* optimize reconnection code
* prepared upnp threadification to counter main loop stall at supernode change
* NAT-PMP port forwarding support, temporarily merge codes to resolve conflicts.
* make compile fix
* prepared threadification in more detail
* adopted threadification to new file setup
* cleaned up
* renamed functions and data structures
* fixes
* differentiated between miniupnp and natpmp and added corresponding lib support to makefile
* name
* commented unused header includes
* comments
* license
* fixes
* fixes
* fixes
* NAT-PMP is already available.
* added CLI parameter to disable port forwarding if required
* preliminary made use of multithreading
* adjusted log level
* added man page documentation
* def'ed conf
* made pmpnat adjustments
Co-authored-by: fengdaolong <fengdaolong@gmail.com>
* Allow an autobuilder with no access to private key material to create testable packages
* Initial dpkg build - will need helpers installed to work
* Start adding required dpkg helpers
* Tweak package artifact names
* Add a windows 'package' builder
* Ensure prefix path handling deals with current directory change when descending to tools dir
* The tools makefile currently only needs the SBINDIR path to install properly
* Add a macos 'package' builder
* Remove unused configure variables
* Without commit history, some of the automatic version numbering will fail
* Add an rpm builder
* Need to set the env var for the rpm build before we change our working dir
* Allow gpg signing to fail for generating test rpm packages
* Unfortunately the rpm spec file hardcodes some path assumptions, so we need to use hacks to work around them
* Return to the top dir before moving things around
* A small change to make actions re-run the pipeline
* Name this workflow file with a nicer looking name
* Provide a minimal reimplementation of our autoconf, to try windows builds
* Try building with windows
* Fix thinko in spelling
* Ensure shell script runs inside a shell
* Add a hack to aid include discovery
* Just keep adding tech debt...
* Assume that we will have slashes in some of the replacement strings and avoid that char with sed
* Restore one slash
* Hack around the tools makefile interdependancy bug
* A correct cflags include hack for each compile dir
* Ensure we link against winsock (note, even though this says 32bit, it should link the 64bit library ... I think)
* Bad link ordering if we dont use LDLIBS
* Remove unused make variable
* Remove makefile duplication using inheritance (this does mean you can no longer cd tools; make, but must do make tools)
* Add missing library for win32
* Show OS variable
* Make hack autoconf more robust for tests on non gitlab runners
* Remove no longer used substitutions from hack autoconf
* Add missing include path to tools under win32
* Build the win32 subdir when the compiler is Msys
* The different subdirs have different dependancies
* Ensure we can find the include files
* Fix library link ordering
* Ensure the tools dir can find the special win32 lib
* Deal with the differing basic type sizes on both linux/64bit and windows/64bit
* Document the steps to mimic the github windows/mingw build locally - to allow for simpler debugging
* Ensure branch name in instructions matches my test branch name
* Clarify the shell needed to build with mingw
* Since the makefile depends on knowing the OS, raise a fatal error if we cannot determine this
* Handling different compile environments is hard.
- Linux: sane and reasonable results for both uname -s (=Linux) and
uname -o (=GNU/Linux)
- Windows/Mingw: insane results for uname -s
(=MSYS_NT-$MAJOR.$MINOR-$BUILDNR) but sane results for uname -o (Msys)
- Macos: sane results for uname -s (=Darwin) but does not support
uname -o at all
* Revamp the way that Mingw is detected
* Avoid attempting to generate gcovr report when running under windows
* Whoops, isolate the right step
* Fix spelling mistake
* win32/Makefile: Remove unused setting and add comment
* ensure that all win32 includes use the same expected path
* Allow simpler cross compilation by letting configure pass the CC and AR environment through
* Avoid multiple '_CRT_SECURE_NO_WARNINGS redefined' warnings
* Convert to a consolidated CONFIG_TARGET variable to select any different compile options
* Use the more generic printf defines to avoid warnings on mingw
* Update mingw build docs
* English better for reader happy make
* Address a number of mingw compiler warnings
* Fix Visual C compile
* Be sure to document some of the hacky nature of the mingw build
Hamish Coleman
Logan oos Even
Luca Deri
Logan007
emanuele-f