Dariusz on Software

Few, most important in my opinion, however mostly overlooked GCC compiler switches:

• -Wall: enables all the warnings about constructions that some users consider questionable, very likely a programming mistakes
• -Wextra: enables some extra warning flags that are not enabled by -Wall
• -Winit-self: warn about uninitialized variables which are initialized with themselves
• -Wold-style-cast: warn if an old-style (C-style) cast to a non-void type is used within a C++ program
• -Woverloaded-virtual: warn when a function declaration hides virtual functions from a base class
• -Wuninitialized: warn if an automatic variable is used without first being initialized
• -Wmissing-declarations: warn if a global function is defined without a previous declaration
• -ansi, -std=standard: specify the C/C++ standard level used
• -pedantic: issue all the warnings demanded by strict ISO C and ISO C++, and -pedantic-errors that tunrs them into errors (aborts compilation)

and the most important one:

• -Werror: turns warnings into errors, so your build would go red in case of any warning

I must admit we used to use "-Werror" extensively for many years and many pitfalls are omitted then automatically.

Default git colour setup is not so good. On black terminal background it looks dark:

However, with small change in ~/.git/config file: [color "diff"] meta = yellow bold frag = magenta bold old = red bold new = green bold you would get much better diff display on your terminal:

When you see the following kind of errors during cross compilation (linking phase): ld: warning: libfontconfig.so.1, needed by .../libQtGui.so, not found (try using -rpath or -rpath-link) ld: warning: libaudio.so.2, needed by .../libQtGui.so, not found (try using -rpath or -rpath-link) There could be two reasons:

• the list of required binaries is not complete and linker cannot complete the linking automatically
• your $SYSROOT/usr/lib is not passed to linker by -rpath-link as mentioned in error message

During normal native build your libraries are stored in standard locations (/usr/lib) and locating libraries is easier. Cross compilation needs more attention in this ares as SYSROOT is not standard.

Then search for LDFLAGS setup in your build scripts: LDFLAGS="-L${STAGING_LIBDIR}" And change to the following: LDFLAGS="-Wl,-rpath-link,${STAGING_LIBDIR}-L${STAGING_LIBDIR}" The clumsy syntax -Wl,<options-with-comma-as-space> tells your compiler (that is used for linking purposes) to pass the options (with commas replaced by spaces of course) to linker (ld).

If you are an embedded software developer like me chances are you use embedded Linux for the purpose. It's Open Source, has great tools support and is a great software environment where (almost) everything could be automated through command line interfaces.

Once you decide about operating system used the next step is to choose a build system that would be used for the task of building the software. There are few choices you can select from:

• use pre-built toolchain and rootfs and add your binaries and configuration files (i.e. STLinux for ST-based devices)
• use OpenEmbedded for full-featured buildsystem with packaging system included
• use BuildRoot for simple build system without packaging system included

Today I'm going to tell you about the 3rd option. Buildroot states their view on packaging systems for embedded development this way: We believe that for most embedded Linux systems, binary packages are not necessary, and potentially harmful. When binary packages are used, it means that the system can be partially upgraded, which creates an enormous number of possible combinations of package versions that should be tested before doing the upgrade on the embedded device. On the other hand, by doing complete system upgrades by upgrading the entire root filesystem image at once, the image deployed to the embedded system is guaranteed to really be the one that has been tested and validated. After few years with OpenEmbedded and few months with Buildroot I like the simplicity of Buildroot model. Below you can find basic (the most important in my opinion) concepts of Buildroot.

Buildroot uses basic "make" interface and, actually, it's written in Makefile language. It's clearly visible in (sometimes) weird syntax for packages declaration. For configuration Config.in files are used (the same as for Linux kernel configuration). It's quite useful and extensible choice for configuration and building.

Recipes system (usually placed under package/ subdirectory) describes in Makefile+Config.in language rules for fetching / configuring / building / installing. You can build+install selected package by issuing: "make <pkg-name>" - quite simple and elegant solution.

Each build is configured in .config file that could be edited make well-known "make menuconfig" interface:

You could select build switches there as well as list of included packages.

All the output is placed under "output" subdirectory (you can force full clean by deleting this directory):

• build/<pkg-name>/ - working directory for building given package (no "rm_work" there as in OE, build directories are kept after build)
• build/<pkg-name>/.stamp_* - describes build state for given package, you can force given stage by deleting selected files there
• host/ - the toolchain
• target/ - rootfs (filled in fakeroot mode) used for creating resulting images
• images/ - resulting images are placed there (tgz, squashfs, kernel binary and so on)

Basic input directories:

• package/<pkg-name>/<pkg-name>.mk - a recipe for given package (Makefile syntax)
• Config.in - root of configuration files possible options
• dl/ - this directory is not stored in version control system, but holds cached version of downloads. It's placed outside of output directory in order not to download source packages after every clean
• fs/ - recipes for various output image options (tgz, squashfs and so on)
• system/skeleton/ - basic filesystem structure

The buildsystem is very fast and allows very high level of customizations.

If you encounter the following error during VPN connection: pptp[12549]: nm-pptp-service-12543 warn[decaps_gre:pptp_gre.c:331]: short read (-1): Message too long there's an easy fix. You have to lower your MTU (automatically obtained value was invalid).

First, you have to locate your VPN gateway address in syslog: NetworkManager[11926]: <info> VPN Gateway: X.X.X.X Then, you have to check minimum MTU toward this address: $ traceroute --mtu X.X.X.X traceroute to X.X.X.X (X.X.X.X), 30 hops max, 65000 byte packets 1 192.168.43.1 (192.168.43.1) 4.309 ms F=1380 4.042 ms 2.535 ms 2 * *^C Then you have to change MTU it in your primary connection settings (network manager on Ubuntu below):

That's all!. No more spurious disconnects!