Skip to content
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

allow setting $AS from cgo #2924

Closed
gopherbot opened this issue Feb 8, 2012 · 11 comments
Closed

allow setting $AS from cgo #2924

gopherbot opened this issue Feb 8, 2012 · 11 comments

Comments

@gopherbot
Copy link
Contributor

by salviati.gnu:

Before filing a bug, please check whether it has been fixed since
the latest release: run "hg pull", "hg update default", rebuild, and
retry
what you did to
reproduce the problem.  Thanks.

What steps will reproduce the problem?
1. use cgo comment #cgo 386 AS: nasm -f elf
2.
3.

What is the expected output?
run nasm

What do you see instead?
invalid #cgo verb: #cgo 386 AS: nasm -f elf

Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
linux amd64

Which revision are you using?  (hg identify)
6g version weekly.2012-02-07 +0eab3b57c894

Please provide any additional information below.
@rsc
Copy link
Contributor

rsc commented Feb 8, 2012

Comment 1:

This would allow making arbitrary commands a dependency
of using cgo.  We are explicitly trying to keep things more
tool-neutral.
What is the bigger context here?
Russ

Labels changed: added priority-later, removed priority-triage.

Status changed to WaitingForReply.

@gopherbot
Copy link
Contributor Author

Comment 2 by salviati.gnu:

Just trying to avoid porting a lengthy nasm code to Plan9 as.
Any hacks possible? (ex: will cgo respect environment variable $AS?)

@rsc
Copy link
Contributor

rsc commented Feb 8, 2012

Comment 3:

Since cgo doesn't work on Plan 9 anyway, I think you have two problems.
Russ

@gopherbot
Copy link
Contributor Author

Comment 4 by salviati.gnu:

Sorry, I meant porting to 8a/6a; I'm using linux.

@rsc
Copy link
Contributor

rsc commented Feb 8, 2012

Comment 5:

If you are using cgo in package, then .c and .s files are
handed to gcc to be compiled.  If you are not using cgo
then .c and .s files are handed to the 8c/8a.
Russ

@gopherbot
Copy link
Contributor Author

Comment 6 by salviati@freeconsole.org:

So $CC is used instead of $AS.
Can I ask given the current spec, how do you suggest handling nasm files in a cgo
package?

@gopherbot
Copy link
Contributor Author

Comment 7 by salviati.gnu:

So $CC is used instead of $AS.
Can I ask given the current spec, how do you suggest handling nasm files in a cgo
package?

@rsc
Copy link
Contributor

rsc commented Feb 8, 2012

Comment 8:

I would rewrite them to use the gnu assembler or using
an inline asm statement in a C file.  The tools assume
something like gcc (gcc itself, or maybe clang).  There is
no need to introduce a dependency on a second assembler
when we already assume gcc.
Russ

@gopherbot
Copy link
Contributor Author

Comment 9 by salviati@freeconsole.org:

I see.
The only problem is, this task is too costly in my case. I've downgraded the weekly for
the time being.
I'm confused about the policy on dependencies though. This imposes a strong constraint
on how go programs interact with the non-go world.
In the current cgo spec the programmer can introduce arbitrary 3rd party library
dependencies, which may or may not exists in the system already. Why a different
attitude towards 3rd party tools?

@gopherbot
Copy link
Contributor Author

Comment 10 by salviati.gnu:

I see.
The only problem is, this task is too costly in my case. I've downgraded the weekly for
the time being.
I'm confused about the policy on dependencies though. This imposes a strong constraint
on how go programs interact with the non-go world.
In the current cgo spec the programmer can introduce arbitrary 3rd party library
dependencies, which may or may not exists in the system already. Why a different
attitude towards 3rd party tools?

@rsc
Copy link
Contributor

rsc commented Feb 10, 2012

Comment 11:

I don't believe cgo has ever allowed setting a variable
other than CFLAGS and LDFLAGS.  Maybe nasm has
a mode to emit gas syntax, or maybe someone has a
converter.  I don't want to expand the set of required
build tools.
Russ

Status changed to Unfortunate.

@golang golang locked and limited conversation to collaborators Jun 24, 2016
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