It may be suboptimal, but it's a pain to have to rebuild everything
when some of this changes.
Also, no clue why there seems to be two different code paths for
serializing a tx...
A new version of genRct takes the mixRing as parameter, instead
of the inPk. inPk are part of the mixRing, and it is cleaner to
pass the mixRing data than to fetch it from the RingCT code.
A new version of decodeRct also returns the mask.
Also, failure to decode throws, so errors are properly detected.
This lets my gcc picks those instead of the generic template
where appropriate (and then fail since std::vector<something>
does not have a serialize method.
I think, in this context, dynamically linked builds make sense
only for native builds, not these builds that target arch
families to produce portable binaries.
* some re-org of sections to make things more concise
* dedicated section for installing from packages vs building from source
* for Windows, instruct to run the top-level makefile targets,
because I don't see any reason not to -- advanced users
will look into the makefile and find the cmake command there
if they need to.
* for Windows, instruct to install *-toolchain meta package
which includes expat
* added some context info here and there to aid -- I tried
to clarify things that confused me, e.g. Windows build is
cross-compilation to be precise; motivation for targets
that are meant for generating portable binaries as opposed
to binaries optimized to host CPU.
This reverts commit ecd0f2dde7.
These targets that are not native builds. They are for builds
portable within processors of a given family.
'make release' used to not work to build a native build on ARM, but that
has been fixed. These targets are unrelated to the native build.
This reverts commit 8623492150.
Let's restrict ARCH to values accepted by -march to keep things clear
and consistent. ARCH is -march, with only one exception: a value of
"default" indicates to not pass -march at all.
It is not correct to do so, because ARCH should only take values
supported by the -march argument, with the exception of 'default'
which denotes not passing -march at all.
ARCH defines the target architecture for builds that are intended to be
portable to other machines.
This gets rid of bitmonerod.exe's dependecy on libwindpthreads-1.dll in build
on Windows on x86_64 (via MSYS2 default toolchain). With this patch all DLL
dependencies are on DLLs in c:\windows\system32.
