-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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/go: cgo generates too long a path on windows #17070
Comments
I think #3358 is related. |
if use cgo, it is ok. the bug is only for build with x.swig. |
It looks like these filenames are chosen by SWIG, not by Go. Is there anything we can do about that? |
What is the file whose path is too long? What created that file? Is the problem that the total path is too long, or that an individual name in the path is too long? |
1. swig generate the hello_with_tooooooo_long_path.goswig -go -cgo -intgosize 64 -module hello_with_tooooooo_long_path -o "C:\Users\chai\AppData\Local\Temp\go-build509547282\github.com\chai2010\hello-swig-bug_test_obj_test\hello_with_tooooooo_long_path_wrap.c" -outdir "C:\Users\chai\AppData\Local\Temp\go-build509547282\github.com\chai2010\hello-swig-bug_test_obj_test" hello_with_tooooooo_long_path.swig the full path length is 135. 2. then cgo use the hello_with_tooooooo_long_path.go to generate
|
Thanks. I don't think there is any swig problem here. The problem is cgo. cgo is generating the file WORKDIR/WORKDIRNAME_FILE.cgo1.go where WORKDIRNAME is WORKDIR with the slashes replaced by underscores. When WORKDIR is long, as it often is, the resulting file name is quite long. One way to fix this is to have cmd/go pass a -srcdir option to cmd/cgo, which will cause WORKDIRNAME to contain just the file name, which is all we really need anyhow. |
The root cause here is #3358, which we have yet to fix. Why is cgo putting WORKDIRNAME into the generated file name at all? Also, cgo has no -srcdir option (that's a local Google modification we should upstream). |
cgo putting WORKDIRNAME into the generated file name predates the go tool, when apparently cgo files could live in a separate directory. It was added in https://golang.org/cl/1734047 to fix #533. Maybe we could just stop doing that now. |
CL https://golang.org/cl/32354 mentions this issue. |
This is convenient for direct use of `go tool cgo`. We can also use it from the go tool to reduce the length of the file names that cgo generates. Update #17070. Change-Id: I8466a0a2cc68a732d17d07319e303497715bac8c Reviewed-on: https://go-review.googlesource.com/32354 Run-TryBot: Ian Lance Taylor <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Russ Cox <[email protected]>
CL https://golang.org/cl/32436 mentions this issue. |
CL https://golang.org/cl/32485 mentions this issue. |
Change https://golang.org/cl/56280 mentions this issue: |
Now that we have -importcfg, there's no need for the temporary directory trees that mirror the import path structure, and we can drop a bunch of complex code that was building and maintaining that structure. This should fix "file name too long" errors on systems with low limits. (For example #10651 and #17070, although we fixed those by adding code to deal with very long file names on Windows instead.) Change-Id: I11e221c6c1edeb81c3b2f1d89988f5235aa2bbb9 Reviewed-on: https://go-review.googlesource.com/56280 Reviewed-by: Ian Lance Taylor <[email protected]>
https://github.com/chai2010/hello-swig-bug
The text was updated successfully, but these errors were encountered: