Just so you know - after 1.0.0-based image is officially announced as the new supported version, I'm working on rebasing the devtools image onto BSP version 1.0.1, which was also just released. That would converge the vanilla and the devtools image versions I'm providing and will allow those with devtools image to use my package repository for even more expandability.
In addition to rebasing, I'm working on adding motion and the latest version of the OpenCV (2.4.9) into the default install + upgrading node.js and redis to the latest versions.
Stay tuned! :-)
And here it goes: http://telekinect.media.mit.edu/galileo/image-devtools-1.0.1-1.tar.bz2 (MD5 checksum is at http://telekinect.media.mit.edu/galileo/image-devtools-1.0.1-1.tar.bz2.md5sum)
The main change is (as previously mentioned) rebasing to BSP 1.0.1, which fixes potential Heartbleed-related vulnerabilities plus some other like ADC-related fixes (see 1.0.1 Release Notes on Intel Download portal). Don't forget to upgrade your Galileo to either latest official firmware v.1.0.0 or my inofficial 1.0.1 if you're still on 0.7.5.
Other changes are:
- OpenCV 2.4.9 (latest). Only base set of libraries is installed, if you want them all or add development headers - use the package repo at http://alextgalileo.altervista.org
- updated Node.js and Redis to the latest versions
Your feedback and suggestions as to the enhancing the image are more then welcome!
@all, the devtools image was updated, in addition to all of the above items it now has dnsd+udhcpd enabled in BusyBox (so you can setup your small DNS and DHCP server) + hostapd (which helps to create a wireless access point) + has a fix for a bug in libgcrypt library, which caused "illegal instruction" error in any program, which tried to use AES cipher from it.
The image and MD5 sum are at:
The image was updated to include:
1) the latest node.js version (0.10.29);
2) the latest redis version (2.8.11);
3) quite a few useful node.js modules to make it easier to start off;
EDIT: yikes, looks like I've pasted links to older build version, should have ended with "3". Now updated, give it a shot and sorry for that!
Autoconf broke compatibility between 2.13 and 2.50, so a lot of distros offer separate packages for the two streams. Our build system uses autoconf2.13, so it won't work with 2.69.
I was able to roll my own 2.13 from source, so not a big deal.
What's involved in building a package for Galileo? Would it be worth my while to package up autoconf2.13 and the other packages I'm building from source (NSPR, APR), or is it a lot of hassle to make the packages? (I'm not a Linux newbie, but I've never built a package-manager-package before).
Generally, it highly depends In theory you just create a proper recipe and Yocto will do everythign for you from downloading sources to configuring them to applying your patches, compiling and packaging.
Now creating a recipe is not always trivial, because applications may not be easily cross-compilable, there are quirks and bugs and so on.
Yopu can try creating a recipe for autoconf 2.13 using the one for 2.69 as an example. In the best case you'd only need to rename it (to change the version) and correct MD5/SHA1 checksums.
The image was updated to the latest officially released "Galileo software release 1.0.2", which adds OpenSSL patches for the security vulnerabilities revealed post-Heartbleed + several stability patches (see Release Notes for the 1.0.2).
No other functionality changes since 1.0.1-3
UPDATE: Added CIFS protocol support per our conversation with tfx in another thread.
Whoops! My last reply was intended for this thread:
CIFS works great, but OpenCV doesn't like the build:
/usr/bin/python2.7: symbol 'th_comment_query_count': can't resolve symbol in lib '/usr/lib/libtheoraenc.so.1'.
Traceback (most recent call last):
File "find_obj.py", line 16, in <module>
ImportError: unknown dlopen() error
I did some searching on that error and it has cropped up before:
Looks like you are building the uclibc version of the SD card image: that's the same error I got when trying the uclibc build.
opencv does not work in the uclibc build.
Did you build using uclibc or eglibc? If you used eglibc, we'll have to keep digging... otherwise I'll see if I can figure out the latter.
OK here are my notes on the build:
- Start clean, and follow the directions on alext-mkrs/meta-alext-galileo · GitHub
- Enable opencv, opencv-samples, and cifs
- Fix that nasty vlc bug by editing ./meta-oe/meta-oe/recipes-multimedia/x264/x264_git.bb and updating the hash (as per Yocto Clanton full: Build error for x264 package)
- Commented out the uclibc patches Intel Galileo - Building Linux Image - Malinov Family Web Presence
- (worried that it means Arduino sketches won't work, given the info in that thread)
- Failed with "ERROR: Task 1321 (/home/daniel/yocto/meta-clanton_v1.0.1/meta-oe/meta-oe/recipes-multimedia/v4l2apps/v4l-utils_0.8.8.bb, do_configure) failed with exit code '1'"
- Tried simply disabling it - doesn't work. Parent dependencies roll into OpenCV
Dug into it:
configure: error: unable to find the argp_parse() function
Configure failed. The contents of all config.log files follows to aid debugging
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by v4l-utils configure 0.9.0-test1, which was
generated by GNU Autoconf 2.69. Invocation command line was
$ /home/daniel/yocto/meta-clanton_v1.0.1/yocto_build/tmp/work/i586-poky-linux-uclibc/v4l-utils/0.8.8-r2/git/configure --build=i686-linux --host=i586-poky-linux-uclibc --target=i586-poky-linux-uclibc --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib/v4l-utils --datadir=/usr/share --sysconfdir=/etc --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib --includedir=/usr/include --oldincludedir=/usr/include --infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/home/daniel/yocto/meta-clanton_v1.0.1/yocto_build/tmp/sysroots/clanton --disable-qv4l2 --enable-shared --disable-nls
Devtools image is uclibc-based, just like the official one and yes, python OpenCV binding not working, it is a known problem.
If you want to use that, you indeed need to switch over to eglibc image (and I'd suggest you to create a new thread on that, let's have this one devoted to a devtools image), or
use the IoT DevKit image, which is eglibc based and has Python OpenCV binding working, AFAIK. I haven't worked with it, so I don't have any details, but should be "googlable" There are also mentions of it in this community, just try the search.