I don’t understand what for yocto builds unusable -dev and -src packages? Something like libnl-3-dev doesn’t provide static link library. -src don’t provide makefiles. What the point of having them generated if they are unusable?
I made image with gcc and required dev. packages to be able to make on targed skipping the burden of yocto and cross-compiling issues. I install dependency ipk’s from yocto deploy folder and what? And nothing…
Edward
Hi @kevin.tx,
Does it really matter what carrier board it is? Its Iris V1.1A. The same would happen to eval v3 and all all other carrier boards.
Pre-build image is made from sources. I’ll switch to quarterly releases soon. But I very doubt it will be different, unless you fix something.
The problem again:
I let yocto build and put to image packagegoup-sdk-target, wget, git, etc to be able to compile something on target. Sometimes its hard to configure sources on different machine. Now I hit the need to rebuild some *.ipk from sources. So I take *src.ipk from yocto build/deploy folder and install it on target using opkg. It turns out that what I install is useless, because something like *.c files get installed, but no makefile or essential .config, which should be present in sources of hostapd package.
The same issue with *dev.ipk packages. I need some developer library for gcc, which has to provide *.a file, else GCC won’t link. I try to install *dev.ipk file, which certainly should provide developer link library. And again, it turns out that *dev.ipk is useless, no *.a file in it.
The question is what the heck yocto burns electricity and heats our planet to build those not working and useless *.ipk’s ?
Bets Regards,
Edward
Hello @Edward,
These packages are not necessarily useless.
You can define what you need or not by the “EXTRA_IMAGE_FEATURES” on your local.conf:
#
# Extra image configuration defaults
#
# The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated
# images. Some of these options are added to certain image types automatically. The
# variable can contain the following options:
# "dbg-pkgs" - add -dbg packages for all installed packages
# (adds symbol information for debugging/profiling)
# "src-pkgs" - add -src packages for all installed packages
# (adds source code for debugging)
# "dev-pkgs" - add -dev packages for all installed packages
# (useful if you want to develop against libs in the image)
# "ptest-pkgs" - add -ptest packages for all ptest-enabled packages
# (useful if you want to run the package test suites)
# "tools-sdk" - add development tools (gcc, make, pkgconfig etc.)
# "tools-debug" - add debugging tools (gdb, strace)
# "eclipse-debug" - add Eclipse remote debugging support
# "tools-profile" - add profiling tools (oprofile, lttng, valgrind)
# "tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.)
# "debug-tweaks" - make an image suitable for development
# e.g. ssh root access has a blank password
# There are other application targets that can be used here too, see
# meta/classes/image.bbclass and meta/classes/core-image.bbclass for more details.
# We default to enabling the debugging tweaks.
# package-management deploys the package meta data of deployed packeges
EXTRA_IMAGE_FEATURES ?= "debug-tweaks package-management"
So, in your case, you can add the dev-pkgs on it.
Also… judging by your response, you need to have static libraries generated by Yocto, right?
If that is the point, you can do that by adding staticdev-pkgs to EXTRA_IMAGE_FEATURES as well.
Either way, It’s not advisable to compile things on target, if that is what you are trying to do.
You’ll end up with a huge image, plus the computational overhead of the compilation on the target itself.
The best approach is to generate a SDK with your environment, configuring the required kind of pkgs through SDKIMAGE_FEATURES_append on local.conf, plus executing:
bitbake my-image -fc populate_sdk
Then, you use this SDK as a reference for development on your host machine, for cross-compiling your app to be deployed to your target.
Best regards,
André Curvello
Thank you for your guide, but did you actually check what’s inside those packages? Say I could with some tension agree that src packages are useful for debugging. Always, say 20 years ago src packages provided full source code without exceptions. I mean something essential like makefile was present in those packages, which allowed to easily rebuild from sources. Do you imply it is not true any more? Here’s libusb-1.0 Yocto src package, please see missing makefile:
edward@edward-VirtualBox:~/oe-core5/build/deploy/ipk/armv7at2hf-neon$ dpkg -c libusb-1.0-src_1.0.22-r0_armv7at2hf-neon.ipk
drwxr-xr-x root/root 0 2018-03-25 04:19 ./usr/
drwxr-xr-x root/root 0 2018-03-25 04:19 ./usr/src/
drwxr-xr-x root/root 0 2018-03-25 04:19 ./usr/src/debug/
drwxr-xr-x root/root 0 2018-03-25 04:19 ./usr/src/debug/libusb1/
drwxr-xr-x root/root 0 2018-03-25 04:19 ./usr/src/debug/libusb1/1.0.22-r0/
drwxr-xr-x root/root 0 2018-03-25 04:19 ./usr/src/debug/libusb1/1.0.22-r0/libusb-1.0.22/
drwxr-xr-x root/root 0 2018-03-25 04:19 ./usr/src/debug/libusb1/1.0.22-r0/libusb-1.0.22/libusb/
-rw-r--r-- root/root 88562 2018-03-17 09:23 ./usr/src/debug/libusb1/1.0.22-r0/libusb-1.0.22/libusb/core.c
-rw-r--r-- root/root 35752 2018-03-17 09:23 ./usr/src/debug/libusb1/1.0.22-r0/libusb-1.0.22/libusb/descriptor.c
-rw-r--r-- root/root 12303 2018-03-17 09:23 ./usr/src/debug/libusb1/1.0.22-r0/libusb-1.0.22/libusb/hotplug.c
-rw-r--r-- root/root 3326 2018-03-17 09:23 ./usr/src/debug/libusb1/1.0.22-r0/libusb-1.0.22/libusb/hotplug.h
-rw-r--r-- root/root 107985 2018-03-17 09:23 ./usr/src/debug/libusb1/1.0.22-r0/libusb-1.0.22/libusb/io.c
-rw-r--r-- root/root 72802 2018-03-17 09:23 ./usr/src/debug/libusb1/1.0.22-r0/libusb-1.0.22/libusb/libusb.h
-rw-r--r-- root/root 41654 2018-03-17 09:23 ./usr/src/debug/libusb1/1.0.22-r0/libusb-1.0.22/libusb/libusbi.h
drwxr-xr-x root/root 0 2018-03-25 04:19 ./usr/src/debug/libusb1/1.0.22-r0/libusb-1.0.22/libusb/os/
-rw-r--r-- root/root 8479 2018-03-17 09:23 ./usr/src/debug/libusb1/1.0.22-r0/libusb-1.0.22/libusb/os/linux_udev.c
-rw-r--r-- root/root 78072 2018-03-17 09:23 ./usr/src/debug/libusb1/1.0.22-r0/libusb-1.0.22/libusb/os/linux_usbfs.c
-rw-r--r-- root/root 6057 2018-03-17 09:23 ./usr/src/debug/libusb1/1.0.22-r0/libusb-1.0.22/libusb/os/linux_usbfs.h
-rw-r--r-- root/root 2231 2018-03-17 09:23 ./usr/src/debug/libusb1/1.0.22-r0/libusb-1.0.22/libusb/os/poll_posix.c
-rw-r--r-- root/root 218 2018-03-17 09:23 ./usr/src/debug/libusb1/1.0.22-r0/libusb-1.0.22/libusb/os/poll_posix.h
-rw-r--r-- root/root 2220 2018-03-17 09:23 ./usr/src/debug/libusb1/1.0.22-r0/libusb-1.0.22/libusb/os/threads_posix.c
-rw-r--r-- root/root 2879 2018-03-17 09:23 ./usr/src/debug/libusb1/1.0.22-r0/libusb-1.0.22/libusb/os/threads_posix.h
-rw-r--r-- root/root 7483 2018-03-17 09:23 ./usr/src/debug/libusb1/1.0.22-r0/libusb-1.0.22/libusb/strerror.c
-rw-r--r-- root/root 12094 2018-03-17 09:23 ./usr/src/debug/libusb1/1.0.22-r0/libusb-1.0.22/libusb/sync.c
edward@edward-VirtualBox:~/oe-core5/build/deploy/ipk/armv7at2hf-neon$
The sme regarding dev packages. 20 years ago they included not only header files but as well gcc link libraries *.a. Contents of Yocto libusb-1.0 dev package, please see missing *.a:
edward@edward-VirtualBox:~/oe-core5/build/deploy/ipk/armv7at2hf-neon$ dpkg -c libusb-1.0-dev_1.0.22-r0_armv7at2hf-neon.ipk
drwxr-xr-x root/root 0 2018-03-25 04:19 ./lib/
lrwxrwxrwx root/root 0 2018-03-25 04:19 ./lib/libusb-1.0.so -> libusb-1.0.so.0.1.0
drwxr-xr-x root/root 0 2018-03-25 04:19 ./usr/
drwxr-xr-x root/root 0 2018-03-25 04:19 ./usr/include/
drwxr-xr-x root/root 0 2018-03-25 04:19 ./usr/include/libusb-1.0/
-rw-r--r-- root/root 72802 2018-03-25 04:19 ./usr/include/libusb-1.0/libusb.h
drwxr-xr-x root/root 0 2018-03-25 04:19 ./usr/lib/
drwxr-xr-x root/root 0 2018-03-25 04:19 ./usr/lib/pkgconfig/
-rw-r--r-- root/root 302 2018-03-25 04:19 ./usr/lib/pkgconfig/libusb-1.0.pc
edward@edward-VirtualBox:~/oe-core5/build/deploy/ipk/armv7at2hf-neon$
Condents of Ubuntu libusb-1.0 dev package, please see *.a present:
edward@edward-VirtualBox:~$ dpkg-query -L libusb-1.0-0-dev
/.
/usr
/usr/include
/usr/include/libusb-1.0
/usr/include/libusb-1.0/libusb.h
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libusb-1.0.a
/usr/lib/x86_64-linux-gnu/pkgconfig
/usr/lib/x86_64-linux-gnu/pkgconfig/libusb-1.0.pc
/usr/share
/usr/share/doc
/usr/share/doc/libusb-1.0-0-dev
/usr/share/doc/libusb-1.0-0-dev/copyright
/usr/lib/x86_64-linux-gnu/libusb-1.0.so
/usr/share/doc/libusb-1.0-0-dev/README
/usr/share/doc/libusb-1.0-0-dev/changelog.Debian.gz
edward@edward-VirtualBox:~$
Do you still think such dev package with missing *.a are useful? Could you share how?
Either way it is faster to quickly compile something on target rather then going through bb layers mods, bitbake, etc, It’s sad yocto baked packages are not useful for this.
Thank you very much for your help. It’s sad part of source files, like makefiles, .config files, etc are removed from src packages. Well, OK, they are meant just to provide *.c and *.h files for debugging.
Clearly i’ll use DISABLE_STATIC = " " next time. With static libs removed many if not the most of dev- packages for me still are rendered useless. Perhaps I lose couple more minutes on full build but save time compiling on target, still better than git cloning and remaking all dependency libs.
Best regards,
Edward
P.S. I understand Yocto is meant embedded. But ~GHz Cortex, even single core is still much better then something like 33MHz i386 :-). That’s for response why to build on target. I don’t need that for everyday coding, but sometimes it’s way faster to rebuild something on target rather than going through Yocto.
Hi @Edward,
Yes, yes… I understand that for both the “useless resources” and about the native compilation on target 
Best regards,
André Curvello
Hi @Edward,
Yocto does not generate the static libraries by default (packages -staticdev).
You can enable it by adding the following line in the desired recipe:
DISABLE_STATIC_pn-libusb1 = " "
Or globally for all recipes at local.conf:
DISABLE_STATIC = " "
I did a quick check about these topics with my colleagues, and I came to know that Yocto does not pack the build scripts by default.
That explains what you are seeing.
Is there anything else I could help you with?
Best regards,
André Curvello
Hi Edward,
Thanks for reaching out to Toradex support.
Which carrier board are you using with the Colibri iMX7?
Can you provide some detailed information about your issue? I see you’re trying to use pre-build images, to skip the cross compiling process. Which step is failing?
Best Regards
Kevin