So, I was given the task to upgrade our yocto based system from fido to morty. I have very little experience with yocto, I have been struggling with it and trying to understand it for almost a week now. I have managed to fix some issues, but now I'm facing a problem when trying to build the image:
dnsmasq-2.68-r0 do_package_qa: QA Issue: No GNU_HASH in the elf binary: '/oe/.../dnsmasq/2.68-r0/packages-split/dnsmasq/usr/bin/dnsmasq'
I have looked online for a solution and I did find a way to suppress the error by adding:
INSANE_SKIP_${PN} = "ldflags"
in the recipe.
However I don't believe this is the 'correct' way to do it, and I had it on another recipe, that had the same problem. I also found that someone had similar issue and rearranging packages did the trick, but I don't know how to do that.
So my question is: Is it bad idea to just add the insane_skip to all recipes that have this issue and if so how can it be fixed?
You'd likely benefit from having a look at the dnsmasq recipe in meta-oe.
Your problem is that dnsmasq doesn't respect the LDFLAGS variable out of the box. Try adding:
EXTRA_OEMAKE_append = " 'LDFLAGS=${LDFLAGS}'"
to your recipe. (See the recipe in the linked URL).
Somewhere, you might have overridden EXTRA_OECONF with EXTRA_OECONF = " foobar ".
Use the += notion might resolve the issue:
EXTRA_OECONF += " foobar "
Related
I was exporting my component to Bit.dev, when I got stuck at the bit tag --message command, with the error message: Failed task 1: "teambit.pkg/pkg:PackComponents" of env "teambit.harmony/node"
I have already ran the previous commands: bit link --rewire, bit compile and bit build --all prior. I would also like to mention that I have circular dependencies errors which I workaround with the --ignore-issues \"CircularDependencies\" flag.
Have anyone faced this issue before, and managed to solve it? Thanks in advance.
I'm working on Yocto bitbake.
I found to specify the recipe using "PREFERRED_VERSION" directive in conf/local.conf, if there are multiple recipes for one component.
I'm using "Rocko", and want to select the version of "1.1.0" of openssl so that I appended the line below to conf/local.conf.
PREFERRED_VERSION_openssl = "1.1.%"
But, it look that it doesn't work and openssl-1.0.2 was built.
Does anyone have an idea what is wrong? Thanks.
PREFERRED_VERSION_openssl_forcevariable = "1.1.%"
I am trying to build an console image for an RPi using the core-image-base recipe, but somewhere in my configuration, I seem to have switched something on that is increasing the number of recipes built by around 1000 which include many things that don't feel like they belong in a console image (libx11, gnome-desktop-testing, etc.)
I am trying to track down why these recipes are being included in my build. My method so far has been to run the following commands:
# Generate a massive dot file with all the dependencies in it
bitbake -g core-image-base
# grep through that file to find out what is bringing in
# gnome-desktop-testing.
cat task-depends.dot | grep -i gnome-desktop-testing | grep -vi do_package_write_rpm
I removed do_package_write_rpm from the matching since everything seems to match against it. This leaves the following:
"core-image-base.do_build" -> "gnome-desktop-testing.do_build"
"core-image-base.do_rootfs" -> "gnome-desktop-testing.do_package_qa"
"core-image-base.do_rootfs" -> "gnome-desktop-testing.do_packagedata"
"core-image-base.do_rootfs" -> "gnome-desktop-testing.do_populate_lic"
"glib-2.0.do_package_qa" -> "gnome-desktop-testing.do_packagedata"
(followed by many dependencies between the tasks of the gnome-desktop-testing recipe)
So, if my interpretation is correct, it seems that core-image-base is depending directly on gnome-desktop-testing. This seems unusual since core-image-base is supposed to be a console only image.
I tried adding PACKAGE_EXCLUDE = "gnome-desktop-testing" to my local.conf hoping that it would give back some more information, but the build just seems to proceed regardless of this variable's setting :/
How can I figure out why gnome-desktop-testing is being built by Yocto? Ideally I would like to have a solution not involving toaster.
I ran into this issue and so I thought I would post the answer.
First, I removed the recipe, rebuilt and then looked at the first dependency chain.
NOTE: Runtime target 'shared-mime-info' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['shared-mime-info', 'glib-2.0', 'gnome-desktop-testing']
Then we look in the recipe to see that glib-ptest has an RDEPENDS on gnome-desktop-testing.
RDEPENDS_${PN}-ptest += "\
coreutils \
libgcc \
dbus \
gnome-desktop-testing \
tzdata \
So then to fix that you will need to disable "ptest". This can be done from the your distro configuration (meta-layer/conf/distro/*.conf).
One brutal solution to this problem is to just delete the recipe that you don't want and to rerun bitbake. This gives you a useful message such as:
ERROR: Required build target 'core-image-base' has no buildable providers.
Missing or unbuildable dependency chain was:
['core-image-base', 'packagegroup-base-extended', 'ofono', 'glib-2.0', 'gnome-desktop-testing']
If you have brought in these layers using git, the changes can be quickly reverted with git checkout path/to/deleted/recipe
I am on a raspbian stretch system with the spur32 VM for ARM and a Pharo 7 image. At Startup I always get an exception: Error - Module not found.
It seems to have to do with lgitlibrary. I really cannot figure out what this error is about.
Any ideas?
Thanks,
Henrik
I see. If you check #unixModuleName
unixModuleName
| pluginDir |
pluginDir := Smalltalk vm binary parent.
#('libgit2.so' 'libgit2.so.0')
detect: [ :each | (pluginDir / each) exists ]
ifFound: [ :libName | ^ libName ].
self error: 'Module not found.'
Here you have your error message: self error: 'Module not found.'
You probably have libgit2.so or libgit2.so.0 missing (or dependencies). You may suffer with similar problem as me: Getting error when adding OSSubprocess to my Pharo 6.1 on Centos 7.4x.
You should check the dependencies with ldd (check my question for details).
Edit Adding information due to comment:
I have yet to use IceBerg (the Pharo's git integration). My guess, would be to "(re-)initialize it": (Smalltalk at: #LGitLibrary) initialize.
For more information, I recommend reading these: pharo's iceberg and some Pharo project that uses git like pharo-contributor and checking blog pharoweekly (for some information about the pharo-contributor) - https://pharoweekly.wordpress.com/2018/04/24/pharo-contributor-to-contribute-to-pharo.
You may want to use some guide "How to use git and github with Pharo". Which was done by Peter Uhnak (you can find him on SO).
I had the similar problem and I needed to build libgit2 library from source using this instructions. The basic build didn't work because Pharo wasn't able to initialize the library. I compiled it again with parameter -DSTDCALL=ON an it works.
I'm attempting to generate an Xcode project and am getting:
error: reachedTimeLimit
Unfortunately I don't see a lot of help googling this error nor does there appear to be a way to extend whatever the current time limit is from the command line.
Any ideas?
There is a hardcoded 10 second time limit for package resolving baked into SPM - see the code in DependencyResolver.swift.
Line 1365 has let timeLimit = 10, and there is no way of changing this externally, except of course building your own version of SPM with a higher timeout.
I haven't dug deep enough into the resolver algorithm, but it seems that your dependency tree is pretty complex for the resolving to take so long.