[yocto] cmake toolchain file missing in SDK
Hallo Yocto developpers! Since my last SDK release, I cannot cross compile applications with cmake. I'm using yocto sumo. I get this error: build$ cmake ../ CMake Error at /opt/comet-linux/0.0.0-2018.06-last-guy/sysroots/x86_64-cometsdk-linux/usr/share/cmake-3.10/Modules/CMakeDetermineSystem.cmake:100 (message): Could not find toolchain file: /opt/comet-linux/0.0.0-2018.06-last-guy/sysroots/x86_64-cometsdk-linux/usr/share/cmake/OEToolchainConfig.cmake Call Stack (most recent call first): CMakeLists.txt:2 (project) CMake Error: CMake was unable to find a build program corresponding to "Unix Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool. CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage -- Configuring incomplete, errors occurred! It seems that the folder "cmake" is missing: $ ls /opt/comet-linux/0.0.0-2018.06-last-guy/sysroots/x86_64-cometsdk-linux/usr/share/ X11 aclocal aclocal-1.15 autoconf automake-1.15 ca-certificates cmake-3.10 device_table-minimal.txt gdb gnu-config libtool locale mime opkg qemu However, it was working with a previous release ??!! And it seems to be installed in the cmake recipe: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/cmake/cmake_3.10.3.bb#n38 Has someone already faced this problem? What am I doing wrong? Kind regards, Guy -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] cmake toolchain file missing in SDK
If I copy the missing toolchain file (meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake) manually into the extracted SDK, this fixes the issue. But why was it not deployed automatically by yocto? Regards, Guy On 06/27/18 12:31, Guy Morand wrote: Hallo Yocto developpers! Since my last SDK release, I cannot cross compile applications with cmake. I'm using yocto sumo. I get this error: build$ cmake ../ CMake Error at /opt/comet-linux/0.0.0-2018.06-last-guy/sysroots/x86_64-cometsdk-linux/usr/share/cmake-3.10/Modules/CMakeDetermineSystem.cmake:100 (message): Could not find toolchain file: /opt/comet-linux/0.0.0-2018.06-last-guy/sysroots/x86_64-cometsdk-linux/usr/share/cmake/OEToolchainConfig.cmake Call Stack (most recent call first): CMakeLists.txt:2 (project) CMake Error: CMake was unable to find a build program corresponding to "Unix Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool. CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage -- Configuring incomplete, errors occurred! It seems that the folder "cmake" is missing: $ ls /opt/comet-linux/0.0.0-2018.06-last-guy/sysroots/x86_64-cometsdk-linux/usr/share/ X11 aclocal aclocal-1.15 autoconf automake-1.15 ca-certificates cmake-3.10 device_table-minimal.txt gdb gnu-config libtool locale mime opkg qemu However, it was working with a previous release ??!! And it seems to be installed in the cmake recipe: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/cmake/cmake_3.10.3.bb#n38 Has someone already faced this problem? What am I doing wrong? Kind regards, Guy -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] cmake / no such file or directory ??!
Hello Yocto developpers! I'm facing a weird problem that seems very strange. I can cross-compile a project based on cmake with the generated Yocto SDK. However, after adding a recipe, the compilation fails: /mnt/ssd/yocto-build-script/build/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/communication-library/git-AUTOINC+f5cd493ce5-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ -Dcommunication_interface_EXPORTS -I/mnt/ssd/yocto-build-script/build/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/communication-library/git-AUTOINC+f5cd493ce5-r0/git/library -Wall -Wextra -Werror -fPIC -std=gnu++11 -MD -MT CMakeFiles/communication-interface.dir/communication_interface.cpp.o -MF CMakeFiles/communication-interface.dir/communication_interface.cpp.o.d -o CMakeFiles/communication-interface.dir/communication_interface.cpp.o -c /mnt/ssd/yocto-build-script/build/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/communication-library/git-AUTOINC+f5cd493ce5-r0/git/communication_interface.cpp | In file included from /mnt/ssd/yocto-build-script/build/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/communication-library/git-AUTOINC+f5cd493ce5-r0/git/communication_interface.cpp:1: | /mnt/ssd/yocto-build-script/build/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/communication-library/git-AUTOINC+f5cd493ce5-r0/git/library/communication_interface.h:4:10: fatal error: string: No such file or directory | #include | ^~~~ | compilation terminated. I also tried to change the cmake generator to unix makefile (who knows ...): OECMAKE_GENERATOR = "Unix Makefiles" But I have the same issue. I am working on the thud branch. Anyone had the same problem? What am I doing wrong? Best regards, Guy Morand -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] cmake / no such file or directory ??!
Sorry Yocto developers!
I have found the issue, in my CMakeLists.txt, I changed this:
set(CMAKE_CXX_FLAGS "-Wall -Wextra -Werror")
to this:
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra -Werror")
Now it works like a charm, stupid me :D! Sorry for all the noise!
Best regards,
Guy Morand
On 2/5/19 8:21 AM, Guy Morand wrote:
Hello Yocto developpers!
I'm facing a weird problem that seems very strange. I can
cross-compile a project based on cmake with the generated Yocto SDK.
However, after adding a recipe, the compilation fails:
/mnt/ssd/yocto-build-script/build/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/communication-library/git-AUTOINC+f5cd493ce5-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++
-Dcommunication_interface_EXPORTS
-I/mnt/ssd/yocto-build-script/build/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/communication-library/git-AUTOINC+f5cd493ce5-r0/git/library
-Wall -Wextra -Werror -fPIC -std=gnu++11 -MD -MT
CMakeFiles/communication-interface.dir/communication_interface.cpp.o
-MF
CMakeFiles/communication-interface.dir/communication_interface.cpp.o.d
-o
CMakeFiles/communication-interface.dir/communication_interface.cpp.o
-c
/mnt/ssd/yocto-build-script/build/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/communication-library/git-AUTOINC+f5cd493ce5-r0/git/communication_interface.cpp
| In file included from
/mnt/ssd/yocto-build-script/build/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/communication-library/git-AUTOINC+f5cd493ce5-r0/git/communication_interface.cpp:1:
|
/mnt/ssd/yocto-build-script/build/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/communication-library/git-AUTOINC+f5cd493ce5-r0/git/library/communication_interface.h:4:10:
fatal error: string: No such file or directory
| #include
| ^~~~
| compilation terminated.
I also tried to change the cmake generator to unix makefile (who knows
...):
OECMAKE_GENERATOR = "Unix Makefiles"
But I have the same issue. I am working on the thud branch. Anyone had
the same problem? What am I doing wrong?
Best regards,
Guy Morand
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Makefile library and debian naming
Hallo Yocto developpers!
I'm trying to build a Makefile based library. The recipe looks like this:
---[recipe mesages.bb]---
# SNIP recipe header
do_compile() {
oe_runmake LDFLAGS="${LDFLAGS}" shared-lib
oe_runmake LDFLAGS="${LDFLAGS}" static-lib
}
do_install() {
oe_runmake install DESTDIR=${D}${prefix}
# Fix pkg-config
sed -i 's,${D},,g' ${D}/usr/lib/pkgconfig/messages.pc
# FIXME: Try to make a debian package libmessages instead
# This avoids errors when installing an app linking with this library!
rm ${D}/${libdir}/lib${PN}.so
}
---[/recipe mesages.bb]---
The resulted image in WORKDIR looks like this:
---[WORKDIR/image]---
image/usr/lib/libmessages.so.0.3.0
image/usr/lib/libmessages.so.0
image/usr/lib/libmessages.a
image/usr/lib/pkgconfig/messages.pc
image/usr/include/messages/
---[/WORKDIR/image]---
The generated ipk packages are:
---[ipks]---
messages-dev_git.ipk
messages_git.ipk
messages-staticdev_git.ipk
messages-dbg_git.ipk
---[/ipks]---
The problem is that an application compiled with this library links
against the static library. If I don't remove the .so file from the
recipe, my application fails installing:
---[bitbake error]---
ERROR: myApp do_package_qa: QA Issue: /usr/bin/myApp contained in
package myApp requires libmessages.so, but no providers found in
RDEPENDS_myApp? [file-rdeps]
---[/bitbake error]---
Probably because the .so gets packed in the messages-dev.ipk ...
The strange thing is that I would expect a generated ipk with debian
naming such as:
libmessages_git.ipk
libmessages-dbg_git.ipk
libmessages-dev_git.ipk
libmessages-staticdev_git.ipk
I have other libraries based on cmake and everything works as expected!
Despite the recipe already inherits "debian", explicitly inheriting this
class doesn't help.
What am I doing wrong?
Guy Morand
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Makefile library and debian naming
Ross,
Thanks for your quick reply!
No, I don't inherit debian and wish I could leave the so file as is, it
was just a quick and dirty hack to compile my image.
> Another indication of this is the lack of renaming. Look at
> the makefile, specifically the specified soname.
The Makefile is written by myself. The library is built as follow:
$(SHARED_OUT_DIR)/%.o: %.c
$(CC) $(CFLAGS) -fPIC -c -o $@ $<
$(SHARED_OUT_DIR)/$(SHARED_LIB_NAME): $(SHARED_OBJS)
$(CC) -shared $(LDFLAGS) $(SHARED_OBJS) -o $@
What do you mean with "lack of renaming", do you have some pointers?
Something with LDFLAGS? What is the specified "soname"?
Guy
On 11/21/2017 02:13 PM, Burton, Ross wrote:
You don't need to inherit debian in a recipe, that is meant to be a
distro-level inherit (and is inherited out of the box).
Deleting the .so breaks non-static linking as that is the file which is
used to link against, so don't delete it. It should be in the -dev package.
The QA error is probably because your library is built wrong in the
makefile. Another indication of this is the lack of renaming. Look at
the makefile, specifically the specified soname.
Ross
On 21 November 2017 at 13:00, Guy Morand <mailto:g...@guy-morand.ch>> wrote:
Hallo Yocto developpers!
I'm trying to build a Makefile based library. The recipe looks like
this:
---[recipe mesages.bb <http://mesages.bb>]---
# SNIP recipe header
do_compile() {
oe_runmake LDFLAGS="${LDFLAGS}" shared-lib
oe_runmake LDFLAGS="${LDFLAGS}" static-lib
}
do_install() {
oe_runmake install DESTDIR=${D}${prefix}
# Fix pkg-config
sed -i 's,${D},,g' ${D}/usr/lib/pkgconfig/messages.pc
# FIXME: Try to make a debian package libmessages instead
# This avoids errors when installing an app linking with this
library!
rm ${D}/${libdir}/lib${PN}.so
}
---[/recipe mesages.bb <http://mesages.bb>]---
The resulted image in WORKDIR looks like this:
---[WORKDIR/image]---
image/usr/lib/libmessages.so.0.3.0
image/usr/lib/libmessages.so.0
image/usr/lib/libmessages.a
image/usr/lib/pkgconfig/messages.pc
image/usr/include/messages/
---[/WORKDIR/image]---
The generated ipk packages are:
---[ipks]---
messages-dev_git.ipk
messages_git.ipk
messages-staticdev_git.ipk
messages-dbg_git.ipk
---[/ipks]---
The problem is that an application compiled with this library links
against the static library. If I don't remove the .so file from the
recipe, my application fails installing:
---[bitbake error]---
ERROR: myApp do_package_qa: QA Issue: /usr/bin/myApp contained in
package myApp requires libmessages.so, but no providers found in
RDEPENDS_myApp? [file-rdeps]
---[/bitbake error]---
Probably because the .so gets packed in the messages-dev.ipk ...
The strange thing is that I would expect a generated ipk with debian
naming such as:
libmessages_git.ipk
libmessages-dbg_git.ipk
libmessages-dev_git.ipk
libmessages-staticdev_git.ipk
I have other libraries based on cmake and everything works as expected!
Despite the recipe already inherits "debian", explicitly inheriting
this class doesn't help.
What am I doing wrong?
Guy Morand
--
___
yocto mailing list
yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto
<https://lists.yoctoproject.org/listinfo/yocto>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Makefile library and debian naming
Ok a quick search on the Internet and I've found out that I probably
miss some linker parameters such as:
-Wl,-soname,libmessages.so.0
Great, I have the feeling I learned something important today!
Thanks for the pointers!
Guy
On 11/21/2017 02:22 PM, Guy Morand wrote:
Ross,
Thanks for your quick reply!
No, I don't inherit debian and wish I could leave the so file as is, it
was just a quick and dirty hack to compile my image.
> Another indication of this is the lack of renaming. Look at
> the makefile, specifically the specified soname.
The Makefile is written by myself. The library is built as follow:
$(SHARED_OUT_DIR)/%.o: %.c
$(CC) $(CFLAGS) -fPIC -c -o $@ $<
$(SHARED_OUT_DIR)/$(SHARED_LIB_NAME): $(SHARED_OBJS)
$(CC) -shared $(LDFLAGS) $(SHARED_OBJS) -o $@
What do you mean with "lack of renaming", do you have some pointers?
Something with LDFLAGS? What is the specified "soname"?
Guy
On 11/21/2017 02:13 PM, Burton, Ross wrote:
You don't need to inherit debian in a recipe, that is meant to be a
distro-level inherit (and is inherited out of the box).
Deleting the .so breaks non-static linking as that is the file which
is used to link against, so don't delete it. It should be in the -dev
package.
The QA error is probably because your library is built wrong in the
makefile. Another indication of this is the lack of renaming. Look
at the makefile, specifically the specified soname.
Ross
On 21 November 2017 at 13:00, Guy Morand <mailto:g...@guy-morand.ch>> wrote:
Hallo Yocto developpers!
I'm trying to build a Makefile based library. The recipe looks like
this:
---[recipe mesages.bb <http://mesages.bb>]---
# SNIP recipe header
do_compile() {
oe_runmake LDFLAGS="${LDFLAGS}" shared-lib
oe_runmake LDFLAGS="${LDFLAGS}" static-lib
}
do_install() {
oe_runmake install DESTDIR=${D}${prefix}
# Fix pkg-config
sed -i 's,${D},,g' ${D}/usr/lib/pkgconfig/messages.pc
# FIXME: Try to make a debian package libmessages instead
# This avoids errors when installing an app linking with this
library!
rm ${D}/${libdir}/lib${PN}.so
}
---[/recipe mesages.bb <http://mesages.bb>]---
The resulted image in WORKDIR looks like this:
---[WORKDIR/image]---
image/usr/lib/libmessages.so.0.3.0
image/usr/lib/libmessages.so.0
image/usr/lib/libmessages.a
image/usr/lib/pkgconfig/messages.pc
image/usr/include/messages/
---[/WORKDIR/image]---
The generated ipk packages are:
---[ipks]---
messages-dev_git.ipk
messages_git.ipk
messages-staticdev_git.ipk
messages-dbg_git.ipk
---[/ipks]---
The problem is that an application compiled with this library links
against the static library. If I don't remove the .so file from the
recipe, my application fails installing:
---[bitbake error]---
ERROR: myApp do_package_qa: QA Issue: /usr/bin/myApp contained in
package myApp requires libmessages.so, but no providers found in
RDEPENDS_myApp? [file-rdeps]
---[/bitbake error]---
Probably because the .so gets packed in the messages-dev.ipk ...
The strange thing is that I would expect a generated ipk with debian
naming such as:
libmessages_git.ipk
libmessages-dbg_git.ipk
libmessages-dev_git.ipk
libmessages-staticdev_git.ipk
I have other libraries based on cmake and everything works as
expected!
Despite the recipe already inherits "debian", explicitly inheriting
this class doesn't help.
What am I doing wrong?
Guy Morand
-- ___
yocto mailing list
yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto
<https://lists.yoctoproject.org/listinfo/yocto>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Kernel module depedency (header+symbols)
Hallo Yocto developpers,
I have been struggling a little to write recipe with kernel modules
depedency. It seems that this is not well documented and picked up some
solution across the mailing list and by reading the source. That is why
I'm wondering if my approach is correct or hopefully will help someone
else who tries to achieve the same thing...
First I have a modules that provides an header file with exported symbols:
---[base-module.h]---
extern int base_module_something(void);
---[/base-module.h]---
Where the function is exported in the c file:
---[base-module.c]---
int base_module_something(void)
{
/* something */
return 0;
}
EXPORT_SYMBOL(base_module_something);
---[/base-module.c]---
Now it seems that I have to prepend my recipe name with "kernel-module-"
(cf.later) and add the header file installation:
---[kernel-module-base-module.bb]---
do_install_append() {
install -m 0664 ${S}/base-module.h ${D}/${includedir}/${PN}
}
---[/kernel-module-base-module.bb]---
In the second module, I added an argument to find the path to the base
module header file:
---[Kbuild second module]---
ccflags-y += -I$(BASE_MODULE_PATH)
---[/Kbuild second module]---
In the recipe of the second module, I give the dependency to my
base-module and pass the variable to find the header file:
---[second-module.bb]---
DEPENDS = "kernel-module-base-module"
do_compile_prepend() {
export BASE_MODULE_PATH=${STAGING_INCDIR}/kernel-module-base-module/"
}
---[/second-module.bb]---
The reason to have the first module prepended with "kernel-module" is
that the bbclass looks for Module.symvers file for depedency with that
name and adapt the KBUILD_EXTRA_SYMBOLS consequently:
https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/module.bbclass#n12
Despite this solution works for me, I was wondering if this is the right
approach and if there is a more "yocto way"?
Best regards,
Guy
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
