github-actions[bot] on master
libgloss: bfin: fix subdir inst… (compare)
@fulcobohle, that should be done automatically if you use
MINGW_INSTALLS=mingw64 makepkg-mingw --noconfirm --noprogressbar -sCLf --nocheck as commented in :point_up: January 7, 2021 6:37 PM. See https://archlinux.org/pacman/makepkg.8.html:
Remove the $srcdir before building the package.
makepkg will not build a package if a built package already exists in the PKGDEST (set in makepkg.conf(5)) directory, which may default to the current directory. This allows the built package to be overwritten.
You might want to also remove
However, there is a very easy thing you can do for having this tested (viewing something is always easier than imagining...):
pkgrelvalue of the graphviz PKGBUILD recipe. Just increase it by one.
CI will start automatically, and it will attempt to build it. You will then see if it works as it does locally, or whether it fails.
ImportError: DLL load failed while importing pytrellis: %1 is not a valid Win32 application.? https://github.com/msys2/MINGW-packages/pull/7568/checks?check_run_id=1671268526#step:5:1369
If thats python then it means mixing of 32-bit and 64-bit DLL files
@naveen521kk, yes. The problem is that the recipe needs to build some assets which take more than 4GB of memory, so it crashes on MINGW32. I'm calling a MINGW64 bash from the PKGBUILD recipe (https://github.com/msys2/MINGW-packages/pull/7568/files#diff-3e2029a456a188ac9c6af1a1f77cbeabeb85b7ce75bbd7577a98d2b795fba704R53-R55), but it's not doing it properly. The DLLs are installed for both MINGW32 and MINGW64: https://github.com/msys2/MINGW-packages/pull/7568/files#diff-3e2029a456a188ac9c6af1a1f77cbeabeb85b7ce75bbd7577a98d2b795fba704R33-R34. The same recipe works on MINGW64.
mingw-w64-x86_64-pythonis already installed, because it's a dependency of
I would suggest not to mix those.
@Biswa96, honestly, I don't like doing it like this. But I think this is better than pushing an intermediate package to MSYS2 which is just to be used while building nextpnr.
nextpnr-chipdbsand then make
mingw-w64-nextpnrdepend on that.
You could setup a new sysconfig_blah.py for this cross scenario too ..
@mingwandroid, there is already a helper script for executing this step (https://github.com/msys2/MINGW-packages/pull/7568/files#diff-5525f40256b3131d3d3c52f57815fb1ca64d76f2bcc3a94cbf41ac9705fe2afd). Yet, I don't see where would
sysconfig_blah.py fit in there, since those are just calls to cmake.