* support linux l2 bridge
* unified timeout name
* typo
* minor code style adaptions
* feature define
* feature define
* feature define
* feature define
* added hint to bridging to help output
* added hint to bridging
* drafted bridging documentation
* added bridging hint
---------
Co-authored-by: Logan oos Even <46396513+Logan007@users.noreply.github.com>
It looks like the github windows build environment is not correctly
inheriting environment variables. Which is strange, as that has not
been changed with the recent updates. Include the vars directly as a
workaround (and plan to refactor later)
It is difficult to maintain one build system, let alone two - especially
if one build system is known to be better maintained and the other build
system continues to be used - with bug and feature requests raised
against it.
The maintainers are aware that there are people using the CMake system,
but believe that the extra maintainability of only having one build
system, combined with the knowledge that the current CI system
demonstrates that all supported architectures are working with the
Makefiles make the use of these Makefiles a more sustainable direction.
* added Windows support to n2n-route tool
* fixed includes
* more include fixes
* one more include addition
* more compile fixes
* wish I had a working Windows VM
* fixed some more Windows compile errors
* considered Windows-specific lib linkage
* promised to never code OS specific tools again
* removed invisible invalid characters
* where to get if_idx from
* retrieving interface index for route
* bracket...
* one more bracket...
* added optional gateway parameter to user-defined routes
* clarification
* clarification
* Windows needs special network init
* adapted waiting-for-key
config.guess now has support for:
* musl
* aarch64eb
* riscv32, riscv64
* loongarch32, loongarch64
And many other new stuff. Bump config.guess for that
This is a only exception while all other libraries are dynamically
linked.
The "TODO" does not make any sense as libcap provides both dynamic
and static libraries.
There is not reason to explain why it needs to be statically linked
'especially' as dynamic linking works very well.
Then just make it dynamically-linked by default, which also matches
the behaviour on autotools.
Compiled and tested on aarch64, no errors found.
Signed-off-by: Tianling Shen <i@cnsztl.eu.org>
