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.

Sign up for GitHub

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

Jump to bottom

cmd/link: Windows -H windowsgui stopped working in Go 1.10? #24232

Closed
devorel opened this issue Mar 3, 2018 · 24 comments
Closed

cmd/link: Windows -H windowsgui stopped working in Go 1.10? #24232

devorel opened this issue Mar 3, 2018 · 24 comments
Labels
FrozenDueToAge help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Go1.11

Comments

@devorel
Copy link

devorel commented Mar 3, 2018

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)? 1.10

Does this issue reproduce with the latest release? yes ,just the last

What operating system and processor architecture are you using (go env)? windows 10 ,intel i7

What did you do?

go build -ldflags "-H windowsgui" -v -o %gopath%/bin/test.exe my\proj\test.io

if i compile my program with version 1.9 , it's work good!
but if i compile my program in the last version 1.10 , i get black window console

What did you expect to see?

my window program without window console

What did you see instead?

my window program with window console
@alexbrainman
Copy link
Member

@devorel I cannot reproduce this. I did this:

c:\>go version
go version go1.10 windows/amd64

c:\>go build -ldflags "-H windowsgui" -v -o %tmp%\a.exe github.com/alexbrainman/gowingui

c:\>

and then I double clicked on %TMP%\a.exe. I don't see any window console.

What did I do wrong?

Thank you.

Alex

@davecheney davecheney added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Mar 4, 2018
@alexbrainman alexbrainman mentioned this issue Mar 4, 2018
Open
@devorel
Copy link
Author

devorel commented Mar 4, 2018 via email

@alexbrainman
Copy link
Member

@devorel I don't understand your explanation. Please, try again.

Thank you

Alex

@devorel
Copy link
Author

devorel commented Mar 4, 2018 via email

@devorel
Copy link
Author

devorel commented Mar 4, 2018 •
edited
Loading

look
this flug "windowsgui" need to cancel the window console

hello1 10

different

hello1 9
1 9v

@alexbrainman
Copy link
Member

this flug "windowsgui" need to cancel the window console

I don't get any console windows. Both at version 1.9 and 1.10.

How did you build your executable? Did you see my command there #24232 (comment) ?
What is your command? Can I download your program to try it here?

Alex

@devorel
Copy link
Author

devorel commented Mar 4, 2018

Hi
i try your program , and i get it again
go build -ldflags "-H windowsgui" -v -o %tmp%\a.exe github.com/alexbrainman/gowingui

v1 10 bug

https://golang.org/dl/
go1.10.windows-amd64.msi | Installer | Windows | x86-64 | 106MB

@alexbrainman
Copy link
Member

go build -ldflags "-H windowsgui" -v -o %tmp%\a.exe github.com/alexbrainman/gowingui

Looking at your screenshot, I can see you did something completely different. You used \ instead of / in your import path. Do not do that. Really use

go build -ldflags "-H windowsgui" -v -o %tmp%\a.exe github.com/alexbrainman/gowingui

command.

Alex

@devorel
Copy link
Author

devorel commented Mar 4, 2018 via email

@bradfitz bradfitz changed the title Hi you have a bug compilation cmd/link: Windows -H windowsgui stopped working in Go 1.10? Mar 4, 2018
@bradfitz bradfitz added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. and removed WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Mar 4, 2018
@bradfitz bradfitz added this to the Go1.11 milestone Mar 4, 2018
@alexbrainman
Copy link
Member

I don't know how to reproduce your problem here. Sorry.

Alex

@devorel
Copy link
Author

devorel commented Mar 4, 2018 via email

@asticode
Copy link
Contributor

asticode commented Mar 6, 2018

I've built a library that uses the -H windowsgui flag and some of my users are complaining it stopped working in GO 1.10 too. Unfortunately I didn't have time to investigate further but this issue seems to describe an actual problem therefore I'd like to help.

@alexbrainman which windows are you testing on?

@alexbrainman
Copy link
Member

@asticode

some of my users are complaining it stopped working in GO 1.10 too. Unfortunately I didn't have time to investigate further but this issue seems to describe an actual problem therefore I'd like to help.

Perhaps your users use wrong import path to build their program, like I described in #24233. That will make Go 1.10 build executable without IMAGE_SUBSYSTEM_WINDOWS_GUI flag set.

@alexbrainman which windows are you testing on?

Windows 10.

Alex

@devorel
Copy link
Author

devorel commented Mar 6, 2018 via email

@alexbrainman
Copy link
Member

NO, it's not!
i v1.94 it's work good!
i copied the command of alexbrainman https://github.com/alexbrainman ,and
i get the window console yet

I believe you, but I cannot reproduce it myself. Perhaps others can. Sorry.

Alex

@devorel
Copy link
Author

devorel commented Mar 6, 2018 via email

@krasnovu
Copy link

@alexbrainman, I have a similar problem on Go 1.10.1 (I could not downgrade to 1.9.3 to check if there was an error on this version) and I`ve found a way to reproduce it.

Steps to reproduce:

  1. Check the GOPATH parameter in go env. For example, E:\Go.
  2. In the console, change the directory using other letter case of part intersecting with GOPATH variable. For example, cd e:\go\src\site\project (here "e" and "go" in lowercase).
  3. Build the project with the ldflags keys. For example go build -ldflags "-s -w -H=windowsgui".

P.S.: In my auto-builder project the second step looks like os.Chdir(dir).

This was referenced Apr 18, 2018
Closed
Closed
@alexbrainman
Copy link
Member

@alexbrainman, I have a similar problem on Go 1.10.1 (I could not downgrade to 1.9.3 to check if there was an error on this version) and I`ve found a way to reproduce it.

Yes, I can reproduce it here too now. I use these commands:

set MYHOME=c:\users\alex\dev
set GOROOT=%MYHOME%\go
set GOROOT_BOOTSTRAP=%MYHOME%\go1.4.3
set GOPATH=%MYHOME%
set PATH=%PATH%;%GOROOT%\bin
cd %GOPATH%\src\github.com\alexbrainman\gowingui
go build -ldflags "-H windowsgui" -v -o %tmp%\a.exe
pause

That creates %tmp%\a.exe that opens command window when it runs.

Thank you @krasnovu

Alex

@alexbrainman alexbrainman mentioned this issue Apr 24, 2018
Closed
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/109235 mentions this issue: cmd/go/internal/load: use strings.ToLower when comparing package directory names

@alexbrainman
Copy link
Member

Just submitted the fix. Should we back port the fix to go1.10 and go1.9 ?

Alex

@ianlancetaylor
Copy link
Contributor

@alexbrainman We shouldn't backport to 1.9 which doesn't have this problem anyhow.

A backport to 1.10 is OK with me if you think it is a good idea.

@alexbrainman
Copy link
Member

We shouldn't backport to 1.9 which doesn't have this problem anyhow.

I agree, go1.9 is not broken with this issue, so we do not need to backport to go1.9.

A backport to 1.10 is OK with me if you think it is a good idea.

This issue did not affect me personally, so I do not know if it should be back ported or not. That is why I asked here. And it looks like no one cares about backporting this to go1.9. So I assume we don't want to backport this until we hear some complains.

Thank you, Ian.

Alex

@hugows
Copy link

hugows commented Jun 29, 2018 •
edited
Loading

PSA: for me, changing the GOPATH to the correct capitalization form e.g. "C:\Users\hugo\go" instead of "c:\users\hugo\go" is a workaround for on go 1.10.3.

@rsc rsc mentioned this issue Aug 10, 2018
Closed
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/129059 mentions this issue: cmd/go: fix -gcflags, -ldflags not applying to current directory

gopherbot pushed a commit that referenced this issue Aug 17, 2018
@rsc
cmd/go: fix -gcflags, -ldflags not applying to current directory
2ce6da0 
A flag setting like -gcflags=-e applies only to the packages
named on the command line, not to their dependencies.
The way we used to implement this was to remember the
command line arguments, reinterpret them as pattern matches
instead of package argument generators (globs), and apply them
during package load. The reason for this complexity was to
address a command-line like:

	go build -gcflags=-e fmt runtime

The load of fmt will load dependencies, including runtime,
and the load of runtime will reuse the result of the earlier load.
Because we were computing the effective -gcflags for each
package during the load, we had to have a way to tell, when
encountering runtime during the load of fmt, that runtime had
been named on the command line, even though we hadn't
gotten that far. That would be easy if the only possible
arguments were import paths, but we also need to handle

	go build -gcflags=-e fmt runt...
	go build -gcflags=-e fmt $GOROOT/src/runtime
	go build -gcflags=-e fmt $GOROOT/src/runt...
	and so on.

The match predicates usually did their job well, but not
always. In particular, thanks to symlinks and case-insensitive
file systems and unusual ways to spell file paths, it's always
been possible in various corner cases to give an argument
that evalutes to the runtime package during loading but
failed to match it when reused to determine "was this package
named on the command line?"

CL 109235 fixed one instance of this problem by making
a directory pattern match case-insensitive on Windows, but that
is incorrect in some other cases and doesn't address the root problem,
namely that there will probably always be odd corner cases
where pattern matching and pattern globbing are not exactly aligned.

This CL eliminates the assumption that pattern matching
and pattern globbing are always completely in agreement,
by simply marking the packages named on the command line
after the package load returns them. This means delaying
the computation of tool flags until after the load too,
for a few different ways packages are loaded.
The different load entry points add some complexity,
which is why the original approach seemed more attractive,
but the original approach had complexity that we simply
didn't recognize at the time.

This CL then rolls back the CL 109235 pattern-matching change,
but it keeps the test introduced in that CL. That test still passes.

In addition to fixing ambiguity due to case-sensitive file systems,
this new approach also very likely fixes various ambiguities that
might arise from abuse of symbolic links.

Fixes #24232.
Fixes #24456.
Fixes #24750.
Fixes #25046.
Fixes #25878.

Change-Id: I0b09825785dfb5112fb11494cff8527ebf57966f
Reviewed-on: https://go-review.googlesource.com/129059
Run-TryBot: Russ Cox <[email protected]>
Reviewed-by: Alan Donovan <[email protected]>
@golang golang locked and limited conversation to collaborators Aug 10, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Go1.11
Development

No branches or pull requests
9 participants
@bradfitz @davecheney @hugows @ianlancetaylor @krasnovu @gopherbot @alexbrainman @asticode @devorel