Implement the Windows wrapper generator #2
Labels
help wanted
Extra attention is needed
Comments
|
@karalabe What needs to be done in order to add windows support? |
|
The first thing I ran into was file names being too long during compilation for the NTFS file system (max 255 characters). |
|
Error on windows 10: |
|
If I'm not mistaken can't the NTFS file system max of 255 characters be extended? This happens when installing python on windows. |
Windows 10 does have something... https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=cmd |
|
what about cross compilation? It seems here that he's having the issue of building libtor on the windows OS, but what about cross compiling libtor for windows on linux? |
|
I added Windows support in https://github.com/gen2brain/go-libtor. I didn't try to build from Windows yet, all was done cross-compiling from Linux. I did have to patch a couple of |
|
@gen2brain I'm getting the following errors:
When I run: ` Could you let me know the command that you are using to cross compile a windows build of your fork or if you have any idea why I'm getting these errors when trying to compile for windows? |
|
@bobbaker6667 You can drop those build tags, they are not used. As I mentioned I had to patch a few rpc* files that come with MinGW runtime, maybe also something else (something that uses widl to generate header from .idl files, not sure). Try for now with the attached patches and report what happens after that. |
|
@gen2brain building from windows has the same issue, I haven't tried a cross-compile yet. |
Sorry I'm late to the party. Cross compilation could be a first iteration but go is meant to be cross platform and a solution which doesn't require another os environment would improve adoption of this library. The complexity of any given project which takes this library as a dependency would increase drastically, if it had to cross compile for windows binaries. Switching os context to build a library isn't good developer ergonomics. The beautiful aspect of go is that you have a comprehensive ecosystem of library solutions letting you solve your problems within your binary, lowering the complexity of a given project by not having to cross runtime barriers. Crossing os barriers at the compilation phase defeats that elegance. |
|
@psycik Thanks for checking, I believe the issue is not with filename/extension too long, because none of the filenames exceed 255, but there are 1100+ files per platform, perhaps that is another limitation in Windows. Also, not sure if that is an issue with I just needed this for some project, there was no Windows support so I added it (i.e. adding necessary files, headers, cgo flags, etc.). I anyway build for all platforms from Linux, i.e. with toolchains like MingW, OSXCross, NDK, RPi, crossdev, etc. I can compile for any platform. I don't even know how I could compile my apps in real Windows, it is much much easier to target Windows from Linux, at least for me. |
|
Hi all, just writing in reply, what I ended up doing was compiling tor for the needed arches with musl/mingw32 and then embedding the static binaries with go:embed and writing them to a working directory, this means I am able to use the bine wrapper for any arch that you can compile static binary for. Appreciate your input @gen2brain as we ended up coming to similar solutions. |
|
@bobbaker6667 I agree it is nice to not depend on CGO, but in my case, I was already using Qt and libmpv/ffmpeg with all the dependencies, at that point, I do not care at all about pure Go. There is also an issue with using tor binary, for example, in Windows, it will first ask for permission for my app to use the internet, then once again for tor binary, probably more. When you embed tor it is just your app, I can see total memory usage, all connections, etc. Now, the option to have both via build tags would be perfect, bine library is very nicely done to allow both cases. I believe for now would be enough to support major platforms like Windows(386/amd64), Darwin(amd64/arm64), and Linux/Android(amd64/arm64). Btw. I forked from the repo that added support for macOS/iOS, I fixed arm64 support for M1/M2, so that should all work (I built binary but it is not tested). Of course, many cannot use it in real Windows, and I did have to patch MingW in Linux (that also must be resolved, why is needed, how come no one noticed so far, etc. I only hacked it). |
|
I have applied the two patch files to my compiler (mingw32) and have attempted to cross compile a windows binary with your fork of the library ''github.com/gen2brain/go-libtor", The error message has now changed which is something, I've attached the output of the compiler. I have a feeling that it is failing to cross compile openssl correctly, which might be due to failure to compile one of it's dependency's correctly, does your version attempt to compile all the prerequisites for openssl etc or is your version expecting libevent openssl / other tor requirements etc to already be built and installed to the compilers folder? Attached is the output Any ideas what could be going wrong here? After your post I appreciate the benefits of having the tor binary not shipped seperately and would like to attempt to try and cross compile a reproducable windows build using your library if anyone has any ideas on what I should be looking at from here would be greatly appreciated EDIT: my only other thought would be is this the response to accedently passing through -static etc LD flags to the compiler that builds the libevent/openssl? The command I'm using to build is this |
|
commenting a bit out of context, one general solution to windows is to embed the whole compiled tor binary into the Go program, upon start up, extract it on disk, in temp/whatever, then use ExePath. The downside is ~10/15mb increase on the binary size, though looking at my local linux build here using this repo it is 19mb, looks fairly identical increase. Dirty, but a rock solid solution of the poorman. I am always lost into those C cross compilation header things. |
|
any update on this? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: