Cleanup to prepare for changing STAGING_DIR_HOSTPKG. The actual change of
STAGING_DIR_HOSTPKG (i.e., moving the host packages back into a common, not
target-specific directory) will be done after the first LEDE release, but
the cleanup will also be useful for projects like Gluon.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Sometimes I'm getting error on the host-side build:
```
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: /home/sandu/work/lede/staging_dir/host/lib/liblzma.a(liblzma_la-common.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/home/sandu/work/lede/staging_dir/host/lib/liblzma.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:2847: recipe for target 'libgettextlib.la' failed
make[9]: *** [libgettextlib.la] Error 1
make[9]: Leaving directory '/home/sandu/work/lede/build_dir/target-x86_64_musl-1.1.15/host/gettext-0.19.8.1/gettext-tools/gnulib-lib'
Makefile:2597: recipe for target 'all' failed
```
Disabling the shared-lib build, seems to fix this.
This is when building glib2 on the host-side.
glib2 is required by newer QEMU package [which is in the feeds].
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
When the gettext-full host build phase finds an `emacs` exectuble during the
build it will launch an `emacs --batch` command to run some Lisp code.
On certain Debian systems the `/usr/bin/emacs` path might point, via
alternatives, to the `/usr/bin/jove` editor which will then launch an
interactive session when invoked by the gettext build.
In order to avoid this problem, explicitely disable emacs handling during
the build through a configure environment variable.
Also remove my now unreachable maintainer address.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
The autopoint and gettextize host utilities contain hardcoded staging dir
paths which need to be overridden for the SDK environment.
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
SVN-Revision: 48208
Note, that licensing stuff is a nightmare: many packages does not clearly
state their licenses, and often multiple source files are simply copied
together - each with different licensing information in the file headers.
I tried hard to ensure, that the license information extracted into the OpenWRT's
makefiles fit the "spirit" of the packages, e.g. such small packages which
come without a dedicated source archive "inherites" the OpenWRT's own license
in my opinion.
However, I can not garantee that I always picked the correct information
and/or did not miss license information.
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
SVN-Revision: 43155
