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

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

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

Comments

Projects
None yet
9 participants
@devorel
Copy link

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

This comment has been minimized.

Copy link
Member

commented Mar 4, 2018

@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

@devorel

This comment has been minimized.

Copy link
Author

commented Mar 4, 2018

@alexbrainman

This comment has been minimized.

Copy link
Member

commented Mar 4, 2018

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

Thank you

Alex

@devorel

This comment has been minimized.

Copy link
Author

commented Mar 4, 2018

@devorel

This comment has been minimized.

Copy link
Author

commented Mar 4, 2018

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

hello1 10

different

hello1 9
1 9v

@alexbrainman

This comment has been minimized.

Copy link
Member

commented Mar 4, 2018

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

This comment has been minimized.

Copy link
Author

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

This comment has been minimized.

Copy link
Member

commented Mar 4, 2018

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

This comment has been minimized.

Copy link
Author

commented Mar 4, 2018

@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 this to the Go1.11 milestone Mar 4, 2018

@bradfitz bradfitz added the help wanted label Mar 4, 2018

@alexbrainman

This comment has been minimized.

Copy link
Member

commented Mar 4, 2018

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

Alex

@devorel

This comment has been minimized.

Copy link
Author

commented Mar 4, 2018

@asticode

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Member

commented Mar 6, 2018

@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

This comment has been minimized.

Copy link
Author

commented Mar 6, 2018

@alexbrainman

This comment has been minimized.

Copy link
Member

commented Mar 6, 2018

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

This comment has been minimized.

Copy link
Author

commented Mar 6, 2018

@krasnovu

This comment has been minimized.

Copy link

commented Apr 18, 2018

@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).

@alexbrainman

This comment has been minimized.

Copy link
Member

commented Apr 22, 2018

@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

@gopherbot

This comment has been minimized.

Copy link

commented Apr 25, 2018

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

@gopherbot gopherbot closed this in f7b625e May 26, 2018

@alexbrainman

This comment has been minimized.

Copy link
Member

commented May 26, 2018

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

Alex

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented May 27, 2018

@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

This comment has been minimized.

Copy link
Member

commented Jun 1, 2018

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

This comment has been minimized.

Copy link

commented Jun 29, 2018

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.

@gopherbot

This comment has been minimized.

Copy link

commented Aug 10, 2018

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

cmd/go: fix -gcflags, -ldflags not applying to current directory
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 <rsc@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.