Warning is:
#warning redirecting incorrect #include <sys/poll.h> to <poll.
Not a big issue.
But it can be annoying when building with -Werror set.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
I guess these were left since some initial OVS package versions.
They were fine up until recently.
Some of the build artifacts got a little messy and thus the
OpenWRT OVS package got a little messy.
This cleans it up a bit.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Probably related to -fstack-protector being used.
Got the idea from:
http://ubuntuforums.org/showthread.php?t=352642&p=10100263#post10100263
Regarding the missing __stack_check_fail_local, using gcc as the linker instead of ld fixes the issue without disabling stack protection as with -fno-stack-protector.
Fixes linker errs on some targets:
objects/prod/dnssd_clientstub.c.so.o: In function `handle_resolve_response':
dnssd_clientstub.c:(.text+0x395): undefined reference to `__stack_chk_fail_local'
objects/prod/dnssd_clientstub.c.so.o: In function `handle_query_response':
dnssd_clientstub.c:(.text+0x4bd): undefined reference to `__stack_chk_fail_local'
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
For x86 and x86_64, nodejs has some special CPU
code that needs to be selected by specifying
the correct CPU name (correct for nodejs).
On OpenWRT x86 is i386 ; node wants ia32 for this.
And x86_64 is x64 on nodejs.
So, we just need to do the proper substitutions.
Note: the ARCH env-var is obtained from CONFIG_ARCH, after
some subtitutions are applied.
So, it shouldn't affect other target archs.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Version 1.13.3 has a tar.gz so the OpenWRT default Build/Prepare
rule can be used with MD5 checksum.
Add patch to fix build:
ktutil_funcs.c: In function 'ktutil_delete':
ktutil_funcs.c:75:28: error: 'prev' may be used uninitialized in this function [-Werror=maybe-uninitialized]
prev->next = lp->next;
There does not seem to be a way for 'prev' being uninitialized
(logically), however the compiler does not see that, because
'prev' is dependent on i >= 1.
So, we just need to initialize it to NULL.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Reported buildbot issue is:
/store/buildbot/slave/ar71xx/build/build_dir/target-mips_34kc_musl-1.1.11/ola-0.9.7/plugins/openpixelcontrol/.libs/libolaopenpixelcontrol.so: undefined reference to `ola::network::TCPSocket::ReadDescriptor() const'
collect2: error: ld returned 1 exit status
There's also a discussion (attempt) to fix this on the buildroot project:
https://patchwork.ozlabs.org/patch/503884/
This bug has been reported (from the buildroot project), here:
https://github.com/OpenLightingProject/ola/issues/880
This commit introduced the issue:
https://github.com/OpenLightingProject/ola/commit/bfc1d99055980dfac5c959a7210257d1939803ec
specifically the `-fvisibility-inlines-hidden` switch.
So, until, the upstream project (ola) fixes this, this fix
looks like the quickest/simplest workaround to have this package build.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Seems ntpdate also requires this lib:
```
Package ntpdate is missing dependencies for the following libraries:
libcap.so.2
make[2]: *** [/store/buildbot/slave/ar71xx/build/bin/ar71xx/packages/packages/ntpdate_4.2.8p4-1_ar71xx.ipk] Error 1
make[2]: Leaving directory `/store/buildbot/slave/ar71xx/build/feeds/packages/net/ntpd'
```
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Seems those pkgconfig file paths were revealed to be incorrect
after doing a full clean build.
And I only had to inspiration to do one after doing the initial PR.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
And split python-dev and python-lib2to3 packages.
Seems for python3 this was done, so we'll sync here.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
That means basically moving the host Python from $(STAGING_DIR_HOST)
to $(STAGING_DIR_HOST)/usr and making the PYTHONPATH var
as an argument.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Some notes about the 'encodings' module, which is about 1.7 MB.
Unfortunately that one cannot be moved into the 'python3-codecs'
package, because Python tries to load up all available encodings
at startup.
Some efforts to add a dummy folder/python file have failed so far,
since there's a C code (Python/codecs.c) that tries to evaluate that
all encodings (in the encodings folder/module) are valid.
Basically the encodings module is a repository of encodings,
and it seemst there are quite a few of them.
Maybe a request to upstream Python would work for this, to
make encodings a bit more decoupled from the interpreter.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Based on the idea that 'what-works-on-python-should-work-on-python3'
because they share the same trunk, these patches have been copied over
from the python package.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Rule of thumb is: any Python file that is greater than 100kb
(or adds a dependency with which it adds more than 100 kb)
should be a pretty useful/commonly used lib to stay in `python-light`.
An example, is the Python IO lib, which summarized (Python source +
binary module) is over 200kb.
Also moved some files that should have been put into previously
existing packages before, and re-organized the packages a bit.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Seems removing the PyPackage rule and/or adding dummy install rule
causes some issues inside the build-system, where the libpython2.7.so.1.0
is not seen by packages that depend on python.
Even though that libpython2.7.so.1.0 file is installed properly by `python-base`.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Calling `PyPackage` will install some default install rules for
python packages that are not required for the `python` package specifically
are not required.
That will lead to some conflicts with `python-light` because the
`/usr/lib/python2.7/site-packages` folder (+contents) will be
available in both packages.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
When cross-compiling, we do not need to add runtime lib dirs.
Also, the cross compilers that are used on OpenWRT do not support
the '-R' option, which causes build failures.
These build failures existed before, but were not noticed,
because it fails only on some setups.
This is because Python's `setup.py` does a lot of voo-doo
automagic that needs handling for some cross-compilation cases.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Packetize some Python modules to reduce size of the overall Python package.
Basically, a new package is introduced, call `python-light`,
and everything that's extra (or big) is put in other packages.
The `python` package becomes a metapackage that installs `python-light`
along with the rest of the packages.
Base work started by Jan Čermák.
Signed-off-by: Jan Čermák <jan.cermak@nic.cz>
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Seems when cross compiling on x86_64 Debian (most likely Ubuntu too)
the host's paths will be added too causing build failures for some extensions.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Python packs some pip installation script during the build,
which looks like a better idea to use for the python-pip
and/or python-setuptools packages.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Some symbols are not found (tgetnum and BC).
Looks like the termcap lib, which should be in libncurses(w)
but maybe some build param would be required.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Redefine python-full as all-pages-minus-a-few-that-don't make sense.
Remove all other packages.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This mostly helps to avoid confusion when modules are cross-compiled.
Otherwise build folders are named with the host's platform name.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
The target's PYTHON3_INC_DIR should take precedence over the host's
include dir when cross-compiling.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Python's build scripts prefer ncursesw, and if it is detected
it will be used.
The problem will occur when linking, since ncursesw libs may not be
installed if not added as deps, but the sources will be compiled
against ncursesw.
Reference from Python's HISTORY file:
Patch #1428494: Prefer linking against ncursesw over ncurses library.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This mostly helps to avoid confusion when modules are cross-compiled.
Otherwise build folders are named with the host's platform name.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This will reduce the bloat when users will want to compile in their
Python C extensions.
There will be a initial bloat (several kb) if just Python
is installed, but that will be compensated when users will add more
C extensions.
During the build we also have to add Python's PKG_BUILD_DIR
so that the shared lib is found when compiling Python's
built-in C extensions.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
The target's PYTHON_INC_DIR should take precedence over the host's
include dir when cross-compiling.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
