Re: [yocto] SDK install w/ CMake
Hi Eric
I don't think your issue has something do to with CMake.
> -Original Message-
> From: yocto-boun...@yoctoproject.org
> On Behalf Of Eric Schwarz
> Sent: Freitag, 1. Februar 2019 09:51
> To: yocto@yoctoproject.org
> Subject: [yocto] SDK install w/ CMake
>
> Hello,
>
> we have got the problem that w/ the Yocto recipe and CMake install targets
> as below always everything (headers and library or binary
> respectively) is installed in the SDK.
> The binary also goes into the SDK even though we just add it to
> IMAGE_INSTALL based on a XILINX yocto build (rel-v2018.3).
I'm not sure I understand what you are trying to do. If you add something to
IMAGE_INSTALL it gets installed to the target.
That usually includes binaries and libraries.
If you only want libraries but not binaries it's probably best to split them
into multiple packages as described in
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#package-splitting-dev-environment
This way you can have the binaries in a different package like ${PN}-tools.
Pascal
> For sure we only want headers to be installed when "-dev"
> is added to TOOLCHAIN_TARGET_TASK_append and the binary should not
> be installed at all when it is just added to IMAGE_INSTALL.
>
> For sure we studied Yocto and CMake recipes from other libraries where it
> works like pugixml but weren't able to figure out what's going wrong.
>
>
> Yocto recipe
>
>
> DESCRIPTION = "C++ reflection library"
> SECTION = "libs"
> LICENSE = "CLOSED"
>
> SRCREV = "${AUTOREV}"
> SRCBRANCH = "next"
> SRC_URI =
> "git://gitlab.company.de/psg/${PN}.git;branch=${SRCBRANCH};protocol=ssh
> "
>
> DEPENDS = "catch2"
>
> inherit cmake
> S = "${WORKDIR}/git"
> FILES_${PN}-dev += "${libdir}/cmake"
>
> # The following are needed because the library is unversioned.
> # See
> https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Librari
> es#Non-versioned_Libraries
> SOLIBS = ".so"
> FILES_SOLIBSDEV = ""
>
>
> CMake library install part
> ==
>
> # Shared client library target.
> add_library(shared SHARED $)
> target_include_directories(shared PUBLIC
> $
> $
> )
>
> set_target_properties(shared
> PROPERTIES
> ARCHIVE_OUTPUT_DIRECTORY lib/shared
> LIBRARY_OUTPUT_DIRECTORY lib/shared
> RUNTIME_OUTPUT_DIRECTORY lib/shared
> OUTPUT_NAME ${LIBRARY_NAME}
> )
>
> # Install target.
> install(TARGETS shared static
> EXPORT ${LIBRARY_NAME}-config
> DESTINATION ${CMAKE_INSTALL_LIBDIR})
> install(DIRECTORY include/reflect DESTINATION
> ${CMAKE_INSTALL_INCLUDEDIR})
> install(EXPORT ${LIBRARY_NAME}-config
> NAMESPACE ${LIBRARY_NAME}-
> DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/${LIBRARY_NAME})
>
>
> CMake binary install part
> =
>
> install(TARGETS ${EXECUTABLE_NAME} DESTINATION
> ${CMAKE_INSTALL_BINDIR})
>
>
> Many thanks for any hints
> Eric
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] do_populate_lic fail from scratch build but succed after clean
Hi
I have an recipe based on serialport npm package created with devtool.
I added some custom licenses in my layer with LICENSE_PATH:
# Additional license directories.
LICENSE_PATH += "${LAYERDIR}/files/common-licenses"
After this I get some inconsistent build result (or i dont understand ).
Te steps I make is the following, build from scratch then bitbake fails,
clean recipe and build recipe and it succed:
1. bitbake myLayer ->
WARNING: serialport-6.2.2-r0 do_populate_lic: Could not copy license file
/home/jonas/yocto/build/tmp/work/cortexa9hf-neon-goerlix-linux-gnueabi/serialport/6.2.2-r0/npmpkg/node_modules/prompt-list/node_modules/prompt-radio/node_modules/prompt-checkbox/node_modules/prompt-base/node_modules/readline-ui/node_modules/debug/LICENSE
to
/home/jonas/yocto/build/tmp/work/cortexa9hf-neon-goerlix-linux-gnueabi/serialport/6.2.2-r0/license-destdir/serialport/LICENSE.3:
[Errno 2] No such file or directory:
'/home/jonas/yocto/build/tmp/work/cortexa9hf-neon-goerlix-linux-gnueabi/serialport/6.2.2-r0/npmpkg/node_modules/prompt-list/node_modules/prompt-radio/node_modules/prompt-checkbox/node_modules/prompt-base/node_modules/readline-ui/node_modules/debug/LICENSE'
.
//
.
ERROR: serialport-6.2.2-r0 do_populate_lic: QA Issue: serialport:
LIC_FILES_CHKSUM points to an invalid file:
/home/jonas/yocto/build/tmp/work/cortexa9hf-neon-goerlix-linux-gnueabi/serialport/6.2.2-r0/npmpkg/node_modules/prompt-list/node_modules/prompt-radio/node_modules/prompt-checkbox/node_modules/prompt-base/node_modules/readline-ui/node_modules/debug/LICENSE
[license-checksum]
.
//
.
ERROR: serialport-6.2.2-r0 do_populate_lic: Fatal QA errors found, failing
task.
ERROR: serialport-6.2.2-r0 do_populate_lic: Function failed:
populate_lic_qa_checksum
2. bitbake serialport -c clean
3. bitbake serialport -> success
In my view it feels like different tasks is executed in different order,
like the npm recipe is missing some dependency but before I adden
LICENSE_PATH to the layer config I had no problem..
__
Build Configuration:
BB_VERSION = "1.40.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING = "universal"
TUNE_FEATURES= "arm armv7a vfp neon callconvention-hard cortexa9"
TARGET_FPU = "hard"
meta = "thud:3541f019a505d18263fad0b46b88d470e3fd9d62"
meta-oe
meta-python
meta-networking
meta-filesystems = "thud:6094ae18c8a35e5cc9998ac39869390d7f3bb1e2"
meta-yocto-bsp = "thud:3541f019a505d18263fad0b46b88d470e3fd9d62"
meta-microservicebus-node = "thud:cab931199236b5bdeeb660f64aea55c2e0c09c2b"
Best regards
Jonas
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] CMake based recipes and defining CMAKE_BUILD_TYPE
Aright thank you for checking into this, you went farther then I expected.
I will take the approach of setting it for the recipes I really care about and
leave the rest alone.
Matt S.
From: Andreas Müller
Sent: Wednesday, February 6, 2019 3:11 PM
To: Matt Schuckmann
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] CMake based recipes and defining CMAKE_BUILD_TYPE
On Wed, Feb 6, 2019 at 11:53 PM Andreas Müller wrote:
>
> On Wed, Feb 6, 2019 at 11:24 PM Andreas Müller
> wrote:
> >
> > On Wed, Feb 6, 2019 at 11:05 PM Matt Schuckmann
> > wrote:
> > >
> > > Hi Andreas,
> > >
> > > Thanks for the response, do you set build type in each recipe
> > > individually or is there some central .conf file or other other location
> > > that you set it?
> > >
> > > Matt S.
> > Honestly: I do not set them yet because I thought RelWithDebInfo is
> > default. That assumption was based on some projects but I checked now:
> > it does not seem to be something to rely on...
> >
> Will build-/run-test this with my 'world':
>
> diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
> index fd40a9863e..a8e08e6d6f 100644
> --- a/meta/classes/cmake.bbclass
> +++ b/meta/classes/cmake.bbclass
> @@ -153,6 +153,7 @@ cmake_do_configure() {
> -DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
> -DCMAKE_VERBOSE_MAKEFILE=1 \
> -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
> + -DCMAKE_BUILD_TYPE=${@d.getVar(oe.utils.vartrue('DEBUG_BUILD',
> 'Debug', 'RelWithDebInfo', d))} \
> ${EXTRA_OECMAKE} \
> -Wno-dev
> }
>
> Takes a while...
>
Not exactly: After short build I saw:
* There are some sed on '*-noconfig.cmake' they are going to break
* libeigen fails because it supports 'Debug' and 'Release' only (and I
bet there are more)
Will skip further tests and get the feeling that a common solution won't do...
Andreas
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] CMake based recipes and defining CMAKE_BUILD_TYPE
On Wed, Feb 6, 2019 at 11:53 PM Andreas Müller wrote:
>
> On Wed, Feb 6, 2019 at 11:24 PM Andreas Müller
> wrote:
> >
> > On Wed, Feb 6, 2019 at 11:05 PM Matt Schuckmann
> > wrote:
> > >
> > > Hi Andreas,
> > >
> > > Thanks for the response, do you set build type in each recipe
> > > individually or is there some central .conf file or other other location
> > > that you set it?
> > >
> > > Matt S.
> > Honestly: I do not set them yet because I thought RelWithDebInfo is
> > default. That assumption was based on some projects but I checked now:
> > it does not seem to be something to rely on...
> >
> Will build-/run-test this with my 'world':
>
> diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
> index fd40a9863e..a8e08e6d6f 100644
> --- a/meta/classes/cmake.bbclass
> +++ b/meta/classes/cmake.bbclass
> @@ -153,6 +153,7 @@ cmake_do_configure() {
> -DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
> -DCMAKE_VERBOSE_MAKEFILE=1 \
> -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
> + -DCMAKE_BUILD_TYPE=${@d.getVar(oe.utils.vartrue('DEBUG_BUILD',
> 'Debug', 'RelWithDebInfo', d))} \
> ${EXTRA_OECMAKE} \
> -Wno-dev
> }
>
> Takes a while...
>
Not exactly: After short build I saw:
* There are some sed on '*-noconfig.cmake' they are going to break
* libeigen fails because it supports 'Debug' and 'Release' only (and I
bet there are more)
Will skip further tests and get the feeling that a common solution won't do...
Andreas
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 00/10] Misc fixes (cover letter only)
Oops, yes, I forgot the [layerindex-web], my apologies. I can cc the oe-devel list if people really want to see it there as well; up to this point we've been using this list only. The other option would be a dedicated list but I suspect that would have a very limited subscription. Cheers, Paul On Thursday, 7 February 2019 11:24:24 AM NZDT akuster wrote: > > Hello Paul. > > On 2/6/19 2:00 PM, Paul Eggleton wrote: > > The following changes since commit 61e9b048591adab88d1996646286e1d7df024bea: > > > > Fix drop-down alignment on duplicates page (2018-11-20 11:58:42 +1300) > > > > are available in the Git repository at: > > > > git://git.yoctoproject.org/layerindex-web paule/fixes12 > > http://git.yoctoproject.org/cgit.cgi/layerindex-web/log/?h=paule/fixes12 > > > > Paul Eggleton (10): > > Send people an email when another user adds them as a maintainer > > Add links to other branch recipes in recipe detail > > Fix errors due to races deleting bitbake temp files > > local.conf: allow for upstream_tracking.inc to be missing > > Use try...finally or with to ensure files get closed > > Replace use of assert with exceptions > > docker: add wget to dependencies > > RRS: fix sorting arrow positioning > > rrs_maintainer_history: check out layer branch before looking for > > maintainers.inc > > RRS: add tool to import/export upstream history data > > Thanks for the updates and fixes. This is a very useful tool to both YP > and OE. > > I had to look at what was actual changes to figure out what this patch > set was against. Should we change the "subject" to help clarify? ie > [layer-index][PATCH ...? > > The layer index is hosted on OE. Should one of the OE mailing be CC'ed?? > > Yes I realize the sources are hosted on YP but the url for the tool is > http://layers.openembedded.org. can be confusing. > > kind regards, > Armin > > > > Dockerfile | 1 + > > conf/local.conf| 2 +- > > layerindex/bulkchange.py | 18 +- > > layerindex/update.py | 4 +- > > layerindex/update_layer.py | 14 +- > > layerindex/utils.py| 21 ++- > > layerindex/views.py| 70 ++-- > > rrs/tools/historytool.py | 196 + > > rrs/tools/rrs_distros.py | 19 +- > > rrs/tools/rrs_maintainer_history.py| 45 ++--- > > rrs/tools/rrs_upgrade_history.py | 4 +- > > rrs/tools/rrs_upstream_history.py | 3 +- > > rrs/tools/upgrade_history_internal.py | 3 +- > > rrs/views.py | 2 + > > templates/layerindex/maintemail.txt| 9 + > > templates/layerindex/maintemailsubject.txt | 1 + > > templates/layerindex/recipedetail.html | 27 +++ > > templates/rrs/maintainers.html | 2 +- > > templates/rrs/recipedetail.html| 27 +++ > > templates/rrs/recipes.html | 2 +- > > 20 files changed, 392 insertions(+), 78 deletions(-) > > create mode 100755 rrs/tools/historytool.py > > create mode 100644 templates/layerindex/maintemail.txt > > create mode 100644 templates/layerindex/maintemailsubject.txt > > > > -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] CMake based recipes and defining CMAKE_BUILD_TYPE
On Wed, Feb 6, 2019 at 11:24 PM Andreas Müller wrote:
>
> On Wed, Feb 6, 2019 at 11:05 PM Matt Schuckmann
> wrote:
> >
> > Hi Andreas,
> >
> > Thanks for the response, do you set build type in each recipe individually
> > or is there some central .conf file or other other location that you set it?
> >
> > Matt S.
> Honestly: I do not set them yet because I thought RelWithDebInfo is
> default. That assumption was based on some projects but I checked now:
> it does not seem to be something to rely on...
>
Will build-/run-test this with my 'world':
diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index fd40a9863e..a8e08e6d6f 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -153,6 +153,7 @@ cmake_do_configure() {
-DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
-DCMAKE_VERBOSE_MAKEFILE=1 \
-DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
+ -DCMAKE_BUILD_TYPE=${@d.getVar(oe.utils.vartrue('DEBUG_BUILD',
'Debug', 'RelWithDebInfo', d))} \
${EXTRA_OECMAKE} \
-Wno-dev
}
Takes a while...
Andreas
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 00/10] Misc fixes (cover letter only)
Hello Paul. On 2/6/19 2:00 PM, Paul Eggleton wrote: > The following changes since commit 61e9b048591adab88d1996646286e1d7df024bea: > > Fix drop-down alignment on duplicates page (2018-11-20 11:58:42 +1300) > > are available in the Git repository at: > > git://git.yoctoproject.org/layerindex-web paule/fixes12 > http://git.yoctoproject.org/cgit.cgi/layerindex-web/log/?h=paule/fixes12 > > Paul Eggleton (10): > Send people an email when another user adds them as a maintainer > Add links to other branch recipes in recipe detail > Fix errors due to races deleting bitbake temp files > local.conf: allow for upstream_tracking.inc to be missing > Use try...finally or with to ensure files get closed > Replace use of assert with exceptions > docker: add wget to dependencies > RRS: fix sorting arrow positioning > rrs_maintainer_history: check out layer branch before looking for > maintainers.inc > RRS: add tool to import/export upstream history data Thanks for the updates and fixes. This is a very useful tool to both YP and OE. I had to look at what was actual changes to figure out what this patch set was against. Should we change the "subject" to help clarify? ie [layer-index][PATCH ...? The layer index is hosted on OE. Should one of the OE mailing be CC'ed?? Yes I realize the sources are hosted on YP but the url for the tool is http://layers.openembedded.org. can be confusing. kind regards, Armin > > Dockerfile | 1 + > conf/local.conf| 2 +- > layerindex/bulkchange.py | 18 +- > layerindex/update.py | 4 +- > layerindex/update_layer.py | 14 +- > layerindex/utils.py| 21 ++- > layerindex/views.py| 70 ++-- > rrs/tools/historytool.py | 196 + > rrs/tools/rrs_distros.py | 19 +- > rrs/tools/rrs_maintainer_history.py| 45 ++--- > rrs/tools/rrs_upgrade_history.py | 4 +- > rrs/tools/rrs_upstream_history.py | 3 +- > rrs/tools/upgrade_history_internal.py | 3 +- > rrs/views.py | 2 + > templates/layerindex/maintemail.txt| 9 + > templates/layerindex/maintemailsubject.txt | 1 + > templates/layerindex/recipedetail.html | 27 +++ > templates/rrs/maintainers.html | 2 +- > templates/rrs/recipedetail.html| 27 +++ > templates/rrs/recipes.html | 2 +- > 20 files changed, 392 insertions(+), 78 deletions(-) > create mode 100755 rrs/tools/historytool.py > create mode 100644 templates/layerindex/maintemail.txt > create mode 100644 templates/layerindex/maintemailsubject.txt > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] CMake based recipes and defining CMAKE_BUILD_TYPE
On Wed, Feb 6, 2019 at 11:05 PM Matt Schuckmann wrote: > > Hi Andreas, > > Thanks for the response, do you set build type in each recipe individually or > is there some central .conf file or other other location that you set it? > > Matt S. Honestly: I do not set them yet because I thought RelWithDebInfo is default. That assumption was based on some projects but I checked now: it does not seem to be something to rely on... Andreas -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] CMake based recipes and defining CMAKE_BUILD_TYPE
Hi Andreas, Thanks for the response, do you set build type in each recipe individually or is there some central .conf file or other other location that you set it? Matt S. From: Andreas Müller Sent: Wednesday, February 6, 2019 1:31 PM To: Matt Schuckmann Cc: yocto@yoctoproject.org Subject: Re: [yocto] CMake based recipes and defining CMAKE_BUILD_TYPE On Wed, Feb 6, 2019 at 7:39 PM Matt Schuckmann wrote: > > I'm trying to understand why the cmake.bbclass doesn't make any attempt to > set CMAKE_BUILD_TYPE and what the design philosophy behind that is? > > On the surface I would expect that the default build type would be Release > but I can see how that might not always be the right choice. I'm really > surprised that there isn't a global variable that can be set for this, am I > missing something, or is it really expected that each recipe provide it if > they care? > > > FYI I started looking into this when I realized that NDEBUG is not set for > many (if not all) of my CMake based recipes and thus asserts are still > enabled in my production code. This appears to be known behavior for CMake if > CMAKE_BUILD_TYPE is not set. > > > Matt S. > Hi Matt, This is not a full answer but Release is not a common target for us: cmake will produce not containing debug info. With these debugging is useless (and you'll get package qa warnings). If there is a default target for us it is RelWithDebInfo. Andreas -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 00/10] Misc fixes (cover letter only)
The following changes since commit 61e9b048591adab88d1996646286e1d7df024bea: Fix drop-down alignment on duplicates page (2018-11-20 11:58:42 +1300) are available in the Git repository at: git://git.yoctoproject.org/layerindex-web paule/fixes12 http://git.yoctoproject.org/cgit.cgi/layerindex-web/log/?h=paule/fixes12 Paul Eggleton (10): Send people an email when another user adds them as a maintainer Add links to other branch recipes in recipe detail Fix errors due to races deleting bitbake temp files local.conf: allow for upstream_tracking.inc to be missing Use try...finally or with to ensure files get closed Replace use of assert with exceptions docker: add wget to dependencies RRS: fix sorting arrow positioning rrs_maintainer_history: check out layer branch before looking for maintainers.inc RRS: add tool to import/export upstream history data Dockerfile | 1 + conf/local.conf| 2 +- layerindex/bulkchange.py | 18 +- layerindex/update.py | 4 +- layerindex/update_layer.py | 14 +- layerindex/utils.py| 21 ++- layerindex/views.py| 70 ++-- rrs/tools/historytool.py | 196 + rrs/tools/rrs_distros.py | 19 +- rrs/tools/rrs_maintainer_history.py| 45 ++--- rrs/tools/rrs_upgrade_history.py | 4 +- rrs/tools/rrs_upstream_history.py | 3 +- rrs/tools/upgrade_history_internal.py | 3 +- rrs/views.py | 2 + templates/layerindex/maintemail.txt| 9 + templates/layerindex/maintemailsubject.txt | 1 + templates/layerindex/recipedetail.html | 27 +++ templates/rrs/maintainers.html | 2 +- templates/rrs/recipedetail.html| 27 +++ templates/rrs/recipes.html | 2 +- 20 files changed, 392 insertions(+), 78 deletions(-) create mode 100755 rrs/tools/historytool.py create mode 100644 templates/layerindex/maintemail.txt create mode 100644 templates/layerindex/maintemailsubject.txt -- 2.17.2 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] CMake based recipes and defining CMAKE_BUILD_TYPE
On Wed, Feb 6, 2019 at 7:39 PM Matt Schuckmann wrote: > > I'm trying to understand why the cmake.bbclass doesn't make any attempt to > set CMAKE_BUILD_TYPE and what the design philosophy behind that is? > > On the surface I would expect that the default build type would be Release > but I can see how that might not always be the right choice. I'm really > surprised that there isn't a global variable that can be set for this, am I > missing something, or is it really expected that each recipe provide it if > they care? > > > FYI I started looking into this when I realized that NDEBUG is not set for > many (if not all) of my CMake based recipes and thus asserts are still > enabled in my production code. This appears to be known behavior for CMake if > CMAKE_BUILD_TYPE is not set. > > > Matt S. > Hi Matt, This is not a full answer but Release is not a common target for us: cmake will produce not containing debug info. With these debugging is useless (and you'll get package qa warnings). If there is a default target for us it is RelWithDebInfo. Andreas -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] CMake based recipes and defining CMAKE_BUILD_TYPE
I'm trying to understand why the cmake.bbclass doesn't make any attempt to set CMAKE_BUILD_TYPE and what the design philosophy behind that is? On the surface I would expect that the default build type would be Release but I can see how that might not always be the right choice. I'm really surprised that there isn't a global variable that can be set for this, am I missing something, or is it really expected that each recipe provide it if they care? FYI I started looking into this when I realized that NDEBUG is not set for many (if not all) of my CMake based recipes and thus asserts are still enabled in my production code. This appears to be known behavior for CMake if CMAKE_BUILD_TYPE is not set. Matt S. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Proper Use of KERNEL_MODULE_AUTOLOAD variable
Maybe it would be good to have a working example in the tree.
Best Regards,
Ulf Samuelsson
> 6 feb. 2019 kl. 02:22 skrev Khem Raj :
>
>
>
>> On Sat, Feb 2, 2019 at 7:17 PM Ken Sloat
>> wrote:
>> On Sat, Feb 2, 2019 at 10:03 PM Bruce Ashfield
>> wrote:
>> >
>> > On 2019-02-02 9:59 p.m., Ken Sloat wrote:
>> > > Hello,
>> > >
>> > > I have an out of tree kernel module which I want autoloaded at startup
>> > > on my system. Looking at the Yocto project manual, I see that one way
>> > > I can do this is to add the module name to the KERNEL_MODULE_AUTOLOAD
>> > > variable within my custom module recipe.
>> > >
>> > > What I have found is that the module-split class is indeed generating
>> > > the "/etc/modules-load.d/mymodule.conf" file, however this file is not
>> > > actually being installed. To be more precise it is appearing in the
>> > > "package" directory (i.e.
>> > > tmp/work/**/mymodule/package/etc/modules-load.d/mymodule.conf) but not
>> > > within the "image" directory (nor in my final rootfs).
>> > >
>> > > Is there something I'm missing in the usage of KERNEL_MODULE_AUTOLOAD?
>> > > Is the intention for this variable I add extra steps to manually
>> > > install this file in my recipe? FYI I'm using Morty.
>> >
>> > Can you provide your recipe ? It would make suggestions easier. For
>> > example, my first question is: Is the module being installed to your
>> > image via IMAGE_INSTALL, or some other similar variable ?
>> >
>> > Bruce
>> >
>> > >
>> > > Thanks,
>> > > Ken Sloat
>> > >
>> >
>>
>> Hi Bruce,
>>
>> Thanks for your quick reply. Yes the module is being installed via
>> image_install. Module is installed but generated conf file is not. See
>> recipe below:
>>
>> require mymodule.inc
>>
>> inherit module kernel-module-split
>>
>> DEPENDS = "virtual/kernel"
>>
>> EXTRA_OEMAKE_append = " \
>> KERNELDIR=${STAGING_KERNEL_DIR} \
>> "
>>
>> MAKE_TARGETS = "module"
>>
>> MODULE_NAME = "mymodule"
>>
>> PKG_${PN} = "kernel-module-${MODULE_NAME}"
>>
>> module_do_install() {
>> install -d ${D}/lib/modules/${KERNEL_VERSION}/kernel/${MODULE_NAME}
>> install -m 0644 ${MODULE_NAME}.ko \
>>
>> ${D}/lib/modules/${KERNEL_VERSION}/kernel/${MODULE_NAME}/${MODULE_NAME}.ko
>> }
>>
>> FILES_${PN} = " \
>> /lib/modules/${KERNEL_VERSION}/kernel/${MODULE_NAME} \
>> "
>
> Your recipe is overwriting common stuff which otherwise should be provided by
> module bbclass
> I would suggest that you append to the variables instead of over writing them
> above and try to reuse
> The primitives from bbclass as much as you can for best results
>>
>>
>> KERNEL_MODULE_AUTOLOAD += "${MODULE_NAME}"
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[linux-yocto] [PATCH] don't check console device file on fs when booting with initrd/initramfs
In case of initrd/initramfs /dev/console might not exist that early
as devtmpfs is mounted a bit later by /init process so disable this
check in that case.
Signed-off-by: Alexey Brodkin
---
init/main.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/init/main.c b/init/main.c
index 387a2d7dc90b..5b904bc78fa4 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1112,7 +1112,9 @@ static int __ref kernel_init(void *unused)
static noinline void __init kernel_init_freeable(void)
{
+#ifndef CONFIG_BLK_DEV_INITRD
struct kstat console_stat;
+#endif
/*
* Wait until kthreadd is all set-up.
*/
@@ -1144,11 +1146,17 @@ static noinline void __init kernel_init_freeable(void)
do_basic_setup();
- /* Use /dev/console to infer if the rootfs is setup properly */
+#ifndef CONFIG_BLK_DEV_INITRD
+ /*
+* Use /dev/console to infer if the rootfs is setup properly.
+* In case of initrd or initramfs /dev/console might be instantiated
+* later by /init so don't do this check for CONFIG_BLK_DEV_INITRD
+*/
if (vfs_lstat((char __user *) "/dev/console", (struct kstat __user *)
_stat)
|| !S_ISCHR(console_stat.mode)) {
panic("/dev/console is missing or not a character
device!\nPlease ensure your rootfs is properly configured\n");
}
+#endif
/* Open the /dev/console on the rootfs, this should never fail */
if (ksys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
--
2.16.2
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
