GoLang No Es Para Windows
Tommye Hope
I have done some fixes for installer and application code to launch this in Windows XP. Unfortunatelly, it use bcrypt.dll. There are successful cases where it was replaced. But while I have no experience for this step. I have no access to Visual Studio 2019 to test my code and continue to fix.
As you can see. uint64_t inside bcrypt. I suppose Windows XP does not support thay so I can replace it but result is unknown.
Really I'm bad in coding when don't understand what code does and shoud does.
But the last golang which installs and creates XP compatible code is go 1.10 (very old). Newer versions of go are not compatible with XP, unfortunately.
I managed to build psiphon command line with go 1.10 for xp. And some people have patched and built the latest dnscrypt.
Cross compiling with Go is designed to be simple - we just set the environment variable GOOS for the target Operating System (and GOARCH if targeting a different architecture). Unfortunately when using native graphics calls the use of CGo in Fyne makes this a little harder.
To cross-compile a Fyne application you will also have to set CGO_ENABLED=1 which tells go to enable the C compiler (this is normally turned off when the target platform is different to the current system). Doing so unfortunately means that you must have a C compiler for the target platform that you are going to compile for.After installing the appropriate compilers you will also need to set the CC environment variable to tell Go which compiler to use.
With the environment variables above set you should be able to compile in the usual manner.If further errors occur it is likely to be due to missing packages. Some target platforms require additional libraries or headers to be installed for the compilation to succeed.
As a Linux system is able to cross compile to macOS and Windows easily it can be simpler to use a virtualised environment when you are not developing from Linux. Docker images are a useful tool for a complex build configuration and this works for Fyne as well. There are different tools that can be used. The tool recommended by the Fyne developers is fyne-cross. It has been inspired by xgo and uses a docker image built on top of the golang-cross image,that includes the MinGW compiler for windows, and a macOS SDK, along with the Fyne requirements.
While "containers are Linux," Podman also runs on Mac and Windows, where itprovides a native podman CLI and embeds a guest Linux system to launch yourcontainers. This guest is referred to as a Podman machine and is managed withthe podman machine command. Podman on Mac and Windows also listens forDocker API clients, supporting direct usage of Docker-based tools andprogrammatic access from your language of choice.
On Mac, each Podman machine is backed by a virtual machine.Once installed, the podman command can be run directly fromthe Unix shell in Terminal, where it remotely communicates with the podmanservice running in the Machine VM.
On Windows, each Podman machine is backed by a virtualized Windows Subsystem forLinux (WSLv2) distribution. Once installed, the podman command can be rundirectly from your Windows PowerShell (or CMD) prompt, where it remotelycommunicates with the podman service running in the WSL environment.Alternatively, you can access Podman directly from the WSL instance if youprefer a Linux prompt and Linux tooling.
The container-tools:rhel8 is the fast application stream, containing most recent rolling versions of the tools. Use the container-tools:2.0 stream for stable versions of Podman 1.6. The command yum module list container-tools shows the available streams.
Support for redirecting connections from the container host to services running inside a container is included for FreeBSD 13.3 and later. To enable this, first load the pf kernel module and enable PF support for these redirections using sysctl:
If any dependencies cannot be installed or are not sufficiently current, they have to be built from source.This will mainly affect Debian, Ubuntu, and related distributions, or RHEL where no subscription is active (e.g. Cloud VMs).
Be careful to double-check that the version of golang is new enough (i.e. go version), as of January 2022 version is 1.16.x or higher is required.The current minimum required version can always be found in the go.mod file.If needed, golang kits are available at Alternatively, go can be built from source as follows(it's helpful to leave the system-go installed, to avoid having to bootstrap go:
The latest version of at least one container runtime is expected to be installed on the system. crun or runc are some of the possibilities, and one is picked up as the default runtime by Podman (crun has priority over runc).Supported versions of crun or runc are available for example on Ubuntu 22.04.runc version 1.0.0-rc4 is the minimal requirement, which is available since Ubuntu 18.04.
This project is using go modules for dependency management. If the CI is complaining about a pull request leaving behind an unclean state, it is very likely right about it. After changing dependencies, make sure to run make vendor to synchronize the code with the go module and repopulate the ./vendor directory.
The mounts.conf files specify volume mount directories that are automatically mounted inside containers when executing the podman run or podman build commands. Container process can then use this content. The volume mount content does not get committed to the final image.
For example, a mounts.conf with the line "/usr/share/rhel/secrets:/run/secrets", the content of /usr/share/rhel/secrets directory is mounted on /run/secrets inside the container. This mountpoint allows Red Hat Enterprise Linux subscriptions from the host to be used within the container.
You need to mount the host rclone config dir at /config/rclone into the Dockercontainer. Due to the fact that rclone updates tokens inside its config file, and thatthe update process involves a file rename, you need to mount the whole host rcloneconfig dir, not just the single host rclone config file.
By default, the rclone binary inside a Docker container runs with UID=0 (root).As a result, all files created in a run will have UID=0. If your config and data filesreside on the host with a non-root UID:GID, you need to pass these on the containerstart command line.
If you want to access the RC interface (either via the API or the Web UI), it isrequired to set the --rc-addr to :5572 in order to connect to it from outsidethe container. An explanation about why this is necessary is present here.
It is possible to use rclone mount inside a userspace Docker container, and exposethe resulting fuse mount to the host. The exact docker run options to do that mightvary slightly between hosts. See, e.g. the discussion in thisthread.
Make sure you have git and Go installed.Go version 1.18 or newer is required, the latest release is recommended.You can get it from your package manager, or download it fromgolang.org/dl. Then you can run the following:
This will check out the rclone source in subfolder rclone, which you can latermodify and send pull requests with. Then it will build the rclone executablein the same folder. As an initial check you can now run ./rclone version(.\rclone version on Windows).
This assumes you have a GCC compatible C compiler (GCC or Clang) in your PATH,as it uses cgo. But on Windows, thecgofuse library that the cmountimplementation is based on, also supports buildingwithout cgo, i.e. by settingenvironment variable CGO_ENABLED to value 0 (static linking). This is how theofficial Windows release of rclone is being built, starting with version 1.59.It is still possible to build with cgo on Windows as well, by using the MinGWport of GCC, e.g. by installing it in a MSYS2distribution (make sure you install it in the classic mingw64 subsystem, theucrt64 version is not compatible).
Additionally, to build with mount on Windows, you must install the third partyutility WinFsp, with the "Developer" feature selected.If building with cgo, you must also set environment variable CPATH pointing tothe fuse include directory within the WinFsp installation(normally C:\Program Files (x86)\WinFsp\inc\fuse).
You may add arguments -ldflags -s to omit symbol table and debug information,making the executable file smaller, and -trimpath to remove references tolocal file system paths. The official rclone releases are built with both of these.
If you want to customize the version string, as reported bythe rclone version command, you can set one of the variables fs.Version,fs.VersionTag (to keep default suffix but customize the number),or fs.VersionSuffix (to keep default number but customize the suffix).This can be done from the build command, by adding to the -ldflagsargument value as shown below.
On Windows, the official executables also have the version information,as well as a file icon, embedded as binary resources. To get that with yourown build you need to run the following command before the build command.It generates a Windows resource system object file, with extension .syso, e.g.resource_windows_amd64.syso, that will be automatically picked up byfuture build commands.
The above command will generate a resource file containing version informationbased on the fs.Version variable in source at the time you run the command,which means if the value of this variable changes you need to re-run thecommand for it to be reflected in the version information. Also, if youoverride this version variable in the build command as described above, youneed to do that also when generating the resource file, or else it will stilluse the value from the source.
There are other make targets that can be used for more advanced builds,such as cross-compiling for all supported os/architectures, and packagingresults into release artifacts.See Makefileand cross-compile.gofor details.
7fc3f7cf58