Can't install Cmake
Closed this issue · 14 comments
This is what I get. (I removed the progress bars from the log, but they all were at 100%)
# pacman -S cmake
resolving dependencies...
looking for conflicting packages...
Packages (6) jsoncpp-1.9.4-1 libarchive-3.5.1-1 librhash-1.4.1-2 libuv-1.41.0-1 pkg-config-0.29.2-4 cmake-3.20.4-1
Total Download Size: 8.41 MiB
Total Installed Size: 41.66 MiB
:: Proceed with installation? [Y/n] y
:: Retrieving packages...
librhash-1.4.1-2-i686
pkg-config-0.29.2-4-i686
jsoncpp-1.9.4-1-any
libarchive-3.5.1-1-i686
libuv-1.41.0-1-i686
cmake-3.20.4-1-i686
Total (6/6)
(6/6) checking keys in keyring
(6/6) checking package integrity
(6/6) loading package files
(6/6) checking for file conflicts
(6/6) checking available disk space
:: Processing package changes...
(1/6) installing jsoncpp
JsonCpp headers and build libraries are now in jsoncpp-devel.
(2/6) installing libarchive
(3/6) installing librhash
(4/6) installing libuv
(5/6) installing pkg-config
(6/6) installing cmake
:: Running post-transaction hooks...
(1/1) Rebasing DLLs
rebase: failed to open rebase database "/etc/rebase.db.i386":
No such file or directory
error: command (/usr/bin/rebase /usr/bin/rebase -snT - ) failed to execute correctly
Any suggestions?
Where did the /usr/bin/rebase executable file go? Try to clean install msys2 using latest installer.
The exe is in usr\bin, but I think the missing rebase.db.i386 file is the culprit. I'm using the 32bit msys2 :P
Is it necessary to rebase, anyway? If I can go on without that step, I will.
Close the issue if there is nothing else. Thanks for the reply.
32bit msys2 was deprecated long time ago, see the release tag here https://github.com/msys2/msys2-installer/releases/tag/nightly-i686. But someone among us is using 32bit msys2 for development, handing over to @jeremyd2019
I think running /autorebase.bat might help here
That's a result of my adding a pacman hook to automatically rebase on 32-bit. Is it necessary to rebase? Maybe not, but on 32-bit it very quickly becomes necessary.
Make sure no msys processes are running (check taskmgr), then run autorebase.bat in the root of the msys32 install. That will create the rebase db, and rebase everything.
As far as 32-bit msys2 being deprecated: If at all possible, run 64-bit. If you really can't (stuck on 32-bit OS or running on official releases of Win10 for ARM64 which only has 32-bit emulation), packages were updated as of early July in the official repo, and you can use my 32-bit repo for continuing updates past that: https://github.com/jeremyd2019/msys2-build32/releases/tag/repo
For the 32bit issue, I am in fact using msys2-base-i686-20210705.tar.xz. Thanks for the link to the updated packs :)
I run autorebase and it produced the missing file. Do I need to rebase the libs manually or it's an optional step I can skip?
autorebase rebases all files, so you don't need to do any more rebasing
Ok, problem solved then. Thanks :)
You may well see "errors" from the rebase hook in future installs or updates, saying it can't rebase dlls that are in use. This is expected, and you can just run autorebase.bat with no running msys processes afterwards if you want to be sure they are rebased. But I've found that pacman seems to report all matching files to the hook, not just the ones that were changed in that operation, so there's a good chance the files it's complaining about don't actually need rebasing.
Is the rebasing necessary or it's just an optimization?
It is necessary, cygwin/msys2 dlls need to be loaded at the same address in every process for fork emulation to work. Windows will only do this if no dll overlaps another's address space. Due to the limitations of 32-bit address space, it is very likely that dlls will happen to overlap unless rebased with a database to ensure they don't. On 64-bit, there's enough address space to make "random" base addresses unlikely to overlap (though we did manage to get unlucky and have that happen recently)
Oh ok.
Can this be closed now?