on Github Actions windows msys2, configure cannot find icu

Question

In a Github Action on windows-latest , I call a script using the following command:

C:\msys64\msys2_shell.cmd -mingw64 -defterm -here -full-path -no-start -shell bash scripts/cibw_before_all_windows.sh

I don't understand what all of the flags mean, so it may be that one of the flags is wrong. The cibw_before_all_windows.sh script is the following:

pacman -S --noconfirm --needed  \
           bison  \
           flex  \
           icu-devel  \
           swig

export CPPFLAGS="-I/c/msys2/usr/include ${CPPFLAGS}"
export LDFLAGS="-L/c/msys2/usr/lib ${LDFLAGS}"
export PATH="/c/msys2/usr/bin/:${PATH}"
export PKG_CONFIG_PATH="/c/msys2/usr/lib/pkgconfig:${PKG_CONFIG_PATH}"


cd hfst_src/
autoreconf -fvi
./configure --with-unicode-handler=icu
make
make check V=1 VERBOSE=1
make install
cd ..

python setup.py build_ext

The script fails on ./configure --with-unicode-handler=icu , with the following output:

...
  checking for ld used by g++... C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe
  checking if the linker (C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) is GNU ld... yes
  checking whether the g++ linker (C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) supports shared libraries... yes
  checking for g++ option to produce PIC... -DDLL_EXPORT -DPIC
  checking if g++ PIC flag -DDLL_EXPORT -DPIC works... yes
  checking if g++ static flag -static works... yes
  checking if g++ supports -c -o file.o... yes
  checking if g++ supports -c -o file.o... (cached) yes
  checking whether the g++ linker (C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) supports shared libraries... yes
  checking dynamic linker characteristics... Win32 ld.exe
  checking how to hardcode library paths into programs... immediate
  checking for gawk... (cached) gawk
  checking how to run the C preprocessor... gcc -E
  checking for bison... bison -y
  checking for flex... flex
  checking for lex output file root... lex.yy
  checking for lex library... none needed
  checking for library containing yywrap... no
  checking whether yytext is a pointer... yes
  checking for getopts... false
  checking for a Python interpreter with version >= 3.0... python
  checking for python... /mingw64/bin/python
  checking for python version... 3.8
  checking for python platform... win32
  checking for python script directory... ${prefix}/lib/python3.8/site-packages
  checking for python extension module directory... ${exec_prefix}/lib/python3.8/site-packages
  configure: WARNING: Building hfst successfully requires flex newer than 2.5.33 on some platforms. Unless you are building with pre-flex-generated sources, building will probably fail.
  checking whether ln -s works... no, using cp -pR
  checking whether make sets $(MAKE)... (cached) yes
  checking for doxygen... no
  checking for main in -ldl... no
  checking for main in -lpthread... yes
  checking for main in -lm... yes
  checking for ncurses.h... no
  checking for curses.h... no
  checking for termcap.h... yes
  checking for tgetent in -ltermcap... yes
  checking for icu-config... /usr/bin/icu-config
  checking for pkg-config... /mingw64/bin/pkg-config
  ### icu-config: Can't find /usr/lib/msys-icuuc68.dll - ICU prefix is wrong.
  ###      Try the --prefix= option 
  ###      or --detect-prefix
  ###      (If you want to disable this check, use  the --noverify option)
  ### icu-config: Exitting.
  expr: syntax error: unexpected argument '50'
  configure: error: in `/d/a/hfst-python/hfst-python/hfst_src':
  configure: error: --with-unicode-handler=icu requested but icu>=50 not found
  See `config.log' for more details
  Error: Command C:\msys64\msys2_shell.cmd -mingw64 -defterm -here -full-path -no-start -shell bash scripts/cibw_before_all_windows.sh failed with code 1. None

From the output, it appears that configure cannot find my fresh install of flex , bison , and icu . How can get configure to see the installations from pacman ? Is there a better way to approach the problem in general?

EDITS

The versions installed by pacman are...

bison-3.7.4-1
flex-2.6.4-1
icu-devel-68.2-1
swig-4.0.2-1

The reason I say that it does not see my flex and bison is that it complains that configure: WARNING: Building hfst successfully requires flex newer than 2.5.33 on some platforms. Unless you are building with pre-flex-generated sources, building will probably fail. configure: WARNING: Building hfst successfully requires flex newer than 2.5.33 on some platforms. Unless you are building with pre-flex-generated sources, building will probably fail. . Since the flex version from pacman is flex-2.6.4-1 , I'm assuming that configure found a different version somewhere else on the system. This makes me suspect that it's also not finding the pacman version of any other dependencies.

Answer 1

Add the location where pacman installed the .pc files for those packages to environment variable PKG_CONFIG_PATH .

Answer 2

From the output, it appears that configure cannot find my fresh install of flex, bison, and icu.

No, that does not look like the problem at all. The configure output shows that it sees Flex, and Bison, and ICU:

 checking for bison... bison -y checking for flex... flex

[...]

 checking for icu-config... /usr/bin/icu-config

The diagnostic output consists of messages from both icu-config and configure :

 ### icu-config: Can't find /usr/lib/msys-icuuc68.dll - ICU prefix is wrong. ### Try the --prefix= option ### or --detect-prefix ### (If you want to disable this check, use the --noverify option) ### icu-config: Exitting. expr: syntax error: unexpected argument '50' configure: error: in `/d/a/hfst-python/hfst-python/hfst_src': configure: error: --with-unicode-handler=icu requested but icu>=50 not found See `config.log' for more details

The key issue appears to be that your ICU installation is broken, which would be a question of the (pacman) package by which you've installed it. The icu-config program should belong to that package, and if it does not find or does not recognize other package components then either it is flat broken or it is mismatched with the rest of the package. It would be worth verifying against an msys2 installation more directly under your control, but supposing that you can do so, this should be raised as a packaging bug. I guess that would go to the msys2 project.

The diagnostics from configure look like follow-on consequence of the icu-config failure, probably not an issue in their own right.

How can get configure to see the installations from pacman?

It sees them. They're just broken (the icu-devel package is, at any rate).

Is there a better way to approach the problem in general?

I think your approach is generally fine. I do recommend that you test on a local msys2 installation before setting it up as a GitHub action. One possible workaround to the issue you are presently facing would be to ask pacman for a specific, known good version of each package, instead of letting it choose the most recent available. Inasmuch as doing so would make your builds more reproducible, you might consider that an improvement to your approach.

Alternatively, the icu-config output suggests some other possibilities, especially adding the --detect-prefix option or the --noverify option to the icu-config command line. That would be done in configure , and if it in fact solves the problem then it would probably be quicker than waiting for an issue to be resolved through msys2's process (nothing against msys2; it's just that these things take time).