SDK包含了開發時所需的相關檔案，有些還包含了整個開發環境(tool/command)，避免系統的tool/command跟SDK需要的不同造成的error，一個SDK應該包含以下內容：(YOCTO Slides)
- Compilers or cross-compilers
- Linkers
- Library headers
- Debuggers
- Custom utilities
這篇文章就是在介紹如何使用Openembedded建立一個generic SDK供他人開發application，使用指令bitbake -v meta-toolchain即可產生generic SDK，並產生一個install的script，放置於oe/oe-core/build/tmp-eglibc/deploy/sdk/底下，執行過程如下
brook@vista:/home/brook/oe/oe-core/build$ bitbake -v meta-toolchain ... + chmod +x /home/brook/oe/oe-core/build/tmp-eglibc/deploy/sdk/oecore-x86_64-armv7a-vfp-neon-toolchain-oe-core.0.sh + cat /home/brook/oe/oe-core/build/tmp-eglibc/deploy/sdk/oecore-x86_64-armv7a-vfp-neon-toolchain-oe-core.0.tar.bz2 + rm /home/brook/oe/oe-core/build/tmp-eglibc/deploy/sdk/oecore-x86_64-armv7a-vfp-neon-toolchain-oe-core.0.tar.bz2 NOTE: Tasks Summary: Attempted 1685 tasks of which 1312 didn't need to be rerun and all succeeded. brook@vista:/home/brook/oe/oe-core/build$ tree tmp-eglibc/deploy/sdk/ tmp-eglibc/deploy/sdk/ `-- oecore-x86_64-armv7a-vfp-neon-toolchain-oe-core.0.sh 0 directories, 1 file
接著直要將底下的script(oecore-x86_64-armv7a-vfp-neon-toolchain-oe-core.0.sh)給developer開發即可，-d後面帶安裝目錄，安裝過程需要SUDO權限，
brook@vista:/home/brook/oe/oe-core/build$ ./tmp-eglibc/deploy/sdk/oecore-x86_64-armv7a-vfp-neon-toolchain-oe-core.0.sh --help Usage: oecore-x86_64-armv7a-vfp-neon-toolchain-oe-core.0.sh [-y] [-d <dir>] -y Automatic yes to all prompts -d <dir> Install the SDK to <dir> ======== Advanced DEBUGGING ONLY OPTIONS ======== -S Save relocation scripts -R Do not relocate executables -D use set -x to see what is going on brook@vista:~$ /home/brook/oe/oe-core/build/tmp-eglibc/deploy/sdk/oecore-x86_64-armv7a-vfp-neon-toolchain-oe-core.0.sh -d /opt/oe -D + printf 'Enter target directory for SDK (default: /usr/local/oecore-x86_64): ' Enter target directory for SDK (default: /usr/local/oecore-x86_64): + '[' /opt/oe = '' ']' + echo /opt/oe /opt/oe ... + '[' 0 = 0 ']' + /usr/bin/sudo rm /SSD/opt/oe/relocate_sdk.py /SSD/opt/oe/relocate_sdk.sh + echo 'SDK has been successfully set up and is ready to be used.' SDK has been successfully set up and is ready to be used. + exit 0
要使用SDK之前，必須先source安裝目錄下開頭為environment-setup-的script，設置相關的環境變數，我的script內容如下
export PATH=/SSD/opt/oe/sysroots/x86_64-oesdk-linux/usr/bin:/SSD/opt/oe/sysroots/x86_64-oesdk-linux/usr/bin/armv 7a-vfp-neon-oe-linux-gnueabi:$PATH export PKG_CONFIG_SYSROOT_DIR=/SSD/opt/oe/sysroots/armv7a-vfp-neon-oe-linux-gnueabi export PKG_CONFIG_PATH=/SSD/opt/oe/sysroots/armv7a-vfp-neon-oe-linux-gnueabi/usr/lib/pkgconfig export CONFIG_SITE=/SSD/opt/oe/site-config-armv7a-vfp-neon-oe-linux-gnueabi export CC="arm-oe-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mthumb-inte rwork --sysroot=/SSD/opt/oe/sysroots/armv7a-vfp-neon-oe-linux-gnueabi" export CXX="arm-oe-linux-gnueabi-g++ -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mthumb-int erwork --sysroot=/SSD/opt/oe/sysroots/armv7a-vfp-neon-oe-linux-gnueabi" export CPP="arm-oe-linux-gnueabi-gcc -E -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mthumb-interwork --sysroot=/SSD/opt/oe/sysroots/armv7a-vfp-neon-oe-linux-gnueabi" export AS="arm-oe-linux-gnueabi-as " export LD="arm-oe-linux-gnueabi-ld --sysroot=/SSD/opt/oe/sysroots/armv7a-vfp-neon-oe-linux-gnueabi" export GDB=arm-oe-linux-gnueabi-gdb export STRIP=arm-oe-linux-gnueabi-strip export RANLIB=arm-oe-linux-gnueabi-ranlib export OBJCOPY=arm-oe-linux-gnueabi-objcopy export OBJDUMP=arm-oe-linux-gnueabi-objdump export AR=arm-oe-linux-gnueabi-ar export NM=arm-oe-linux-gnueabi-nm export M4=m4 export TARGET_PREFIX=arm-oe-linux-gnueabi- export CONFIGURE_FLAGS="--target=arm-oe-linux-gnueabi --host=arm-oe-linux-gnueabi --build=x86_64-linux --with-libtool-sysroot=/SSD/opt/oe/sysroots/armv7a-vfp-neon-oe-linux-gnueabi" export CFLAGS=" -O2 -fexpensive-optimizations -frename-registers -fomit-frame-pointer" export CXXFLAGS=" -O2 -fexpensive-optimizations -frename-registers -fomit-frame-pointer -fpermissive" export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed" export CPPFLAGS="" export OECORE_NATIVE_SYSROOT="/SSD/opt/oe/sysroots/x86_64-oesdk-linux" export OECORE_TARGET_SYSROOT="/SSD/opt/oe/sysroots/armv7a-vfp-neon-oe-linux-gnueabi" export OECORE_ACLOCAL_OPTS="-I /SSD/opt/oe/sysroots/x86_64-oesdk-linux/usr/share/aclocal" export OECORE_DISTRO_VERSION="20151225" export OECORE_SDK_VERSION="oe-core.0" export PYTHONHOME=/SSD/opt/oe/sysroots/x86_64-oesdk-linux/usr export ARCH=arm export CROSS_COMPILE=arm-oe-linux-gnueabi-
以下是我用這SDK編譯一個檔案，並放入target中執行
brook@vista:~$ source /opt/oe/environment-setup-armv7a-vfp-neon-oe-linux-gnueabi
brook@vista:~$ cat main.c
#include <stdio.h>
int main(int argc, char *argv[])
{
printf("hello\n");
return 0;
}
brook@vista:~$ $CC -o brook-sdk main.c
D:\Projects>adb push z:\brook-sdk /
688 KB/s (5644 bytes in 0.008s)
D:\Projects>adb shell chmod +x /brook-sdk
D:\Projects>adb shell /brook-sdk
hello
開發環境架構圖
dump GCC preprocessor defines
回覆刪除"${CC} -dM -E - < /dev/null"
參考資料：http://stackoverflow.com/questions/2224334/gcc-dump-preprocessor-defines
PACKAGE_SNAP_LIB_SYMLINKS is enabled.
回覆刪除Runtime optimisation of shared object libraries is used when you use PACKAGE_SNAP_LIB_SYMLINKS = "1" in distribution configuration file. It causes removal of symbolic link indirection in final image thus speeding up loading of shared library object as well as saving inode and directory entry in file system.
diff --git a/apps_proc/oe-core/meta/recipes-devtools/json-c/json-c_0.12.bb b/apps_proc/oe-core/meta/recipes-devtools/json-c/json-c_0.12.bb
刪除index 1a5c394..222c7b6 100644
--- a/apps_proc/oe-core/meta/recipes-devtools/json-c/json-c_0.12.bb
+++ b/apps_proc/oe-core/meta/recipes-devtools/json-c/json-c_0.12.bb
@@ -27,3 +27,5 @@ do_configure_prepend() {
# Clean up autoconf cruft that should not be in the tarball
rm -f ${S}/config.status
}
+PACKAGE_SNAP_LIB_SYMLINKS = "0"
+FILES_${PN} = "${libdir}/lib*${SOLIBS}"
diff --git a/apps_proc/oe-core/meta/recipes-support/curl/curl_7.47.1.bb b/apps_proc/oe-core/meta/recipes-support/curl/curl_7.47.1.bb
index 6c71760..62d499e 100755
--- a/apps_proc/oe-core/meta/recipes-support/curl/curl_7.47.1.bb
+++ b/apps_proc/oe-core/meta/recipes-support/curl/curl_7.47.1.bb
@@ -70,3 +70,4 @@ RRECOMMENDS_lib${BPN} += "ca-certificates"
FILES_${PN} += "${datadir}/zsh"
BBCLASSEXTEND = "native nativesdk"
+PACKAGE_SNAP_LIB_SYMLINKS = "1"
-------------------------
lrwxrwxrwx 1 root root 16 Sep 7 00:27 libcurl.so -> libcurl.so.4.4.0
-rwxr-xr-x 1 root root 274848 Sep 7 00:27 libcurl.so.4
lrwxrwxrwx 1 root root 18 Sep 7 00:27 libjson-c.so -> libjson-c.so.2.0.1
lrwxrwxrwx 1 root root 18 Sep 7 00:27 libjson-c.so.2 -> libjson-c.so.2.0.1
-rwxr-xr-x 1 root root 33144 Sep 7 00:27 libjson-c.so.2.0.1
curl因為設定PACKAGE_SNAP_LIB_SYMLINKS = "1", 而導致libcurl.so.4.4.0沒有被建立,開發application會發生找不到library的問題
How do I include the linux kernel headers as part of the SDK package in Yocto?
回覆刪除https://stackoverflow.com/questions/31256770/using-populate-sdk-to-include-kernel-headers
TOOLCHAIN_TARGET_TASK_append = " kernel-devsrc"
Telling gcc directly to link a library statically
回覆刪除https://stackoverflow.com/questions/6578484/telling-gcc-directly-to-link-a-library-statically
It is possible of course, use -l: instead of -l. For example -l:libXYZ.a to link with libXYZ.a. Notice the lib written out, as opposed to -lXYZ which would auto expand to libXYZ.
By default, the previous BitBake command does not build static binaries. If you want to use the toolchain to build these types of libraries, you need to be sure your SDK has the appropriate static development libraries. Use the TOOLCHAIN_TARGET_TASK variable inside your local.conf file before building the SDK installer. Doing so ensures that the eventual SDK installation process installs the appropriate library packages as part of the SDK. Following is an example using libc static development libraries: TOOLCHAIN_TARGET_TASK:append = ” libc-staticdev”
回覆刪除