Building Alt-F for DNS-320L on a x64 Linux Mint 18.1

[Friesenkiwi]

Hi,
thank you for your work to free the DNS-320L (and the other devices) and
the latest 1.0 release.

I want to build a dedicated backup solution out of the 320L, using
Borgbackup (https://borgbackup.readthedocs.io/en/stable/) and Syncthing
(https://syncthing.net/) for multi-site-backup/syncing.
I flashed 1.0 snapshot to the NAS using the web interface, it is running
fine! Syncthing is running out of the box, because it is written in Go
and has very little dependencies.
Borgbackup unfortunately is not, because it needs Python 3.4.0+ and some
more dependencies to build (see
https://borgbackup.readthedocs.io/en/stable/installation.html#source-install)
and the unofficial standalone binary ARM builds (via pyinstaller, see
https://github.com/borgbackup/borg/issues/1018) depend on
/lib/ld-linux.so.3 of glibc.

So I want to build an Alt-F .bin myself and then change the sources to
include Borgbackup and Syncthing right from the beginning. I got stuck
on creating the .bin from the unaltered SVN sources after clearing some
hurdles, so I hope you can help me in how to set up the build environment?
I run a 64bit Linux Mint 18.1 Serena on the build machine.

Problems:
1. bfd.texinfo:325: unknown command `colophon'/`cygnus'
when building binutils-2.23.51 documentation
=> remedy by
find -name '*.texinfo' | sed 's/texinfo$/info/' | xargs touch
after first build fail

2. error: expected ')' before 'int'
when building ncurses
=> remedy by
export CPPFLAGS="-P"
before running the
. exports dns325

3. ../../gcc/toplev.c:536:1: error: redefinition of ‘floor_log2 [etc.]
when building gcc. I was running the default gcc, which seems to be 5.
=> remedy by
apt install gcc-4.7
and switching /usr/bin/gcc and /usr/bin/g++ links to the -4.7 instances.
4.7 seems to be the oldest version available via apt.

4. ./stdint.h:47:13: error: empty filename in #include
when building gettext-0.16.1
=> remedy by simply deleting line 47 (# include "") from
[...]/alt-f-read-only/alt-f/build/build_arm/gettext-0.16.1/gettext-tools/gnulib-lib/stdint.h

5. Directly after this comes the fatal error:
In file included from ./stdint.h:68,
from xsize.h:28,
from linebreak.c:27:
[...]/alt-f-read-only/alt-f/build/build_arm/staging_dir/usr/include/inttypes.h:300:
error: expected '=', ',', ';', 'asm' or '__attribute__' before 'imaxabs'
[5 more]
In file included from gl_linkedhash_list.c:24:
./stdint.h:47:13: error: empty filename in #include
In file included from ./stdint.h:68,
from gl_linkedhash_list.c:24:
[...]/alt-f-read-only/alt-f/build/build_arm/staging_dir/usr/include/inttypes.h:300:
error: expected '=', ',', ';', 'asm' or '__attribute__' before 'imaxabs'
[5 more]

I also on error 4 tried
# include <stdint.h>
trying to follow the source comment:
> Other systems may have an incomplete or buggy <stdint.h>. Include it
> before <inttypes.h>, since any "#include <stdint.h>" in <inttypes.h>
> would reinclude us, skipping our contents because GL_STDINT_H is
> defined.

But to no avail. It seems to me, something is going wrong here in the
automatic generation? Can you please help?

Thank you very much already in advance!

Cheers,
friesenkiwi

[João Cardoso]

I'm afraid I can't help. gcc-4.7 can't cross-build-bootstrap gcc-4.3? It's out of my competences.

I'm using gcc-4.8.3 on openSuSE 13.2 on both 32 and 64 bits machines.

I build Alt-F in the past on Debian and some other Debian-based distros, but several users have also reported difficulties, it's not an easy task. Perhaps using a minimum install VM to do the build?

Sorry

[Friesenkiwi]

Hi and thank you for your quick reply!

Am 01.07.2017 um 03:12 schrieb João Cardoso:
>
>
[...]

>
> I'm afraid I can't help. gcc-4.7 can't cross-build-bootstrap gcc-4.3? It's
> out of my competences.
>
> I'm using gcc-4.8.3 on openSuSE 13.2 on both 32 and 64 bits machines.
> I build Alt-F in the past on Debian and some other Debian-based distros,
> but several users have also reported difficulties, it's not an easy task.
> Perhaps using a minimum install VM to do the build?
>
> Sorry
>

[...]

This is already very valuable information! It is good to know, that
building for you succeeds with gcc-4.8.3. So you're saying, you are running

svn checkout svn://svn.code.sf.net/p/alt-f/code/trunk/alt-f alt-f-read-only
cd alt-f-read-only
. exports dns325
make >& build-dns325.log && echo OK || echo FAIL
./mkinitramfs.sh
./mkfw.sh

(as shown at
https://sourceforge.net/p/alt-f/wiki/How%20to%20Build%20RC4/) on a clean
directory on your system and it works rightaway?

Or are any other commands needed or any settings to the environment
before? Perhaps some of those in
https://sourceforge.net/p/alt-f/wiki/How%20to%20Build%20RC3/ ?

Trying to use a VM might be a good idea, I think I could do that but
would first like to try to use the "normal" way :-)
I am not fluent in C/C++ and only have basic experiences in building
myself, especially little with embedded systems, but I am always eager
to learn and try to solve difficult tasks.


On a different note:
Borgbackup lists glibc >= 2.13 and Python >= 3.4.0 as requirements. I
don't think glibc is a hard requirement but hope it can easily be
substituted by uClibc.
But Alt-F has only a Python 2.7.2 package. Do you think, it would be
possible to have a python3 one, or are there some known problems or
blockers with that?

If my system works, I would be happy to contribute a borgbackup package
to be installed via the package manager.

Cheers again,
friesenkiwi

[João Cardoso]

On Saturday, 1 July 2017 07:59:14 UTC+1, Friesenkiwi wrote:

Hi and thank you for your quick reply!

Am 01.07.2017 um 03:12 schrieb João Cardoso:
>
>
[...]
>
> I'm afraid I can't help. gcc-4.7 can't cross-build-bootstrap gcc-4.3? It's
> out of my competences.
>
> I'm using gcc-4.8.3 on openSuSE 13.2 on both 32 and 64 bits machines.
> I build Alt-F in the past on Debian and some other Debian-based distros,
> but several users have also reported difficulties, it's not an easy task.
> Perhaps using a minimum install VM to do the build?
>
> Sorry
>
[...]

This is already very valuable information! It is good to know, that
building for you succeeds with gcc-4.8.3. So you're saying, you are running

svn checkout svn://svn.code.sf.net/p/alt-f/code/trunk/alt-f alt-f-read-only
cd alt-f-read-only
. exports dns325
make >& build-dns325.log && echo OK || echo FAIL
./mkinitramfs.sh
./mkfw.sh

(as shown at
https://sourceforge.net/p/alt-f/wiki/How%20to%20Build%20RC4/) on a clean
directory on your system and it works rightaway?

Sorry for the late reply.

Yes, that is the recipe. More details can be found at the RC3 build instructions. 

Some packages might have to be installed on the host, but generally the build warns you of missing packages.

As cross compilation is being used, sometimes the build system configure scripts "leaks" into the host system, using headers or libraries from it, and that can only generally be detected at runtime (or searching the logs for '-I/usr/include' or similar)

 

Or are any other commands needed or any settings to the environment
before? Perhaps some of those in
https://sourceforge.net/p/alt-f/wiki/How%20to%20Build%20RC3/ ?

The purpose of "exports" is to free the user from having to define any env. Those RC3 instructions are mostly still valid, but a great deal of discipline is needed when changing different "boards" using the same build tree.

Trying to use a VM might be a good idea, I think I could do that but
would first like to try to use the "normal" way :-)
I am not fluent in C/C++ and only have basic experiences in building
myself, especially little with embedded systems, but I am always eager
to learn and try to solve difficult tasks.


On a different note:
Borgbackup lists glibc >= 2.13 and Python >= 3.4.0 as requirements. I
don't think glibc is a hard requirement but hope it can easily be
substituted by uClibc.

Yes, generally there are no problems with that.

 

But Alt-F has only a Python 2.7.2 package. Do you think, it would be
possible to have a python3 one, or are there some known problems or
blockers with that?

Time, motivation and compatibility with existing packages are the main reasons.

I never tried to cross build pyton3 myself, but if someone contributes a working patch I will gladly add it. A good starting point is adapting buildroot python3 package https://git.busybox.net/buildroot/tree/package/python3 (buildroot has evolved a lot since buildroot-2009.08, which Alt-F is based on)