8000 I am unable to set CFLAGS and LDFLAGS when building go · Issue #1234 · golang/go · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

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

Closed
gopherbot opened this issue Oct 27, 2010 · 12 comments
Closed

I am unable to set CFLAGS and LDFLAGS when building go #1234

gopherbot opened this issue Oct 27, 2010 · 12 comments

Comments

@gopherbot
Copy link
Contributor

by w.d.hubbs:

I am working on packaging go for gentoo linux, and I need to be able to set the CFLAGS
and LDFLAGS when I run all.bash.

Gentoo's package manager  builds packages from source, similar to the BSD ports
collection, and passes CFLAGS and LDFLAGS to the build system when it attempts to build
a package.  Currently I am unable to pass those settings to go's build system.

I attempted exporting CFLAGS and LDFLAGS before running all.bash, but this does not work.

Any suggestions for dealing with this you can give would be very helpful.  
Thanks much.
@rsc
Copy link
Contributor
rsc commented Oct 27, 2010

Comment 1:

Issue #1235 has been merged into this issue.

@rsc
Copy link
Contributor
rsc commented Oct 28, 2010

Comment 2:

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.

@gopherbot
Copy link
Contributor Author

Comment 3 by w.d.hubbs:

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

@rsc
Copy link
Contributor
rsc commented Oct 28, 2010

Comment 4:

Gcc is used to build both a Go compiler (say, 6g) and a C compiler (6c).
the two are part of the same tool chain.  Some of the Makefiles
use CFLAGS to mean the flags passed to that C compiler.
I'll take a look at restructuring a bit to make this possible.
Russ

@rsc
Copy link
Contributor
rsc commented Oct 28, 2010

Comment 5:

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

@gopherbot
Copy link
Contributor Author

Comment 6 by w.d.hubbs:

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

@rsc
Copy link
Contributor
rsc commented Oct 29, 2010 8000

Comment 7:

Yes, -O2 and -ggdb can be used together.

@gopherbot
Copy link
Contributor Author

Comment 8 by w.d.hubbs:

Would you consider having some way that I can turn them off, maybe
having them set up as the default HOST_EXTRA_CFLAGS so that when I
export HOST_EXTRA_CFLAGS they are overwritten by my changes?

@rsc
Copy link
Contributor
rsc commented Oct 29, 2010

Comment 9:

You can turn them off by settings HOST_EXTRA_CFLAGS=-O2 -g0

@gopherbot
Copy link
Contributor Author

Comment 10 by w.d.hubbs:

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.

@rsc
Copy link
Contributor
rsc commented Nov 1, 2010

Comment 11:

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

@rsc
Copy link
Contributor
rsc commented Nov 1, 2010

Comment 12:

This issue was closed by revision 276003a.

Status changed to Fixed.

@golang golang locked and limited conversation to collaborators Jun 24, 2016
@rsc rsc removed their assignment Jun 22, 2022
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.
Projects
None yet
Development

No branches or pull requests

2 participants
0