the script won't create another file (run-nonroot previously)
and instead carry out environment setup itself for the binary
links pointing at it - it's more readable and smaller this way
rework mips32r2.py file copy def - may be useful in other files,
eventually transport this functionality to base.py (!?) later
on, after this branch is merged to master
The following applies to mips32r2_uclibc_glibcxx_dyn target,
only:
- libstdc++.so* tc libs are copied to INSTALL/lib/<full-arch>
- i.e. there is an example showing how to copy other libs from
the toolchain to supplement the installation files (in case
they are found to be missing on a target machine)
- if target already supplies libstdc++.so*, copied ones will be
preferred for kiwix-tools binaries (when run from a non-std
installation directory on the target), drawback in this case
is extra space occupied by the lib, but the gain is less
hazzle on target boxes that lack libstdc++.so*
- comment or modify the lines in mips32r2.py accordingly to the
setup of your mips target
added
mips32r2_uclibc_gclibcxx_dyn, (preferred atm, tested on prod hw)
mips32r2_uclibc_gclibcxx_static
targets (shared) and renamed previous uclibc ones to
mips32r2_uclibc_uclibcxx_dyn,
mips32r2_uclibc_uclibcxx_static
for clarity (i.e. non-shared, pure ones)
reworked builder classes to use inheritance of properties and
methods (instead of copying boiler plate code)
mips32r2_uclibc_gclibcxx_dyn target compiles and tested to run on
production targets such as avm routers modified with a freetz env.
See cm8/freetz@41d97c3789 for one of
many possible projects to build a working toolchain with. In short
- git clone
- umask 0022
- make menuconfig (choose expert, disable toolchain download and
let the toolchain/make scripts built a gcc-5.x one, do not forget
to set FREETZ_LIB_libuClibc__WITH_WCHAR=y)
- read the commit message for further info on long double math
peculiarities
- tested here with 0.9.33.2
Remember that swap will need to be running on the box, or else
kiwix-serve is likely to quit with "invalid lzma stream in cluster"
errors (if memory is too low).
If the box lacks library support such as libstdc++.so*, you can
copy them from the target toolchain libdir over to
BUILD_mips32r2_uclibc_gclibcxx_dyn/INSTALL/lib if there are
unsatisfied dependencies at runtime. (Which libraries need to be
supplemented this way depends on your firmware and/or freetz
configuration).
Another issue is the execution in non-standard installation
directories. LD_LIBRARY_PATH env needs to point to "our" lib
directory. If you tar INSTALL/ dir, transport the result to
an embedded device, untar and wan't to run from there, it is
best to wrap all the elf binaries with a shell script that
correctly sets LD_LIBRARY_PATH. This step has been automated,
but needs testing, see
kiwixbuild/patches/fixenv-run-in-nonstd-installdir.sh
for details.
This fixenv script is copied to INSTALL/bin during the
build and it should be run on the box, if kiwix-tools is to
reside in nonstd location (i.e. if files are not installed
or installable to /bin, /lib or their usr/ pendants).
Feel free to improve on automation of the necessary setup
steps to make mips port build and deployment easier.
ATM the uclibc toolchain buildable by freetz (see
https://github.com/freetz/freetz) is used. When
configuring freetz make sure
FREETZ_LIB_libuClibc__WITH_WCHAR=y
FREETZ_BUILD_TOOLCHAIN=y
are set, so uClibc++ as part of the toolchain is built with wchar_t
support. Eventually root_path definition in mips32r2.py (hardcoded
for now) needs to be adjusted. Some (all?) prebuilt, downloadable
tcs of the freetz project do not have wchar support in uClibc++ (but
uclibc does).
KNOWN PROBLEMS:
xapian-core currently does not compile with uClibc++
The target mips32r2_dyn is tested to fully compile, but untested to
run. Target mips32r2_static reaches kiwix-lib and fails linking
pthread. For further details see the comments in #48.
Some known problems:
* hardcoded values of icudt58l in some dependent packages
unnoticable during compile, but will affect runtimes
* the libdir name problem
x86_64-linux-gnu <> mips-linux-gnu
* pthread linking problem when compiling kiwix-lib statically
may be a meson issue, since it somewhat claims to properly
handle pthread linking in cross-compile situations; there
are some url links in #48 laying out a proper workaround.
The CI is using ubuntu artful and the deb package is compiled with another
compiler that gcc-4.8 (used in other project CI).
As we compile everything with gcc-4.8, we must compile our own ctpp2.
We build with gcc-5 because of zimSplit using ofstream.swap method.
Latest version of zimSplit doesn't use it anymore so let's compile
everything with default gcc.
See openzim/zim-tools@a959609839
We also explicitly set the list of package to install per job, so
less packages are installed.
If the `dep` is a two char string (as "qt"), the `platform, name = dep`
will split the string and search for 't' dependency in 'q' platform.
So, we have to be sure that the dep is a tuple before splitting it.
- Disable icuio and layoutex.
- Hardcode UTF8 as charset (we always use utf8 and hardcoding him improve
performances)
- Do not include default utf headers
- Do not use `using namespace icu`
See http://source.icu-project.org/repos/icu/trunk/icu4c/readme.html#RecBuild
for more information about options.
Increment base dependencies version as we are compiling icu differently.
Enable `--no-daemon` : Using the daemon make gradle keep "configuration"
(like plugin path). If gradle installation path change, it will break
kiwix-android build.
Enable `--build-cache` : This is not the case by default :/
This should greatly improve compilation speed.
By building kiwix-android on the `android` platform, we can now build
`kiwix-lib` on all `android_<arch>` platforms, and so have all
architectures in the same apk.
Fix#108
A metaplatform allow to regroup sereval platform together.
When a target is added to the platform, the target is dispatched/add to
all sub platforms.
As the step (metaplatformName, target) is not really added, we have to
track which steps are really added, so `add_targets` need to return the
list of added targets.
This is the big change !!!!
Instead of handling target as primary object and prepare/build targets,
we are handling build steps.
A build step may be a source (preparation) or a build (of the source).
Actualy, a step is a tuple (context, Builder or Source).
The context define the context of the step. It can be :
- 'source', for a Source step
- 'neutral' or the name of a platform for Build step.
Target becomes a "Class only" class.
Sometime the root_path is dependent of the target platform and sometime
not. But sometime dependent of the build arch :/
[TODO] We should move the cross_file generation to the PlatformInfo class.
cm8
Emmanuel Engelhart
Matthieu Gautier