Unfortunately it doesn't come with a Subversion server built in, so I set out to build it myself. This was a bit of a learning process; I'm taking note of it here in case it may be useful for anybody else trying to build software to run on it.
Open_Source_packages/containing modified source code archives of utilities distributed on the appliance
toolchain/containing the tools and libraries needed to cross-build
xbuild.shscript that can be used to build the package with the correct configuration settings, presumably contributed by Western Digital themselves. In this case just executing
./xbuild.sh buildis enough to build the package correctly.
Some, however, have an
sbbuild.sh script instead. These refer to a no-longer-supported project
called ‘Scratchbox’, which apparently would have provided some way of simulating the target environment
enough for the Autoconf scripts to detect the proper configuration settings. Note that
runs in and detects properties of the host environment, which may not be the correct ones for software that runs
in the target environment. Presence of a Scratchbox-type build script seems a good indication that
the package will need some extra careful attention.
armv7-marvell-linux-gnueabi-softfp_i686_64K_Dev_20131002.tar.gz. Extract this in place, and go one level inside. Observe that
bin/contains tools and libraries that run on the host, whereas the
arm-marvell-linux-gnueabi/(or whatever the case may be) subdirectory has things that run on the target. Importantly, this has the debugger server in
libc/usr/bin/gdbserverwhich was absolutely invaluable in solving the various build problems that I ran into.
sudo dpkg --add-architecture i386 sudo apt-get update sudo apt-get install libc6:i386
source.mescript in the current shell (by executing
. source.me). This sets up environment variables (notably
TARGET_HOST) which are used by the build scripts. Note here that
MY_PREFIXis actually the
DESTDIRconcatenated with the
Open_Source_packages. For each, extract the archive and go inside. Since both these packages have the ‘simple’ cross-build scripts, build by executing
./xbuild.sh build. This builds and installs into a staging directory called
Through trial and error I found the correct configuration to be:
./configure \ --prefix=$MY_PREFIX --host=$TARGET_HOST --with-gnu-ld \ CFLAGS='-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DNO_LINGCLOSE -DSO_LINGER' \ ac_cv_file__dev_zero=yes \ ac_cv_func_setpgrp_void=yes \ apr_cv_tcp_nodelay_with_cork=yes \ ac_cv_sizeof_struct_iovec=1 \ ac_cv_sizeof_pid_t=4That last one in particular (4-byte PIDs) took a serious investment in Assembly-level debugging to find. The lesson for me is that it would have been worth the extra time and effort to double-check whether the autodetected host configurations actually matched the target, and not just assuming that a successful compile meant everything was OK.
Next, try building:
makeThis will fail right away because it's compiling a tool that is used in the build itself; and that shouldn't be cross-compiled. I suppose that an extremely well-written configuration script might have been able to distinguish between artifacts that run on the host rather than the target and adjust accordingly. In this case, I just worked around it by manually executing the commands needed to build the tool: this requires replacing the
However, it turns out that you must first must create a directory so that the Makefile doesn't just rebuild another bad version right on top of it again (this seems like a Makefile bug to me):
mkdir make_tools_dirThe four modified commands that I had to execute manually look something like
/bin/bash /some-path-to/WDMyCloud_Ex2Ultra_GPL_v2.30.193_20180502/Open_Source_packages/apr-1.5.1/libtool \ --silent --mode=compile gcc \ ... \ -o tools/gen_test_char.lo -c tools/gen_test_char.c && touch tools/gen_test_char.lo /bin/bash /some-path-to/WDMyCloud_Ex2Ultra_GPL_v2.30.193_20180502/Open_Source_packages/apr-1.5.1/libtool \ --silent --mode=link gcc \ ... \ -o tools/gen_test_char tools/gen_test_char.lo \ ... /some-path-to/WDMyCloud_Ex2Ultra_GPL_v2.30.193_20180502/Open_Source_packages/apr-1.5.1/build/mkdir.sh \ include/private tools/gen_test_char > include/private/apr_escape_test_char.hAfter this, you should be able to once again
makeand have it complete the build. Then
make installas usual to install to the staging area.
All this shows that cross-building isn't always just a ‘fire-and-forget’ no-brainer; once in a while you do have to get down and dirty into the build process.
./configure \ --prefix=$MY_PREFIX --host=$TARGET_HOST \ --with-apr=$MY_PREFIX/bin/apr-1-config \ --with-expat=$MY_PREFIX \ CFLAGS='-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DNO_LINGCLOSE -DSO_LINGER' make make install
While SQLite is actually preinstalled on the NAS, the version (3.6.14) isn't sufficiently recent for Subversion (which needs at least 3.7.12). This is another reminder of the importance of carefully reading and checking the build instructions, or risking a much harder slog debugging a bad build later on.
Subversion happens to support downloading a SQLite ‘amalgamation’ directly inside and building it there; I just used the latest available stable release:
curl 'https://www.sqlite.org/2018/sqlite-amalgamation-3240000.zip' >sqlite-amalgamation-3240000.zip unzip sqlite-amalgamation-3071501.zip mv sqlite-amalgamation-3240000/ sqlite-amalgamationThe Autoconf configuration script tries to compile a program to detect whether it's running on Mach-O; however, this again fails because the program is compiled for the target environment and won't run. For this case I created this patch which modifies the Autoconf check macro into an Autoconf cacheable variable that we can set to avoid the check altogether. Apply the patch and regenerate the configuration script:
patch -p0 <subversion-mach-O.patch autoconfNow the package can be configured and built:
./configure \ --prefix=$MY_PREFIX \ --host=$TARGET_HOST --build=x86_64-linux-gnu \ --with-apr=$MY_PREFIX/bin/apr-1-config \ --with-apr-util=$MY_PREFIX/bin/apu-1-config \ --with-zlib=$MY_PREFIX \ --enable-optimize --disable-nls \ CFLAGS='-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DNO_LINGCLOSE -DSO_LINGER' \ LDFLAGS='-Wl,--dynamic-linker=/lib/ld-linux.so.3 -Wl,-rpath-link=$MY_TARGET/lib' \ ac_cv_svn_lib_macho_iterate=no make make installThe specification of the path to the dynamic linker is required because the appliance doesn't have it in the default place that's built in to the linker. I do get plenty of “libtool: warning: '.../libexpat.la' seems to be moved” errors, but I ignored them and they don't seem to affect the build.
-g -O0to the
All pages under this domain © Copyright 1999-2018 by: Ben Hekster