Mingw-w64-install.exe Cannot Download Repository.txt

1 view

Skip to first unread message

Tyler Janicke

unread,

Jul 22, 2024, 10:31:33 AM7/22/24

to drivcolnaiti

Download installer mingw-w64-install.exe
Download repository.txt into the same folder as mingw-w64-install.exe
Run mingw-w64-install.exe
In the Settings window, change the Architecture to x86_64 and click Next
Follow instructions and verify that C:\Program Files\mingw-w64 has been made
To open mingw-w64 , run mingw-w64.bat in C:\Program Files\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\

I downloaded the installer from -w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/installer/mingw-w64-install.exe/download
I then ran the installer and after the first screen got a dialog that said:
Cannot download repository.txt[0]
I have tried running as administrator and still get the same error.

mingw-w64-install.exe cannot download repository.txt

Mingw-w64-install.exe Cannot Download Repository.txt ✏ ✏ ✏ https://ssurll.com/2zE7WW

Not sure if this is a recurring problem or if it's still there from before under certain circumstances, but I'm getting it now with mingw-w64-install.exe under windows 7 after confirming
sha256: 19b9a267a5b79913bf6a3a53cda83c3f7711cb6c879d48ccb97b4ed15c21fcf1

Take a look at it, the installer basically just download and unzip the build from one of these urls within repository.txt. Choose the url you want and download/upzip it manually. (In my case, I use 8.1.0x86_64posixsehrev0 setup)

I guess QLibrary is not very helpful to get the reasons why library cannot be loaded. You may try my small tool checkdll or classical "depends" to get more details why library cannot be loaded (like missing or broken dependencies - FreeType, libgcc_s_seh-1.dll, etc.).

So you're right, I'm definitely still running Windows style paths. I thought I was running WSL because I ran the command wsl --install, checked to make sure WSL was enabled in the settings, and then restarted the computer, but it looks like I'm still running Windows style paths - at this point, I cannot for the life of me figure out how to enable WSL.

Downloaded mingw-w64-install.exe from Downloads - Mingw-w64. Extracted and added to user PATH.
Downloaded vs_buildtools__1325967035.1634799115.exe from Thank you for downloading Visual Studio - Visual Studio.

The 12.2.MPACBTI-Rel1 release does not include AArch64 toolchains. If you cannot find the toolchain you require, in this release, then see the 12.3.Rel1 or later releases. Note that the 12.2.MPACBTI-Rel1 release has been superseded by the 13.2.Rel1 release, which includes Rel quality support for the Cortex-M PACBTI extension.

Rtools 4.3 is best tested on Windows 10 and Windows Server 2022. It is sometimes tested on Windows 11 and expected to work there well because of Windows backward compatibility. Rtools 4.3 might also work on older systems, but it is minimally tested: Rtools 4.3 version 5550 was tested before the release of R 4.3.0 and could build R from source also on Windows 7 and Windows 8.1. However, Msys2 officially does not support Windows 7 anymore: the build tools may not work properly. Some important libraries included in Rtools 4.3, including ICU, require at least Windows 7, and hence code built by Rtools 4.3 cannot be expected to work reliably on Windows older than 7.

Sometimes a package DLL is linked succesfully, but the DLL cannot be loaded. Sometimes it can be loaded on the machine where it was built, but not on another machine. One example is the linking of console API present on Windows 10, but not on Windows Server. A common problem why a DLL cannot be loaded is that a dependent DLL is not found (unlike static libraries, DLLs know their dependencies). This is a common problem which can happen on Windows with any toolchain.

Note: in the above, magick.dll is present on the path listed. It is some of its dependencies that is not found, but Windows would tell which one. The confusing error message comes directly from Windows and R cannot possibly fix that.

If you are trying to fix conda problems without removing thecurrent installation and you try to reinstall Miniconda orAnaconda to fix it, you get an error message that Minicondaor Anaconda is already installed and you cannot continue.

The message indicates that cx_freeze cannot be found in thedefault package channels. However, there may be acommunity-created version available and you can search for it byrunning the following command:

Odd, I cannot reproduce this problem anymore. I had to build it once from the command line, so that the .vst is created in the system folder once, and now I can build from within CLion without error. Even if I delete the .vst it will now re-create it (it only failed to do that the first time).

Due to the use of git-submodules, remotes::install_github() cannot be used toinstall the latest version of R package. Thus, one has to run git to check out the codefirst, see Obtaining the Source Code on how to initialize the git repository for XGBoost. Thesimplest way to install the R package after obtaining the source code is:

After the build finished, you will find the binary in "bin-release". To run it, stay in the MINGW 64bit shell.With Python3 you will initially see an error indicating that Python cannot find the encoding librariy.This is because the Python path is not set yet.You can do so by setting the "KLAYOUT_PYTHONPATH" environment variable. However it is easierto create a file KLayout reads to set the Python path:

For security reasons it may be useful to remove the preinstalled Wine bindings so Windows applications cannot be launched directly from a file manager or from the browser (Firefox offers to open EXE files directly with Wine!).If you want to do this, you may add the following to the [options] section in /etc/pacman.conf