-
Notifications
You must be signed in to change notification settings - Fork 18k
I am unable to set CFLAGS and LDFLAGS when building go #1234
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
Labels
Comments
Issue #1235 has been merged into this issue. |
You should be able to edit src/Make.inc to change $HOST_CFLAGS appropriately. We can add a $HOST_LDFLAGS if needed. The build does not use the ones set in the environment unconditionally, because it runs two different compilers at different times during the build. What's right for one is probably not right for the other. Owner changed to r...@golang.org. Status changed to WaitingForReply. |
I see that the default value for HOST_CFLAGS includes -I"$(GOROOT)/include". Would it be possible to remove the -I option from HOST_CFLAGS but keep it in the Makefiles by creating another variable for it if needed? That way I can overwrite the value of HOST_CFLAGS without breaking the compile. HOST_LDFLAGS would be needed if your Makefiles do not use LDFLAGS from the environment. Ideally I would like to do something like this without actually editing src/Makefile.inc. cd src HOST_CFLAGS="${CFLAGS}" HOST_LDFLAGS="${LDFLAGS}" all.bash I'm confused. You say that the build runs two different compilers at different points during the build, but I only have gcc installed and the build completes successfully on my system. If you mean that the C compiler and the go compiler are both being used as part of the build process, I would agree that CFLAGS should not be passed to the go compiler, but in that case I am confused about why CFLAGS from the environment can't be passed to the c compiler. Can you please explain more what you mean? William |
Look at http://golang.org/cl/2735043. Is that sufficient for this? Given $CFLAGS and $LDFLAGS that you want used with gcc, you would run export HOST_EXTRA_CFLAGS=$CFLAGS export HOST_EXTRA_LDFLAGS=$LDFLAGS before running the normal build. Russ |
Hi Russ, I commented on this yesterday, but for some reason the comments didn't show up. Ok, your suggestion works, but I noticed something in the default flags being passed to gcc that caught my attention. You have both -O2 and -gdbg listed. That is asking for optimization and debugging symbols at the same time. Can these be used together? If not, you might want to drop them from your defaults. Thanks, William |
I don't think your suggestion in comment 9 works because HOST_EXTRA_CFLAGS come before your hard coded flags in the command line, and I think the compiler processes the flags from left to right. Also, in comment 7, you say that -O2 and -gdbg can be used together. Does that mean that -O2 doesn't break debugging? I ask because there are comments in the info manual for gcc about how using optimization and debugging at the same time can break debugging. |
The patch I will submit soon http://golang.org/cl/2735043/ fixes them as you asked for. It's true that with -O2, sometimes gdb cannot show you the value of a particular local variable, but it can still give you stack traces and the values of most local variables, all globals, disassemble functions, map program counters to line numbers, and so on. The gcc info manual is making excuses for not being perfect (as if anything about gdb were perfect). I don't care that it's not perfect. It's a whole lot better than having nothing at all. In short, yes, -O2 breaks -ggdb a little bit, but not passing -ggdb at all breaks it a whole lot more. Russ |
This issue was closed by revision 276003a. Status changed to Fixed. |
ericdimon86
added a commit
to ericdimon86/go
that referenced
this issue
Feb 4, 2025
Also, delete go1.17_spec.html. Change-Id: I7c78029dcfbbe8dbabb4ca81052976c1c8f4ed9a Reviewed-on: https://go-review.googlesource.com/c/go/+/645717 Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Robert Griesemer <gri@google.com> TryBot-Bypass: Robert Griesemer <gri@google.com> This PR will be imported into Gerrit with the title and first comment (this text) used to generate the subject and body of the Gerrit change. **Please ensure you adhere to every item in this list.** More info can be found at https://github.com/golang/go/wiki/CommitMessage + The PR title is formatted as follows: `net/http: frob the quux before blarfing` + The package name goes before the colon + The part after the colon uses the verb tense + phrase that completes the blank in, "This change modifies Go to ___________" + Lowercase verb after the colon + No trailing period + Keep the title as short as possible. ideally under 76 characters or shorter + No Markdown + The first PR comment (this one) is wrapped at 76 characters, unless it's really needed (ASCII art, table, or long link) + If there is a corresponding issue, add either `Fixes golang#1234` or `Updates golang#1234` (the latter if this is not a complete fix) to this comment + If referring to a repo other than `golang/go` you can use the `owner/repo#issue_number` syntax: `Fixes golang/tools#1234` + We do not use Signed-off-by lines in Go. Please don't add them. Our Gerrit server & GitHub bots enforce CLA compliance instead. + Delete these instructions once you have read and applied them
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by w.d.hubbs:
The text was updated successfully, but these errors were encountered: