Git Product home page Git Product logo

setup-msys2's Introduction

'Test' workflow Status 'Example PKGBUILD' workflow Status

Setup MSYS2

setup-msys2 is a GitHub Action (GHA) to setup an MSYS2 environment (i.e. MSYS, MINGW32, MINGW64, UCRT64, CLANG32, CLANG64 and/or CLANGARM64 shells)

It provides:

  • Easy installation and updates
  • Easy package installation including caching for faster re-runs
  • A shell helper for running your commands or your whole job in an MSYS2 environment

Usage

  - uses: msys2/setup-msys2@v2

Then, for scripts:

  - shell: msys2 {0}
    run: |
      uname -a

It is also possible to execute specific commands from cmd/powershell scripts/snippets. In order to do so, -c is required:

  - shell: powershell
    run: msys2 -c 'uname -a'
  - shell: cmd
    run: msys2 -c 'uname -a'

Default shell

In order to reduce verbosity, it is possible to set msys2 as the default shell. For example:

  defaults:
    run:
      shell: msys2 {0}
  steps:
  - uses: msys2/setup-msys2@v2
    with:
      update: true
      install: >-
        curl
        git
  - uses: actions/checkout@v4

Build matrix

It is common to test some package/tool on multiple environments, which typically requires installing different sets of packages through option install. GitHub Actions' strategy and matrix fields allow to do so, as explained in docs.github.com: Configuring a build matrix and docs.github.com: jobs.<job_id>.strategy.matrix. See, for instance:

  strategy:
    matrix:
      include:
        - { sys: mingw64, env: x86_64 }
        - { sys: mingw32, env: i686 }
        - { sys: ucrt64,  env: ucrt-x86_64 }
        - { sys: clang64, env: clang-x86_64 }
  steps:
    - uses: msys2/setup-msys2@v2
      with:
        msystem: ${{matrix.sys}}
        install: mingw-w64-${{matrix.env}}-openssl

Alternatively, option pacboy allows using a single matrix variable:

  strategy:
    matrix:
      sys:
        - mingw64
        - mingw32
        - ucrt64
        - clang64
  steps:
    - uses: msys2/setup-msys2@v2
      with:
        msystem: ${{matrix.sys}}
        pacboy: openssl:p

Furthermore, .github/workflows/PKGBUILD.yml is a Reusable Workflow to build and test a package in GitHub Actions using a PKGBUILD recipe. It can be used along with matrix (a Composite Action), as shown in .github/workflows/Tool.yml.

Note: By default, GitHub Actions terminates any running jobs if any job in matrix fails. This default behavior can be disabled by setting fail-fast: false in strategy section. See docs.github.com: jobs.<job_id>.strategy.fail-fast for more details.

Find similar patterns in the following workflows:

Find further details at #171 and #102.

Options

msystem

  • Type: string
  • Allowed values: MSYS | MINGW64 | MINGW32 | UCRT64 | CLANG32 | CLANG64 | CLANGARM64
  • Default: MINGW64

The default environment that is used in the msys2 command/shell provided by this action.

MSYS2 recommends UCRT64 nowadays as the default instead of MINGW64.

For example:

  - uses: msys2/setup-msys2@v2
    with:
      msystem: UCRT64

The environment can be later overridden using the MSYSTEM environment variable if needed. This is useful when multiple commands need to be executed in different contexts. For example, in order to build a PKGBUILD file and then test the installed artifact:

  - uses: msys2/setup-msys2@v2
    with:
      msystem: MSYS
  - shell: msys2 {0}
    run: |
      makepkg-mingw -sCLfc --noconfirm --noprogressbar
      pacman --noconfirm -U mingw-w64-*-any.pkg.tar.xz
  - run: |
      set MSYSTEM=UCRT64
      msys2 -c '<command to test the package>'

update

  • Type: boolean
  • Default: false

By default, the installation is not updated; hence package versions are those of the installation tarball. By setting option update to true, the action will update the package database and all already installed packages.

  - uses: msys2/setup-msys2@v2
    with:
      update: true

install

  • Type: string
  • Allowed values: a whitespace separated list of packages
  • Default: -

Installing additional packages after updating the system is supported through option install. The package or list of packages are installed through pacman --noconfirm -S --needed --overwrite *.

  - uses: msys2/setup-msys2@v2
    with:
      update: true
      install: >-
        git
        curl

pacboy

  • Type: string
  • Allowed values: s whitespace separated list of packages
  • Default: -

Installing additional packages with pacboy after updating the system is supported through option pacboy. The package or list of packages are installed through pacboy --noconfirm -S --needed.

  strategy:
    fail-fast: false
    matrix:
      sys: [ MINGW64, MINGW32, UCRT64, CLANG64 ]
  steps:
  - uses: msys2/setup-msys2@v2
    with:
      msystem: ${{matrix.sys}}
      install: >-
        git
        curl
      pacboy: >-
        openssl:p

platform-check-severity

  • Type: string
  • Allowed values: warn | fatal
  • Default: fatal

By default (fatal), throw an error if the runner OS is not Windows. If set to warn, simply log a message and skip the rest:

  - uses: msys2/setup-msys2@v2
    with:
      platform-check-severity: warn

Advanced Options

These options are rarely needed and shouldn't be used unless there is a good reason.

path-type

  • Type: string
  • Allowed values: minimal | strict | inherit
  • Default: minimal

Defines which parts of the Windows $env:PATH environment variable leak into the MSYS2 environment. Allowed values:

  • strict: do not inherit anything from $env:PATH.
  • minimal (default): only inherit the default Windows paths from $env:PATH (so that cmd.exe and powershell.exe are available for example).
  • inherit: inherit everything; warning: this can lead to interference with other tools installed on the system.
  - uses: msys2/setup-msys2@v2
    with:
      path-type: minimal

This option corresponds to the MSYS2_PATH_TYPE setting in MSYS2; hence it can be overridden per step through env. See msys2/MSYS2-packages: filesystem/profile for further details about the configuration of each option.

cache

  • Type: boolean
  • Default: true

By default (true), caches various things between runs to make repeated runs faster.

  - uses: msys2/setup-msys2@v2
    with:
      cache: false

location

  • Type: string
  • Default: -

Specify an alternate location where to install MSYS2 to.

  - uses: msys2/setup-msys2@v2
    with:
      location: D:\

release

  • Type: boolean
  • Default: true

If true (the default) it makes a fresh install of the latest MSYS2 installer release. If false it will try to re-use the existing MSYS2 installation which is part of the official GitHub Actions Runner Images.

  - uses: msys2/setup-msys2@v2
    with:
      release: false

Known Problems

actions/checkout and line endings

In case you use the actions/checkout action in your workflow and haven't configured git attributes for line endings, then git might auto convert your text files in the git repo to Windows line endings, which might lead to problems with tools provided by MSYS2.

To work around this issue disable the auto conversion before running actions/checkout:

  steps:
  - run: git config --global core.autocrlf input
  - uses: actions/checkout@v4

setup-msys2's People

Contributors

biswa96 avatar daniele-rapagnani avatar ecco avatar eine avatar fabiangreffrath avatar gitmensch avatar iamfirecracker avatar jeremyd2019 avatar lazka avatar mehdichinoune avatar mstorsjo avatar naveen521kk avatar panchabhuta avatar past-due avatar rasa avatar umarcor avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

setup-msys2's Issues

Supress error message in case of a failing mirror

I get following error(s)

error: failed retrieving file 'mingw64.db' from repo.msys2.org : Connection timed out after 10000 milliseconds
error: failed retrieving file 'msys.db' from repo.msys2.org : Connection timed out after 10000 milliseconds
error: failed retrieving file 'libatomic_ops-7.6.10-1-any.pkg.tar.xz' from repo.msys2.org : Connection timed out after 10000 milliseconds

Down for Everyone or Just Me reports (https://downforeveryoneorjustme.com/repo.msys2.org)

It's not just you! repo.msys2.org is down.

Stackoverflow says that one should configure a mirror somewhere. I don't know where these configuration is hosted when using this action. Therefore the question:

Is it possible to add a configuration option mirror:. One could place a mirror from https://github.com/msys2/MSYS2-packages/blob/master/pacman-mirrors/mirrorlist.msys.

Since everything installs fine, the wish is that the error message should be info. Quick and dirty propsoal:

info: failed retrieving file 'libatomic_ops-7.6.10-1-any.pkg.tar.xz' from repo.msys2.org : Connection timed out after 10000 milliseconds. Could download the file from somehwere else.

Use case: build matrix for 32bit and 64 bit

A common CI use case is building your project for 32bit and 64bit, which in the setup-msys2 case also means the package names passed to "install" are different, and then in bash depending on the build do something different maybe.

I'd like to see an example for this in the README.

Save package cache as a post build step

This action is pretty neat, but one thing that would be nice is if saving the package cache could be deferred until after the build is done.

This would be ideal because I have a build script that installs many dependencies (and where it's not really practical to list them out directly in the workflows yml), so it would be nice if it cached those packages too. Not entirely sure if this is possible, although I see actions/cache does it as a post build step.

Environment variables in $GITHUB_ENV ignored for PATH and PKG_CONFIG_PATH

I'm using $GITHUB_ENV to modify environment variables. Sometimes it works, sometimes it doesn't.

In my CI yaml file, I have this:

    - name: Setup paths and env
      run: |
        mkdir -p $HOME/.local/bin
        mkdir -p $HOME/.local/lib/pkgconfig
        echo "PKG_CONFIG_PATH=$HOME/.local/lib/pkgconfig:$PKG_CONFIG_PATH" >> $GITHUB_ENV
        echo "LD_LIBRARY_PATH=$HOME/.local/lib:$LD_LIBRARY_PATH" >> $GITHUB_ENV
        echo "PATH=$HOME/.local/bin:$PATH" >> $GITHUB_ENV
        echo "ANT_HOME=foo" >> $GITHUB_ENV
        echo "ANT_HOME2=bar" >> $GITHUB_ENV

And later on in the same ci, I have this:

    - name: Display information about build environment
      continue-on-error: true
      run: |
        env
        g++ --version
        clang++ --version
        pkg-config --version
        m4 --version

The first one should put some new variables into $GITHUB_ENV. Those variable then become part of the execution environment for the second one. We can see that it somewhat works. Here's the log of the CI run:

2020-12-25T16:24:59.5787589Z ##[group]Run env
2020-12-25T16:24:59.5788080Z οΏ½[36;1menvοΏ½[0m
2020-12-25T16:24:59.5788444Z οΏ½[36;1mg++ --versionοΏ½[0m
2020-12-25T16:24:59.5788831Z οΏ½[36;1mclang++ --versionοΏ½[0m
2020-12-25T16:24:59.5789451Z οΏ½[36;1mpkg-config --versionοΏ½[0m
2020-12-25T16:24:59.5789887Z οΏ½[36;1mm4 --versionοΏ½[0m
2020-12-25T16:24:59.5792315Z shell: D:\a\_temp\msys\msys2.CMD {0}
2020-12-25T16:24:59.5792732Z env:
2020-12-25T16:24:59.5793218Z   MSYSTEM: MINGW64
2020-12-25T16:24:59.5793969Z   PKG_CONFIG_PATH: /home/runneradmin/.local/lib/pkgconfig:/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig
2020-12-25T16:24:59.5794828Z   LD_LIBRARY_PATH: /home/runneradmin/.local/lib:
2020-12-25T16:24:59.5796094Z   PATH: /home/runneradmin/.local/bin:/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
2020-12-25T16:24:59.5797320Z   ANT_HOME: foo
2020-12-25T16:24:59.5797714Z   ANT_HOME2: bar
2020-12-25T16:24:59.5798095Z   NUM_CPUS: 8
2020-12-25T16:24:59.5798458Z ##[endgroup]
2020-12-25T16:24:59.9898476Z USERDOMAIN=fv-az177-439
2020-12-25T16:24:59.9899859Z OS=Windows_NT
2020-12-25T16:24:59.9901764Z LD_LIBRARY_PATH=/home/runneradmin/.local/lib:
2020-12-25T16:24:59.9904727Z COMMONPROGRAMFILES=C:\Program Files\Common Files
2020-12-25T16:24:59.9919605Z PROCESSOR_LEVEL=6
2020-12-25T16:24:59.9921928Z PSModulePath=C:\Modules\azurerm_2.1.0;C:\Modules\azure_2.1.0;C:\Users\packer\Documents\WindowsPowerShell\Modules;C:\Program Files\WindowsPowerShell\Modules;C:\windows\system32\WindowsPowerShell\v1.0\Modules;C:\Program Files\Microsoft SQL Server\130\Tools\PowerShell\Modules\;C:\Program Files (x86)\Google\Cloud SDK\google-cloud-sdk\platform\PowerShell
2020-12-25T16:25:00.0211451Z ANT_HOME2=bar
2020-12-25T16:25:00.0265443Z ANT_HOME=foo
2020-12-25T16:25:00.0272362Z PKG_CONFIG_PATH=/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig
2020-12-25T16:25:00.0267298Z PATH=/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

(I didn't include all the lines in the above log to keep it brief. Full log here.)

Notice how the environment for this command includes setting variables like MSYSTEM, PATH, LD_LIBRARY_PATH and others in the very first lines. And then when we view the results of env, some of those were set into the environment correctly, such as ANT_HOME and ANT_HOME2 and LD_LIBRARY_PATH. But others, like PKG_CONFIG_PATH and PATH were not taken from the environment.

I expected that all the values in the environment would make it into the result of env, not just some of them.

Getting error "Inappropriate ioctl for device" upon various commands within msys shell

For example, in this recent build log of mine, the error of the subject line is printed upon running the action msys2/setup-msys2 itself:
image

Installing additional packages...
  C:\windows\system32\cmd.exe /D /S /C D:\a\_temp\msys\msys2.cmd pacman --noconfirm -S --needed git diffutils mingw-w64-x86_64-clang make mingw-w64-x86_64-cmake mingw-w64-x86_64-boost mingw-w64-x86_64-mesa mingw-w64-x86_64-openexr mingw-w64-x86_64-intel-tbb mingw-w64-x86_64-glm mingw-w64-x86_64-glew mingw-w64-x86_64-dbus patch mingw-w64-x86_64-openvdb
  
  D:\a\curv\curv>setlocal
  bash: cannot set terminal process group (-1): Inappropriate ioctl for device
  bash: no job control in this shell
  resolving dependencies...
  looking for conflicting packages...

The same error message is printed upon the following action:

- shell: msys2 {0}
  run: git describe --dirty

In all cases, the message seems to be just printed; the build continues normally.

PS: This is great action, very easy to use -- in comparison to how one needs to install/configure MSYS2 on Travis! Thanks for developing! πŸ˜„

msys2 shell error handling issues

See the following workflow: https://github.com/lazka/msys2-workflow-error-test/actions/runs/167621530/workflow

The ubuntu bash runs by default with set -e (It's documented as set -e o pipefail here https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#exit-codes-and-error-action-preference but it doesn't look like that's true)

The msys2 shell doesn't which means a failing command doesn't fail the step, which is imo bad, at least for a default behavior in CI. It should at least default to -e

Any ideas?

Thanks!

No issue to report here, just wanted to say thanks for fixing the msys2 update issue that occurred yesterday, it was making me crazy! The new install option also works great.

signature from "Alexey Pavlov (Alexpux) <[email protected]>" is invalid

I'm getting many errors about invalid signatures in my CI:

2020-12-30T07:53:10.1381061Z error: mingw-w64-x86_64-icu: signature from "Alexey Pavlov (Alexpux) <[email protected]>" is invalid
2020-12-30T07:53:10.1382702Z :: File /var/cache/pacman/pkg/mingw-w64-x86_64-icu-68.2-1-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
2020-12-30T07:53:10.1395297Z Do you want to delete it? [Y/n] error: mingw-w64-x86_64-boost: signature from "Alexey Pavlov (Alexpux) <[email protected]>" is invalid
2020-12-30T07:53:10.1396779Z 
2020-12-30T07:53:10.1398296Z :: File /var/cache/pacman/pkg/mingw-w64-x86_64-boost-1.75.0-1-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
2020-12-30T07:53:10.1416780Z Do you want to delete it? [Y/n] error: mingw-w64-x86_64-harfbuzz: signature from "Alexey Pavlov (Alexpux) <[email protected]>" is invalid
2020-12-30T07:53:10.1418414Z 
2020-12-30T07:53:10.1419562Z :: File /var/cache/pacman/pkg/mingw-w64-x86_64-harfbuzz-2.7.3-1-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
2020-12-30T07:53:10.1420770Z Do you want to delete it? [Y/n] error: failed to commit transaction (invalid or corrupted package)
2020-12-30T07:53:10.1731366Z 
2020-12-30T07:53:10.1734005Z Errors occurred, no packages were upgraded.
2020-12-30T07:53:10.1797630Z ##[error]The process 'C:\windows\system32\cmd.exe' failed with exit code 1

Similar to these: Alexpux/MSYS2-pacman#58

Is it a problem only in this repo or in all of msys2 or all of pacman?

Maybe skip "gpg: refreshing 13 keys"

Continuing my journey to nitpick everything. I hope that's OK.

So, on the first start we have:

Sun, 12 Jul 2020 22:28:19 GMT   gpg: refreshing 13 keys from hkps://hkps.pool.sks-keyservers.net
Sun, 12 Jul 2020 22:28:19 GMT   gpg: key 794DCF97F93FC717: "Martell Malone (martell) <[email protected]>" not changed
Sun, 12 Jul 2020 22:28:22 GMT   gpg: key FA11531AA0AA7F57: "Christoph Reiter (MSYS2 development key) <[email protected]>" not changed
Sun, 12 Jul 2020 22:28:30 GMT   gpg: key 4DF3B7664CA56930: "Ray Donnelly (MSYS2 Developer) <[email protected]>" not changed
Sun, 12 Jul 2020 22:28:30 GMT   gpg: key D595C9AB2C51581E: 1 signature not checked due to a missing key
Sun, 12 Jul 2020 22:28:30 GMT   gpg: key D595C9AB2C51581E: "Martell Malone (MSYS2 Developer) <[email protected]>" not changed
Sun, 12 Jul 2020 22:28:30 GMT   gpg: key 974C8BE49078F532: "David Macek <[email protected]>" not changed
Sun, 12 Jul 2020 22:28:30 GMT   gpg: key 5F92EFC1A47D45A1: "Alexey Pavlov (Alexpux) <[email protected]>" not changed
Sun, 12 Jul 2020 22:28:30 GMT   gpg: key 9F418C233E652008: "Ignacio Casal Quinteiro <[email protected]>" not changed
Sun, 12 Jul 2020 22:28:30 GMT   gpg: key 755B8182ACD22879: "Christoph Reiter (MSYS2 master key) <[email protected]>" not changed
Sun, 12 Jul 2020 22:28:30 GMT   gpg: key BBE514E53E0D0813: 1 signature not checked due to a missing key
Sun, 12 Jul 2020 22:28:30 GMT   gpg: key BBE514E53E0D0813: "Ray Donnelly (MSYS2 Developer - master key) <[email protected]>" not changed
Sun, 12 Jul 2020 22:28:30 GMT   gpg: key DA7EF2ABAEEA755C: "Martell Malone (martell) <[email protected]>" not changed
Sun, 12 Jul 2020 22:28:30 GMT   gpg: key 790AE56A1D3CFDDC: "David Macek (MSYS2 master key) <[email protected]>" not changed
Sun, 12 Jul 2020 22:28:30 GMT   gpg: key F40D263ECA25678A: "Alexey Pavlov (Alexpux) <[email protected]>" not changed
Sun, 12 Jul 2020 22:28:30 GMT   gpg: Total number processed: 12
Sun, 12 Jul 2020 22:28:30 GMT   gpg:              unchanged: 12

Which means 11 seconds lost for basically no change. (the thing executed here is this I think: https://github.com/msys2/MSYS2-packages/blob/3a99587ca16686fd0e2e74ffacabd2be15dd85ae/filesystem/07-pacman-key.post#L7)

I wonder if we should somehow skip that part. If we ever need to update the existing keys before an update we can always push out a new installer and update the action to use it. I haven't thought about how to skip it yet.

Action fails to use correct shell for calling cmake dependencies

I'm trying to use GH actions over travis builds since gh is significantly faster, however I'm running into issues. Our cmake-based build systems depends on calling couple mingw external apps, such as intltool-merge, however build proceeds using cmd instead of msys2.

PR and build woes can be seen here: darktable-org/darktable#6603

I'm open to any suggestion on how to improve build system to work :)

MSYS2_PATH_TYPE default

The default in MSYS2 is "minimal" aka MSYS2 directories + default Windows directories. setup-msys2 defaults to "strict" which might be unexpected (things like cmd.exe are not available).

I wonder if changing the default now would still be possible.

New release

It would be nice if we'd get a new release out using 20200629 so we start with a fresh keyring.

I can create one too if wanted (I'd follow the steps in the README)

Changes to PATH variable not recognized by the msys2 shell

I am trying to install a Perl module installer called cpanm. Here, is my workflow file (simplified for debugging purposes):

name: windows-msys2
on: [push, pull_request]
jobs:
  build-dist:
    runs-on: windows-2019
    defaults:
      run:
        shell: msys2 {0}
    steps:
      - uses: msys2/setup-msys2@v2
        with:
          msystem: MSYS
          path-type: minimal
          install: base-devel
      - uses: actions/checkout@v2
      - name: setup perl locallib
        run: |
          TOPDIR=$(cygpath "$GITHUB_WORKSPACE")
          PERL_LOCAL_LIB_ROOT="$TOPDIR/perl5"
          >>"$GITHUB_ENV" echo "PERL_LOCAL_LIB_ROOT=$PERL_LOCAL_LIB_ROOT"
          >>"$GITHUB_ENV" echo "PERL5LIB=$PERL_LOCAL_LIB_ROOT/lib/perl5"
          >>"$GITHUB_ENV" echo "PERL_MB_OPT=--install_base \"$PERL_LOCAL_LIB_ROOT/\""
          >>"$GITHUB_ENV" echo "PERL_MM_OPT=INSTALL_BASE=$PERL_LOCAL_LIB_ROOT"
          >>"$GITHUB_ENV" echo "PATH=$PERL_LOCAL_LIB_ROOT/bin:$PATH"
      - name: install cpanm
        run: |
          echo "PATH=$PATH"
          cpan App::cpanminus  # This command installs cpanm
          export PATH
          ls -l $PERL_LOCAL_LIB_ROOT/bin/cpanm
      - name: test cpanm
        run: |
          ls -l $PERL_LOCAL_LIB_ROOT/bin/cpanm
          export PATH
          cpanm -v Path::Tiny

Here is a link to the log for failed workflow run.

As can be seen, the step "install cpanm" installs the executable script cpanm into the directory /d/a/msys2-gha-path-test/msys2-gha-path-test/perl5/bin and in step "test cpanm" ls -l shows that the script exists in the correct directory. Also PATH is exported and contains:

PATH: /d/a/msys2-gha-path-test/msys2-gha-path-test/perl5/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

Notice that the first entry in PATH is the directory where the script cpanm is installed.

Still, when the runner executes the next command cpanm -v Path::Tiny it fails with

D:\a\_temp\fee6b146-c300-4100-800d-0ad7b7e626b2: line 3: cpanm: command not found
15
Error: Process completed with exit code 127.

What can be the problem here?

Don't understand how to do 32-bit build with GitHub Actions

Hi all,

On my project, I can build 64-bit exe for Windows with the following job :

  msys2-windows-x64:
    runs-on: windows-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v2
      - uses: msys2/setup-msys2@v2
        with:
          update: true
          install: >-
            pkg-config
            make
            git
            mingw-w64-i686-gcc
            mingw-w64-x86_64-gcc
            mingw-w64-x86_64-SDL2
            mingw-w64-x86_64-libogg
            mingw-w64-x86_64-libvorbis
      - shell: msys2 {0}
        name: Compile the project
        run : |
          set MSYSTEM=MINGW64
          make CXX=x86_64-w64-mingw32-g++ CXXFLAGS=-static
      - name: Move artifacts
        run: |
          mkdir artifacts
          move ./bin/*.exe ./artifacts 
      - name: Upload artifacts
        uses: actions/[email protected]  
        with:
          name: msys2-windows-x64
          path: artifacts

So I create from this a 32-bit method like this :

msys2-windows:
    runs-on: windows-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v2
      - uses: msys2/setup-msys2@v2
        with:
          update: true
          install: >-
            pkg-config
            make
            git
            mingw-w64-i686-toolchain
            mingw-w64-i686-SDL2
            mingw-w64-i686-libogg
            mingw-w64-i686-libvorbis
      - shell: msys2 {0}
        name: Compile the project
        run : |
          set MSYSTEM=MINGW32
          make CXX=i686-w64-mingw32-g++ CXXFLAGS=-static
      - name: Move artifacts
        run: |
          mkdir artifacts
          move ./bin/*.exe ./artifacts 
      - name: Upload artifacts
        uses: actions/[email protected]  
        with:
          name: msys2-windows
          path: artifacts

But the issues are :
-> even with "set MSYSTEM=MINGW32", i'm always on MINGW64
-> pkg-config on my makefile doesn't found the SDL2, libogg and libvorbis library ( wrong path ? ) but in 64bit build it works
-> i686-w64-mingw32-g++ is not found but mingw-w64-i686-toolchain is installed

Can you help me to understand what are my errors please ?
Thanks for your time and answers !

Jack0b0

install: pass --needed

Things passed to install should be installed with --needed so that when they already exist they don't get reinstalled.

Provide a way to cache the installation

I currently have the workflow file below. Now I am still fiddling with it and whenever I add or change a step that is even unrelated to the msys2/setup-msys2 step, in the next run this action will still redownload and reinstall all packages.

name: Build Binaries and Deploy

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:

  windows-build: 
    runs-on: windows-latest

    steps:
    - uses: actions/checkout@v2
      with:
        submodules: recursive
      
    - uses: msys2/setup-msys2@v1
      with:
        msystem: MINGW64
        update: true
        cache: true
        install: "git diffutils mingw-w64-x86_64-clang make mingw-w64-x86_64-cmake mingw-w64-x86_64-boost mingw-w64-x86_64-mesa mingw-w64-x86_64-openexr mingw-w64-x86_64-intel-tbb mingw-w64-x86_64-glm mingw-w64-x86_64-glew mingw-w64-x86_64-dbus patch mingw-w64-x86_64-openvdb"

'mingw32-make' is not recognized as an internal or external command,

after add this :
- name: install correct version of mingw
uses: msys2/setup-msys2@v2
with:
msystem: MINGW32
path-type: minimal

when i build some problem, it said:
'mingw32-make' is not recognized as an internal or external command,
why?

i have added shell: msys2 {0} in the step.

- name: configure-pkt_sim
  shell: msys2 {0}
  run: ./pkt_sim.config.bat 5.9

undefined reference to winsock functions

Hi, I'm using action msys2/setup-msys2 to implement CI, the env as follow:
MSYS2 + Vala(GCC) + Meson

in the meson.build script, I have tried these command to solve my problem:
add_project_link_arguments('-lmswsock', language: 'c')
add_project_arguments('-lws_32', language: 'c')
add_project_arguments('-lwsock', language: 'c')

[272/272] Linking target src/kangaroo.exe
FAILED: src/kangaroo.exe 
cc @src/kangaroo.exe.rsp
D:/a/_temp/msys/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: src/25a6634@@kangaroo@exe/meson-generated_Illuminate_Supports_Network_tunnel_http.c.obj: in function `kangaroo_illuminate_supports_network_http_tunnel_forward_tunnel_stream':
D:\a\kangaroo\kangaroo\build/../src/Illuminate/Supports/Network/tunnel_http.vala:218: undefined reference to `WSACreateEvent'
D:/a/_temp/msys/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:\a\kangaroo\kangaroo\build/../src/Illuminate/Supports/Network/tunnel_http.vala:219: undefined reference to `WSACreateEvent'
D:/a/_temp/msys/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:\a\kangaroo\kangaroo\build/../src/Illuminate/Supports/Network/tunnel_http.vala:220: undefined reference to `WSAEventSelect'
D:/a/_temp/msys/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:\a\kangaroo\kangaroo\build/../src/Illuminate/Supports/Network/tunnel_http.vala:221: undefined reference to `WSAEventSelect'
D:/a/_temp/msys/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:\a\kangaroo\kangaroo\build/../src/Illuminate/Supports/Network/tunnel_http.vala:231: undefined reference to `WSAResetEvent'
D:/a/_temp/msys/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:\a\kangaroo\kangaroo\build/../src/Illuminate/Supports/Network/tunnel_http.vala:268: undefined reference to `WSAResetEvent'

but the meson.build work on my local MSYS2 environment....

Use a dummy startGroup at the start

Currently the first login shell is created for disabling CheckSpace which includes all the first time things that get run. Haven an empty login shell at the start would make it easier to see which stage takes which amount of time.

Streamlining matrix builds

I'm interested in streamlining matrix builds that include Linux and MacOS.

Currently, msys2/setup-msys2 fails on non-Windows platforms. It would be nice if there was an option to not fail and instead do nothing. This would mean I don't have to conditionally perform the installation.

Additionally, having an extra msys2do shell command which internally runs msys2 -c <cmd> on Windows and runs <cmd> directly everywhere else also helps.

database file for 'ucrt64' does not exist

It seems this GitHub action failed last night to setup. Here is the interesting part of the log:

Run msys2/setup-msys2@v2
Downloading MSYS2...
Extracting MSYS2...
Disable Key Refresh...
Restoring package cache...
Starting MSYS2 for the first time...
Disable CheckSpace...
Updating packages...
Killing remaining tasks...
Final system upgrade...
  C:\Windows\system32\cmd.exe /D /S /C D:\a\_temp\msys\msys2.cmd -c "'pacman' '--noconfirm' '-Suu' '--overwrite' '*'"
  warning: database file for 'ucrt64' does not exist (use '-Sy' to download)
  :: Starting core system upgrade...
   there is nothing to do
  :: Starting full system upgrade...
  error: failed to prepare transaction (could not find database)
  Error: The process 'C:\Windows\system32\cmd.exe' failed with exit code 1

Could it be that the packages servers were down?

error: not enough free disk space

Trying to run a build using qt5 static and few more libs but I'm facing this error:

  checking available disk space...
  error: Partition / too full: 2746279 blocks needed, 2627211 blocks free
  error: not enough free disk space
  error: failed to commit transaction (not enough free disk space)
  Errors occurred, no packages were upgraded.
  Error: The process 'C:\Windows\system32\cmd.exe' failed with exit code 1

This is the command from my workflow:

    - uses: msys2/setup-msys2@v2
      with:
        update: true
        install: >-
          git
          zip
          upx
          base-devel
          mingw-w64-x86_64-toolchain
          mingw-w64-x86_64-cmake
          mingw-w64-x86_64-gettext
          mingw-w64-x86_64-qt5-static
          mingw-w64-x86_64-libsndfile
          mingw-w64-x86_64-mpg123
          mingw-w64-x86_64-libvorbis
          mingw-w64-x86_64-opusfile
          mingw-w64-x86_64-libgme
          mingw-w64-x86_64-libmpcdec
          mingw-w64-x86_64-wavpack
          mingw-w64-x86_64-ffmpeg
          mingw-w64-x86_64-libbs2b
          mingw-w64-x86_64-libsidplayfp
          mingw-w64-x86_64-libopenmpt
          mingw-w64-x86_64-liblastfm

Is there a way around this? I see that the static qt package is quite big (6.13 GB)

pacman fails due to dependency conflict

Here's a new error that just started showing up in our CI builds:

  :: Starting core system upgrade...
  warning: terminate other MSYS2 programs before proceeding
  resolving dependencies...
  looking for conflicting packages...
  error: failed to prepare transaction (could not satisfy dependencies)
  :: installing filesystem (2020.02-3) breaks dependency 'msys2-base' required by dash
  ##[error]The process 'C:\windows\system32\cmd.exe' failed with exit code 1

https://github.com/gambit/gambit/runs/800489774#step:3:183

Perhaps something changed recently in MSYS2 that caused this?

Error starting bash

Thanks for the very useful GHA !

I'm trying to use it, but when I call msys2do it seems that bash is crashing, is anyone experiencing this too ? My github action is quite small and includes almost only setup-msys2, I'll post here (pamac install is being called after since install apparently did not worked, but other commands that I call after also crash bash):

name: C/C++ CI

on:
push:
pull_request:

jobs:
windows-build:
runs-on: windows-2019
steps:
- uses: actions/checkout@v2
- uses: numworks/setup-msys2@v1
with:
update: true
- name: start build
run: msys2do pamac -S git base-devel gcc mingw-w64-x86_64-lapack mingw-w64-x86_64-winpthreads-git mingw-w64-x86_64-readline mingw-w64-x86_64-suitesparse mingw-w64-x86_64-metis --no-confirm

I got the following error:

Run msys2do pamac -S git base-devel gcc mingw-w64-x86_64-lapack mingw-w64-x86_64-winpthreads-git mingw-w64-x86_64-readline mingw-w64-x86_64-suitesparse mingw-w64-x86_64-metis --no-confirm
D:\a\cbc-binaries\cbc-binaries>setlocal
D:\a\cbc-binaries\cbc-binaries>IF NOT DEFINED MSYS2_PATH_TYPE set MSYS2_PATH_TYPE=strict
D:\a\cbc-binaries\cbc-binaries>D:\a_temp\msys\msys64\usr\bin\bash.exe -ilc "cd $OLDPWD && pamac -S git base-devel gcc mingw-w64-x86_64-lapack mingw-w64-x86_64-winpthreads-git mingw-w64-x86_64-readline mingw-w64-x86_64-suitesparse mingw-w64-x86_64-metis --no-confirm"
0 [main] bash (6560) shared_info::initialize: size of shared memory region changed from 51128 to 40888

Anyone experiencing similar issue ?

Create a script to execute msys2 and maintain PATH and PKG_CONFIG_PATH

@eyal0 you might want to extend this Action with those two lines, in order to make them easier to maintain and reuse. I would suggest the following:

  1. Fork this repo.
  2. Create a feature branch.
  3. Locally, execute npm run install. Either get NodeJs, use a node container, or use WSL.
  4. Edit https://github.com/msys2/setup-msys2/blob/master/main.js#L163-L174, so that an additional file is written, which contains your custom code.
  5. Execute npm run pkg.
  6. Add index.js, commit and push.
  7. Edit your workflow for using eyal0/setup-msys2@feature-branch-name and change the shell: yourcustomentrypoint {0}. Commit and push.
  8. Go back to 4-6, and restart the worflow until you get it done.

Originally posted by @eine in #98 (comment)

Conflicts with pytest and WSL

Recently, GitHub added WSL to the virtual environment used in GitHub Actions (actions/runner-images#1081). As a result, C:\Windows\System32\bash.exe is created. This is NOT an issue for users of setup-msys2 with the default path-type or with strict. However, it might be conflictive for users of mode inherit.

Moreover, in Python, when pytest is used along with check_call(['bash',...]), it is resolved to C:\Windows\System32\bash.exe and it fails if the user has not explicitly configured WSL before. A workaround is to use which from shutil. See actions/runner-images#1081 (comment).

Curiously, the problem is found in MINGW terminals only, not in MSYS. See https://github.com/msys2/setup-msys2/runs/892341986. I think it is because https://github.com/msys2/setup-msys2/runs/892341986?check_suite_focus=true#step:6:7 and https://github.com/msys2/setup-msys2/runs/892341966?check_suite_focus=true#step:6:7 (platform msys vs win32).

/cc @The-Compiler

Setting shell default for Windows hosts in cross-platform matrix

So, I'm kind of banging my head against a wall with something, and I wanted to see if anyone has any clever solutions.

I have a project which builds in CMake, and the cmake commands are actually all the same whether running on Linux, macOS, or Windows. I've worked very hard to keep things that way, in fact, so that the build tooling could be as platform-agnostic as possible.

So, I have a workflow written with build steps that are largely shared between all platforms in the matrix. (Each OS has its own dependency step, gated with an if: ${{ runner.os == 'Linux' }} (or 'Windows' or 'macos'), but that's the only non-shared config.)

To differentiate the -G argument to cmake, which selects the generator to use for the build system, I'm using action-cond from @haya14busa which works great:

     - name: Select CMake generator
        uses: haya14busa/action-cond@v1
        id: generator
        with:
          cond: ${{ runner.os == 'Windows' }}
          if_true: 'MinGW Makefiles'
          if_false: 'Unix Makefiles'
      - name: Build
        run: |
          cmake -B build -S . -G "${{ steps.generator.outputs.value }}" ...

The problem is, I can't think of any way to do the same thing for the MSYS2 shell. If I wanted to take advantage of the "Default shell" option from the README, I'd end up setting it as the default for every shell, including the ones that run on Linux and macOS, which obviously won't work! I've tried 100 different ways to conditionalize the setting, and they all failed:

  1. Add an if: to the defaults: section of the config: Syntax error
  2. Add another haya14busa/action-cond@v1 step that sets either msys2 {0} or bash, and use shell: ${{ steps.select_shell.outputs.value }} in subsequent steps: Syntax error, apparently the steps object is not accessible from the metaconfiguration of subsequent steps.
  3. Capture the output into an environment variable, the same way I can with CC: ${{ matrix.compiler }}:
    env:
      RUNSHELL: ${{ steps.select_shell.outputs.value }}
    steps:
       - name: Select shell...
         id: select_shell
         with:
          cond: ${{ runner.os == 'Windows' }}
          if_true: 'msys2 -c'
          if_false: 'bash -c'
         ...
      - name: Build
        run: |
          $RUNSHELL 'cmake...'
    (In my defense, I never expected that one to work, and it doesn't. Same issue with accessing steps before it's defined.)
  4. The same thing, but set the env in every step that needs it:
    steps:
       - name: Select shell...
         id: select_shell
         with:
          cond: ${{ runner.os == 'Windows' }}
          if_true: 'msys2 -c'
          if_false: 'bash -c'
         ...
      - name: Build
        env:
          RUNSHELL: ${{ steps.select_shell.outputs.value }}
        run: |
          $RUNSHELL 'cmake...'
    That actually came close to working, believe it or not! Actually worked on Linux and macOS. Blew up in the default Powershell on Windows, though.
  5. Set up a completely separate job config before the build job, with the same matrix, and have it relay the results of action-cond into an outputs. Have the second job needs: the first, and set shell: ${{ needs.job1.outputs.shell }} on each step: Syntax error, it seems the needs context isn't any more accessible for defining steps than the steps context is.

At this point I feel like I've exhausted all possibilities. Any suggestions, or do I really have to take my nice, cross-platform workflows and duplicate all of the run steps, just so I can get Windows to run them using the correct shell? 😞

How to find mingw64 redistributable dlls?

How do I find mingw64 redistributable dlls? What environment variable refers to the mingw64 path?

libgcc_s_seh-1.dll
libgomp-1.dll
libstdc++-6.dll
libwinpthread-1.dll

Install section throws error cmd.exe failed with exit code 1

Hi,

I'm trying to setup actions to build app for windows with mingw and qt.

So tried to use this repo and got such error it's hard to say what is origin at least for me.

It is in install section

 install: >-
          mingw-w64-x86_64-toolchain
          base-devel
          git
          p7zip
          ruby 
          mingw-w64-x86_64-qt5
          mingw-w64-i686-qt5
          mingw-w64-i686-toolchain
          mingw-w64-i686-qwt-qt5
          mingw-w64-x86_64-zlib
          mingw-w64-i686-zlib
          zlib-devel
          mingw-w64-x86_64-openssl
          mingw-w64-i686-openssl
          openssl-devel
 C:\windows\system32\cmd.exe /D /S /C D:\a\_temp\msys\msys2.cmd -c "'pacman' '--noconfirm' '-S' '--needed' '--overwrite' '*' 'mingw-w64-x86_64-toolchain' 'base-devel' 'git' 'p7zip' 'ruby' '' 'mingw-w64-x86_64-qt5' 'mingw-w64-i686-qt5' 'mingw-w64-i686-toolchain' 'mingw-w64-i686-qwt-qt5' 'mingw-w64-x86_64-zlib' 'mingw-w64-i686-zlib' 'zlib-devel' 'mingw-w64-x86_64-openssl' 'mingw-w64-i686-openssl' 'openssl-devel'"
  :: There are 19 members in group mingw-w64-x86_64-toolchain:
  :: Repository mingw64
     1) mingw-w64-x86_64-binutils  2) mingw-w64-x86_64-crt-git  3) mingw-w64-x86_64-gcc  4) mingw-w64-x86_64-gcc-ada  5) mingw-w64-x86_64-gcc-fortran  6) mingw-w64-x86_64-gcc-libgfortran  7) mingw-w64-x86_64-gcc-libs  8) mingw-w64-x86_64-gcc-objc  9) mingw-w64-x86_64-gdb  10) mingw-w64-x86_64-gdb-multiarch  11) mingw-w64-x86_64-headers-git  12) mingw-w64-x86_64-libgccjit  13) mingw-w64-x86_64-libmangle-git  14) mingw-w64-x86_64-libwinpthread-git  15) mingw-w64-x86_64-make  16) mingw-w64-x86_64-pkgconf  17) mingw-w64-x86_64-tools-git  18) mingw-w64-x86_64-winpthreads-git  19) mingw-w64-x86_64-winstorecompat-git
  
  Enter a selection (default=all): warning: file-5.39-2 is up to date -- skipping
  warning: gawk-5.1.0-1 is up to date -- skipping
  warning: gettext-0.19.8.1-1 is up to date -- skipping
  warning: grep-3.0-2 is up to date -- skipping
  warning: pacman-5.2.2-9 is up to date -- skipping
  warning: perl-5.32.0-2 is up to date -- skipping
  warning: sed-4.8-1 is up to date -- skipping
  warning: 
  :: There are 48 members in group base-devel:
  wget-1.20.3-1 is up to date -- skipping
  :: Repository msys
     1) asciidoc  2) autoconf  3) autoconf2.13  4) autogen  5) automake-wrapper  6) automake1.10  7) automake1.11  8) automake1.12  9) automake1.13  10) automake1.14  11) automake1.15  12) automake1.16  13) automake1.6  14) automake1.7  15) automake1.8  16) automake1.9  17) bison  18) btyacc  19) diffstat  20) diffutils  21) dos2unix  22) flex  23) gdb  24) gettext-devel  25) gperf  26) groff  27) help2man  28) intltool  29) libtool  30) libunrar  31) libunrar-devel  32) m4  33) make  34) man-db  35) pactoys-git  36) patch  37) patchutils  38) pkgconf  39) pkgfile  40) quilt  41) reflex  42) scons  43) swig  44) texinfo  45) texinfo-tex  46) ttyrec  47) unrar  48) xmlto
  
  Enter a selection (default=all): error: target not found: 
  
  Error: The process 'C:\windows\system32\cmd.exe' failed with exit code 1

Github Action CVE-2020-15228 error message spotted

Currently when installing MSYS2 on the windows-latest box, the following error message pops up:

"Warning: The add-path command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/"

I have had to go through my other jobs updating how environment variables and paths are set. As this is a very new error message, I've raised an issue here so you're aware. πŸ‘

Using MSVC compiler with msys

I've been having trouble configuring my windows build to use the Visual Studio compiler (cl) in an msys shell. I've tried a variety of configurations and PATH manipulations, but nothing seems to work. Example workflow:

- name: Run batch file and set path
  run: | 
    C:\"Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Auxiliary\Build\vcvars64.bat"
    echo "/c/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.28.29910/bin" | Out-File -FilePath $env:GITHUB_PATH -Encoding utf8 -Append
    which cl # returns the correct path
- uses: msys2/setup-msys2@v2
  with:
    update: true
    install: >-
      base-devel
      git
    path-type: inherit
- name: Build project
  run: |
    ./coinbrew/coinbrew build my-repo
  shell: msys2 {0}

Running this workflow errors because it can't find the compiler:

checking for icl... no
checking for cl... no
configure: error: Neither MS nor Intel C compiler found in PATH and CC is unset.
Error: Process completed with exit code 1.

I've confirmed that the PATH is being preserved with the inherit parameter, but for some reason my program can't seem to find the compiler. This configuration work fine on AppVeyor.

Add to path without inherit?

I'd like to add a few directories to the path, but still keep minimal or strict path-type so I don't get confused by tools from other sources.

Ideally, it would just detect the existing ::add-path::/foo entries that are also seen by bash on linux/mac, so I only need to add it in one place, but an extra add-path: '/foo:~/bar' or similar option to the setup-msys2 action would probably also work for my current uses (though possibly would require hard-coding some paths unless I can get access to env vars there for $HOME or similar).

Could you please clarify documentation:

Your documentation at https://github.com/marketplace/actions/setup-msys2 reads:

MSYS2 is available by default in windows-latest virtual environment for GitHub Actions. However, the default installation is updated every ~10 days, and it includes some pre-installed packages. As a result, startup time can be up to 10 min. Moreover, MSYS2/MINGW are neither added to the PATH nor available as a custom shell option.

From this, I understand that your github action "Setup MSYS2" is mainly for people who

  • require their msys2 packages to be always up-to-date, i.e. a 10 days old msys package is too old for them.
  • actually experience this 10 minute startup time
  • do not want to add a custom default shell like the following to their .yml file:
    defaults:
      run:
        shell: bash.exe --login -eo pipefail "{0}"

At least this is what I understood and concluded that the Setup MSYS2 action is not for me, because the default msys2 installation seems to work fine so far. Can you confirm this understanding and maybe clarify your documentation?

Thank you!

"command not found" when trying to call CMake or GCC after installing them

Hi.

Consider following all steps available at the official MSYS2 web site. After finishing them, install the CMake and GCC (I have been trying the i686 option):

$ pacman -S mingw-w64-i686-cmake mingw-w64-i686-gcc

Now, try to use CMake:

$ cmake
bash: cmake: command not found

or GCC:

$ gcc
bash: gcc: command not found

These commands worked in previous versions of MSYS, so I'm not sure if it is a bug in MSYS of something wrong I'm doing. πŸ˜•

TIA for any help!

Multiline value for `install` parameter.

It would be nice to specify install with multi-line value, like this:

  - uses: msys2/setup-msys2@v2
      install: |
        mingw64/mingw-w64-x86_64-gtk3
        mingw64/mingw-w64-x86_64-gprbuild
        mingw64/mingw-w64-x86_64-gcc-ada
        mingw64/mingw-w64-x86_64-pkg-config
        msys/make

But in this case I get error:

  C:\windows\system32\cmd.exe /D /S /C D:\a\_temp\msys\msys2.cmd -c "'pacman' '--noconfirm' '-S' '--needed' '--overwrite' '*' 'mingw64/mingw-w64-x86_64-gtk3
  mingw64/mingw-w64-x86_64-gprbuild
  mingw64/mingw-w64-x86_64-gcc-ada
  mingw64/mingw-w64-x86_64-pkg-config
  msys/make'"
  /usr/bin/bash: -c: line 0: unexpected EOF while looking for matching `''

MSYS2 / Build faild on libs not found when using "eine/setup-msys2@v1" action

The link below is the workflow we tested with "eine/setup-msys2@v1" action.
https://github.com/ForksForTest/haven-offshore/actions/runs/131995709/workflow

After using the "eine/setup-msys2@v1" action to install some specified packages, in the "build Haven for windows x64" step, we always get the errors like as below from the logs:

-- Building internal libraries as static
-- MSYS location: D:/a
-- Could not find DATABASE in env (not required unless you want to change database type from default: lmdb)
-- Using LMDB as default DB type
-- looking for liblzma
-- Could not find libunwind (missing: LIBUNWIND_INCLUDE_DIR LIBUNWIND_LIBRARIES) 
-- Stack trace on exception disabled
CMake Error at D:/a/_temp/msys/msys64/mingw64/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164 (message):
  Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the
  system variable OPENSSL_ROOT_DIR (missing: OPENSSL_CRYPTO_LIBRARY
  OPENSSL_INCLUDE_DIR)
Call Stack (most recent call first):
-- Configuring incomplete, errors occurred!
See also "D:/a/haven-offshore/haven-offshore/monero/build/release/CMakeFiles/CMakeOutput.log".
  D:/a/_temp/msys/msys64/mingw64/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:445 (_FPHSA_FAILURE_MESSAGE)
  D:/a/_temp/msys/msys64/mingw64/share/cmake-3.17/Modules/FindOpenSSL.cmake:459 (find_package_handle_standard_args)
  CMakeLists.txt:465 (find_package)


make: *** [Makefile:151: release-static-win64] Error 1

But, when we switch to use "eine/setup-msys2@v0" action, everything is OK, see the link below.
https://github.com/ForksForTest/haven-offshore/actions/runs/131996395/workflow

You can see we did not changes anything except the version ref of the setup-msys2 action.
and I found that, when executing "eine/setup-msys2@v1", it only took less than 3 minutes, but "eine/setup-msys2@v0" took about 10 minutes with the settings.

I think there may be some issue on "eine/setup-msys2@v1" that cause some packages were not installed. This also can explain why it took a shot time to execute.

error: GPGME error: No data error: database 'msys' is not valid (invalid or corrupted database (PGP signature))

setup-msys2 has stopped working for me. It worked yesterday. The error is here: https://github.com/pcb2gcode/pcb2gcode/runs/1819274591?check_suite_focus=true

Final system upgrade...
  C:\windows\system32\cmd.exe /D /S /C D:\a\_temp\msys\msys2.cmd -c "'pacman' '--noconfirm' '-Suu' '--overwrite' '*'"
  error: GPGME error: No data
  error: GPGME error: No data
  error: GPGME error: No data
  error: database 'mingw32' is not valid (invalid or corrupted database (PGP signature))
  error: database 'mingw64' is not valid (invalid or corrupted database (PGP signature))
  error: database 'msys' is not valid (invalid or corrupted database (PGP signature))
  Error: The process 'C:\windows\system32\cmd.exe' failed with exit code 1
  ##[debug]Node Action run completed with exit code 1
  ##[debug]MSYSTEM='MINGW64'
  ##[debug]Finishing: Setup msys2

Support MSYSTEM=UCRT64

This is a request to support UCRT64 packages.

Currently, setting msystem to UCRT64 gives:

Error: 'msystem' needs to be one of MSYS, MINGW32, MINGW64, got UCRT64

strange .dll not found problem

Hi,

I'm using msys2/setup-msys2 action to set up msys2 shell on my CI build. Recently I started having a strange problem when one of the test apps which tests the library being built on the CI is unable to load the library .dll.

I asked about what could be the possible problem here: msys2/MINGW-packages#8370
But it looks like they have no idea.

Since the problem only occurs on the CI machine (locally all works fine), I thought that there might be some difference in how the environment is configured by the msys2/setup-msys2 action, so, posting the problem here.

Here goes the copy of the problem description from the link above.

===================================================

Hi,

I have a strange problem of a DLL being not found. I'm posting the issue here as I don't have any ideas of what else I can try to fix it.

I have an open source library project svgdom which I build for windows in msys2 environment.
I have github actions based CI configured in the github repo. The CI process first builds the library, producing the DLL, then it builds and runs test applications. To run a test application I have to copy the library DLL to the same directory as the test app's executable to make the test app load and link to the dll when it is run.

One can see the failed CI run here: for mingw64 and for mingw32

The strange thing is that it fails in the CI build, but on my local machine all passes successfully.

From the build log we can see that all test apps worked successfully except the one called tst.

The error when trying to run the tst app is as follows:
For mingw64:

D:/a/svgdom/svgdom/tests/tst/out/rel/tests.exe: error while loading shared libraries: libsvgdom.dll: cannot open shared object file: No such file or directory

For mingw32:

D:/a/svgdom/svgdom/tests/tst/out/rel/tests.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory

The libsvgdom.dll file is there right next to tests.exe, that is 100% sure. I have checked that explicitly listing the dir contents on CI machine.

The only difference of the tst application from other test apps (which pass) I can think of is that the main() function in the tst app is provided by another DLL (libtst), not by the main executable. But again, all works fine on my local machine. And, similar tests are working fine for the libtst itself.

And I'll repeat again, the build (and those tests of course) passes successfully on my local machine in msys2 environment.

Any idea of what else can I try?

Thanks in advance!

Using environment based paths with msys2

In our github action we are using environment variables pointing to the location of a cloned directory, for example

    env:
      ACE_ROOT: ${{ github.workspace }}/ACE

When we now later use msys2 cp it fails because the path is now D:aACE_TAOACE_TAO/ACE because the env is a windows path.

Would be nice if there is a way to indicate which environment variables should be converted to msys2 paths in some ways when using the msys2 shell

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.