bmcweb fails to compile in the openbmc SDK #2
Comments
|
https://gerrit.openbmc-project.xyz/#/c/openbmc/bmcweb/+/11904/ should fix the problem if you are building out of tree. If you want to use the Yocto Dependencies make sure flag -DYOCTO_DEPENDENCIES is set |
|
Yep, nice with this commit and this command to build I was able to get a bmcweb I could start up on our witherspoon from a compile in our SDK: Thanks! |
bradbishop
pushed a commit
that referenced
this issue
Feb 6, 2021
In code review, despite them being documented, people still tend to make these mistakes. Having them numbered allows responding with comments that are much simpler for a maintainer, with quick comments like: "Common error #2" While this might not seem like a huge savings, for maintainers having to review 10s of reviews per day, having an optimized workflow helps a lot with time savings and little improvements add up over time. Signed-off-by: Ed Tanous <edtanous@google.com> Change-Id: I877cbbf50c1e20448f31464f820114073bba513e
bradbishop
pushed a commit
that referenced
this issue
Feb 19, 2021
Fixes #178 Every few months, this option breaks because of some combination of compiler options. I'm hoping that this is a more permenant fix, and will keep it working forever. Functionally, this commit changes a couple things. 1. It fixes the regression that snuck into this option, by making the req variable optional using the c++17 [[maybe_unused]] syntax. 2. It promotes the BMCWEB_INSECURE_DISABLE_XSS_PREVENTION into the config.h file, and a constexpr variable rather than a #define. This has the benefit that both the code paths in question will compiled regardless of whether or not they're used, thus ensuring they stay buildable forever. The optimization path will still delete the code later, but we won't have so many one-off build options breaking. We should move all the other feature driven #ifdefs to this pattern in the future. 3. As a mechnaical change to #2, this adds a config.h.in, which delcares the various variables as their respective constexpr types. This allows the constants to be used in a cleaner way. As an aside, at some point, DISABLE_XSS_PREVENTION should really move to a non-persistent runtime option rather than a compile time option. Too many people get hung up on having to recompile their BMC, and moving it to runtime under admin credentials is no more a security risk. As another aside, we should move all the other #ifdef style options to this pattern. It seems like it would help with keeping all options buildable, and is definitely more modern than #ifdefs for features, especially if they don't require #include changes or linker changes. Tested: enabled meson option insecure-disable-xss, and verified code builds and works again. Change-Id: Id03faa17cffdbabaf4e5b0d46b24bb58b7f44669 Signed-off-by: Ed Tanous <edtanous@google.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've spent a bit of time here and there trying to get bmcweb to compile within the openbmc SDK. I found and patched one issue with https://gerrit.openbmc-project.xyz/#/c/openbmc/openbmc/+/11901/ but I'm still not quite there and I gotta move on for now. So opening this bug to track what I've found.
With an SDK built based on the commit above, I get this when I compile:
The error seem to indicate that cmake is not getting the appropriate SDK paths. The required files and libraries are in the SDK:
But it's not finding them for some reason. I don't think this is a bmcweb specific issue, I think it's probably a cmake related issue with the SDK.
I'm running at commit 1b0044b
The text was updated successfully, but these errors were encountered: