I'm trying to use a 3rd-party autotools project in Yocto. Its unit tests are run by 'make check' and requires './configure --enable-oe-sdk', but this is not included in the default recipe (from autotools.bbclass). I want the tests built and run, so How to build a different autoconf target in a Yocto/BitBake recipe? Please note that the unit tests run on the development host, instead of running on the embedded target.
Here is what I have tried. Adding extra options to recipes based on Autoconf. But it doesn't say how to build a different target. I added EXTRA_OECONF += '--enable-oe-sdk', and tried to override do_compile() of the recipe. But got following error.
configure: error: OECORE_TARGET_SYSROOT must be set with --enable-oe-sdk
I'm asking a generic question, but the project in question is github.com/openbmc/phosphor-bmc-code-mgmt. Thank you so much!
In openBMC's own repository, there is the meta-phosphor repository with the recipe ready for phosphor-bmc-code-mgmt.bb.
Clone and add meta-phosphor to conf/bblayers.conf and use the phosphor-software-manager recipe.
I have run several openBMC test, but I am far from an expert.
It looks like the repo you are looking at was designed to be tested using the continues integration docker frame work.
The instruction on how to run the test are here .
In the example they are testing "phosphor-hwmon" so insted try testing "phosphor-bmc-code-mgmt"
If that does not work, I bet the someone on openbmc discord will help you out. https://discord.com/invite/69Km47zH98
Related
When adding a new project to a Rush monorepo, is there a way for Rush to automatically insert the dev dependencies into the package.json? For example I want to use the same test frameworks between projects so it would be good to have Rush sync the dev dependencies.
No, there is no way to do this. rush has no idea which package requires which dependencies and, as such, you'll need to add them manually to each.
However, once you've configured your package.json's accordingly, rush will help you maintain dependency versioning across your monorepo. The precise behaviour can be configured by:
setting preferredVersions in the common-versions.json file
using a version policy such as lockStepVersion
(I presume you found this answer already but in case any stumbles across this in the future)
If you run rush add -h you get the usage.
[usage: rush add [-h] -p PACKAGE [--exact] [--caret] [--dev] [-m] [-s] [--all]]
--dev If specified, the package will be added to the
"devDependencies" section of the package.json
The command you are looking for is
rush add -p PACKAGENAME --dev
I am putting together a custom Linux image using Yocto. For now, it needs to include development tools and header files for numerous packages.
Thus far, this has worked perfectly fine by adding "-dev" packages as well. For example, I have added boost-dev, opencv-dev, and msgpack-c-dev. I am, however, running into errors with two recipes: (1) websocketpp_0.7.0.bb from meta-openembedded/meta-oe and (2) autobahn-cpp_18.4.1.bb which I have written. Adding -dev to either of these causes errors during the do_rootfs build phase.
Nothing provides websocketpp = 0.7.0-r0 needed by websocketpp-dev-0.7.0-r0
The non-dev recipe seem fine and I can see the work for both recipes includes all of the expected files. Any help is greatly appreciated.
To resolve such problem, You need to create empty websocketpp pacakge, with using - ALLOW_EMPTY.
ALLOW_EMPTY_${PN} = "1"
I have a yocto build setup for a NXP dev-board. I can build images just fine and I thought this would be a simple way to cross compile a static library that I need for another project.
I added a recipe for the package, sqlcipher, and added sqlcipher-staticdev to IMAGE_INSTALL in local.conf.
This leads to me building sqlcipher just fine but I'm only getting dynamic libraries. I want to have a static library but even though I set DISABLE_STATIC = "" in the recipe I get nothing.
It has not been as easy as I first thought but is there a way to do this kind of thing?
Is there something else that needs to be done to build a static lib?
DISABLE_STATIC is appended to EXTRA_OECONF. Please check whether sqlcipher uses autotools to configure and whether has '--enable/disable-static' configure option.
I am currently using yocto for building an embedded linux image for TI AM335x (I am using hob, since I find it more comfortable than using command-line).
I start using the recipe for building 'core-image-base' and here is the selection of packages which are included:
Now I would like to exclude the package alsa-utils-1.0.28-r0 from build, since it has some problems compiling for my target and I really do not need it... so, as far as I can understand, I have to remove all the dependencies which brought alsa-utils in (that is: alsa-state and packagegroup-base, looking at following screenshot):
So I move to Package groups tab and I remove packagegroup-base and then I remove alsa-state and alsa-utils from the Included recipes:
Now it seems that alsa-utils is there no more... but if I try to build the image, this is the result:
Why? Who is still bringing-in alsa-utils? What am I doing wrong? Is there a way (even command-line) to know why a package is brought-in by yocto?
Use
bitbake -g alsa-utils -u depexp
to display a dependency tree you should be able to see who's depending on it.
See the openembedded wiki.
I'm trying to produce gcd a files from an iOS Xcode 4.2 (4D199) project called CocoaTouchHax on Lion and I'm having incredible trouble. I followed the steps here and I went as far as trying to build llvm/clang from source following steps here. However I continue to get this error:
Library not loaded: #executable_path/../lib/libprofile_rt.dylib
Where am I going wrong? I've tried to use the install_name_tool to fix the executable path to no avail. Am I over analyzing something? Am I missing something simple? I put this in as a "Run Script" phase prior to linking to ensure I've updated the #executable path and I use tool to examine the file after and the name is updated:
install_name_tool -id #executable_path/Users/cliff/dev/CocoaTouchHax/build/CocoaTouchHax/Build/Products/Debug-iphonesimulator/lib/libprofile_rt.dylib build/CocoaTouchHax/Build/Products/Debug-iphonesimulator/lib/libprofile_rt.dylib
What am I doing wrong? Help!
Update
Merely adding lib profile_rt.dylib crashes my test run immediately giving the following error when anything is run:
#executable_path/../lib/libprofile_rt.dylib
So I am certain that something needs to happen or something needs to be done to the lib profile_rt.dylib prior to execution.
Another Update I tried creating a sum link to
/Developer/usr/lib
under /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk/Developer/usr
Which I believe is part of the base the path forming the current working directory when test runs. (Assuming it runs from the bin folder there.) This would, in theory, complete the relative lookup path of ../lib/libprofile_rt.dylib from that base path but it didn't work. I've tried running the install_name_tool command prior to copying the dylib in place but I still get this error:
Library not loaded: #executable_path/../lib/libprofile_rt.dylib
I don't know what I'm doing wrong. I somehow did manage to get test coverage files to emit using some combination of the above but I was not paying close enough attention and cannot reproduce the occurance. I know this can work, I just need a little more help figuring out how.
Update: In Xcode 4.3.2 (4E2002), just switch on Generate Test Coverage Files and Instrument Program Flow, the build system will link libprofile_rt for you. Xcode 4.3, and later, is a standard Mac app and the /Developer folder is gone. So, skip steps 5-7 below. You will also have to create a class file to workaround a bug in Apple's unix implementation as described here. You'll want it in the project under test.
For Xcode 4.2 (4C199) in Snow Leopard:
Create a project, say MyProduct. Check Include Unit Tests.
Once Xcode does its thing and loads the new project, you should have two targets, MyProduct and MyProductTests. Duplicate the MyProduct target.
Select the MyProduct copy target.
Go to Build Settings. Under Code Generation turn on Generate Test Coverage Files and Instrument Program Flow.
Go to Build Phases. Expand Link Binary With Libraries. Click the +. Click Add Other.... Browse to /Developer/usr/lib. Choose libprofile_rt.dylib.
Select the MyProductTests target.
Repeat steps 4 and 5 for that target.
Go to Build Settings again. Find Bundle Loader under Linking. Change the path to the MyProduct copy app. Something like $(BUILT_PRODUCTS_DIR)/MyProduct copy.app/MyProduct copy.
Change your schemes so that the tests run under the MyProduct copy scheme and not MyProduct. If you're compiling clang on your own, you can figure out the details here.
That should work. Step 8 took me hours to figure out, it's the key. If you only see gcda files in the test build directory, that's the likely issue.
On Lion you can symlink the dylib into /usr/lib to avoid that error
sudo ln -s /Developer/usr/lib/libprofile_rt.dylib /usr/lib/libprofile_rt.dylib
I cant guarantee that that wont bust something the future however. Remember that you have done it.
Create a new configuration called "Coverage" (or whatever).
In the Coverage config variant you have created go to Build Settings and...
Add -fprofile-arcs and -ftest-coverage to Other C Flags
Switch on Generate Test Coverage Files
Switch on Instrument Program Flow
In Other Linker flags add -lprofile_rt
The reason to do it this way with a config is that you can keep your normal build untouched. Also only works on Simulator. So dont try running this on device.
And from http://mattrajca.com/post/8749868513/llvm-code-coverage-and-xcode-4
Finally, open up the Intermediates/$TARGET.build/$CONFIG/$TARGET.build/Objects-normal/$ARCH subfolder. Inside, you’ll find the aforementioned gcda and gcov files
You can open that folder with CoverStory.
Note that coverage is not cumulative (unlike Coverity) so each run starts afresh. There might be a way to change that.