-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compile Software with gcc instead of clang #1129
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few interesting bits for reviewers to look at
# See the License for the specific language governing permissions and | ||
# limitations under the License. | ||
|
||
exec /usr/bin/x86_64-linux-gnu-gcc -Wl,--no-as-needed "$@" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@garethellis0 can you do better than this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I don't immediately see a better way 😢. I'm fine with this as long as we leave a comment and open an issue with https://github.com/bazelbuild/bazel asking if this is the correct behavior. I can do make the issue or you can, just lemme know!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
drafting an email to [email protected] according to this message:
ATTENTION! Please read and follow:
- if this is a question about how to build / test / query / deploy using Bazel, or a discussion starter, send it to [email protected]
- if this is a bug or feature request, fill the form below as best as you can.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good! Will try to find a way to put this compiler flags in the toolchain now........
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looking good. Still seems to be some clang stuff floating around in files that got renamed like
src/cc_toolchain/wrapper/clang-profdata → src/cc_toolchain/wrapper/k8_gcc-profdata
src/cc_toolchain/wrapper/clang-strip → src/cc_toolchain/wrapper/k8_gcc-strip
src/cc_toolchain/BUILD
Outdated
"/usr/include/", | ||
"/usr/local/include/", | ||
"/usr/lib/gcc/c++/7.4.0/include/", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to be clear, we explicitly have the include directory for 7.4.0
because we still depend on libs / code built with that version of gcc
, so this is where we need to look to find it? Do we have any guarantee this folder exists?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think ubuntu 18.04 has gcc 7.4.0 preinstalled
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps we should install gcc 7.4.0 explicitly in the setup scripts @garethellis0 ? I don't reall want to have stuff just magically assumed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fine with me, installing gcc-7
should do the trick I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok done
src/external/k8_gcc.BUILD
Outdated
|
||
filegroup( | ||
name = "k8_gcc_libs", | ||
srcs = glob(["usr/lib/gcc/x86_64-linux-gnu/7.4.0/*.a"]), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar to my previous comment, should this really all be specifying 7.4.0
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ubuntu 18.04 should have 7.4.0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the question here is can we make this a bit more general, ie. usr/lib/gcc/x86_64-linux-gnu/*/*.a
or maybe usr/lib/gcc/x86_64-linux-gnu/*/*.a
, but I think that could cause issues if there are multiple versions of gcc installed. perhaps we could make this a filegroup
in the arm_gcc.BUILD
file, just so that all the version-specific stuff is in one place?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I'm mostly just concerned about us
- Expecting a specific version of gcc that we do nothing to verify exists
- "hardcoding" the version in multiple places
I just want this to be easy to upgrade and change in the future, and not cause errors with non-obvious messages if someone without the right setup tries to compile
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how to filegroup them any better. I think I can reduce changes required to update just src/external/k8_gcc.BUILD
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the issue here is maybe more in the naming. Could we rename this file to linux_gcc_7_4_0
, because that's how specific it is? Similairly, everything in this file should probably be changed from k8_gcc
to linux_gcc_7_4_0
.
This way if we ever go to upgrade the compiler version or even support multiple platforms, it's clear what bits are specific to what.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should be good now
Only remaining comment for me is gcc versioning, otherwise nothing more to add beyond existing comments (and CI needs to pass). |
Looks like there was a small (but somewhat nasty) bug where we were relying on just reading random memory here. Opened a quick PR to this branch to fix: https://github.com/jonathanlew/Software/pull/1/files |
…d-behavior Added Check To Make Sure Shot Optional Is Not std::nullopt
Added back the clang-format binary so CI should pass now |
@garethellis0 @MathewMacDougall re-review? |
Looks like CI failed due to a network issue. Re-running now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Main comments from my end here are just around what we call k8_gcc
vs linux_gcc_7_4_0
.
Also one comment left above from an earlier review.
Overall looking good! This will definitely be an improvement.
src/external/k8_gcc.BUILD
Outdated
|
||
filegroup( | ||
name = "k8_gcc_libs", | ||
srcs = glob(["usr/lib/gcc/x86_64-linux-gnu/7.4.0/*.a"]), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the issue here is maybe more in the naming. Could we rename this file to linux_gcc_7_4_0
, because that's how specific it is? Similairly, everything in this file should probably be changed from k8_gcc
to linux_gcc_7_4_0
.
This way if we ever go to upgrade the compiler version or even support multiple platforms, it's clear what bits are specific to what.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nothing major to add beyond Gareth's comments. Can we also change the setup scripts to ensure we install gcc 7.4.0?
Ready for re-review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice job getting comments resolved! Just one left (at the very top) and then this is good to go from my end!
Will email [email protected] re: -Wl,--no-as-needed in linux_gcc-gcc |
Co-Authored-By: Gareth Ellis <[email protected]>
Seems like this is good to go then? @garethellis0 is everything good from your end? |
Still waiting on code coverage here..... not sure why it's not running, I think Jon is going to open a new PR to see if that fixes it? |
Will close and reopen to try to fix coverage |
Please fill out the following before requesting review on this PR
Description
Use native gcc to compile code instead of external clang package.
Testing Done
Resolved Issues
resolves #1124
Length Justification
Review Checklist
It is the reviewers responsibility to also make sure every item here has been covered
.h
file) should have a javadoc style comment at the start of them. For examples, see the functions defined inthunderbots/software/geom
. Similarly, all classes should have an associated Javadoc comment explaining the purpose of the class.TODO
(or similar) statements should either be completed or associated with a github issue