sed in makepkg-mingw wrongly invoked

[HazardyKnusperkeks]

Description

I have sed from the msys package, as wall as the UCRT64:

$ pacboy -Ss sed$
mingw32/mingw-w64-i686-sed 4.8-2
    Sed is a stream editor (mingw-w64)
mingw64/mingw-w64-x86_64-sed 4.8-2
    Sed is a stream editor (mingw-w64)
ucrt64/mingw-w64-ucrt-x86_64-sed 4.8-2 [Installiert]
    Sed is a stream editor (mingw-w64)
clang64/mingw-w64-clang-x86_64-sed 4.8-2
    Sed is a stream editor (mingw-w64)
msys/sed 4.9-1 [Installiert]
    GNU stream editor

When invoking makepkg-mingw for mingw64-arm-none-eabi-gdb I get the same error I had on #14082. I investigated a bit and the line sed -i "/ac_cpp=/s/\$CPPFLAGS/\$CPPFLAGS -O2/" libiberty/configure from the PKGBUILD turns into the invocation C:\msys64\ucrt64\bin\sed.exe -i "C:/msys64/ac_cpp=/s/$CPPFLAGS/$CPPFLAGS -O2/" libiberty/configure. I've observed that with the process monitor.

When I change the line to use /usr/bin/sed I observe: C:\msys64\usr\bin\sed.exe -i "/ac_cpp=/s/$CPPFLAGS/$CPPFLAGS -O2/" libiberty/configure.

So it seems someone (who?) changes the / from /ac_cpp to C:/msys64/.

Verification

• [X] I have verified that my MSYS2 is up-to-date before submitting the report (see https://www.msys2.org/docs/updating/)

Windows Version

Microsoft Windows [Version 10.0.19043.2130]

MINGW environments affected

• [ ] MINGW64
• [ ] MINGW32
• [X] UCRT64
• [ ] CLANG64
• [ ] CLANG32
• [ ] CLANGARM64

Expected behavior

The sed call is not altered.

Actual behavior

The sed call is altered.

Repro steps

1. Install sed:u
2. run makepkg-mingw for gcc or arm-none-abi-gdb (and possibly others too?) for UCRT64

Are you willing to submit a PR?

If I get a hint where to look at, yes.

[lazka]

Try uninstalling mingw-w64-sed so the msys version is used.

[HazardyKnusperkeks]

Yeah that works for that. But shouldn't the UCRT variant also work?

[revelator]

depends on what you intend to do, the mingw sed outputs windows paths exclusively which confuses things like autotools as they are geared towards posix paths (one of the main reasons why we use posix shell tools actually). some handcrafted makefile projects might prefer the mingw based sed but as a good deal of packages are ports of posix programs / libraries the use of it will probably be limited.

[cyrilarnould]

I ran into similar issues having the ucrt64 and mingw64 versions of grep installed. Ironically, the grep build fails because of this. I suppose it is a difficult task to address these issues, but in the meantime maybe it should be mentioned in the msys2.org documentation that these two packages should be uninstalled prior to building?

[revelator]

aye the packages that will probably break things are these mingw-w64-grep mingw-w64-sed mingw-w64-diffutils mingw-w64-file mingw-w64-bison and mingw-w64-m4 seem to work so probably safe to use, the others are situational and should only be used when requested by a package script.

[revelator]

on a sidenote mingw-w64-perl will atleast to my knowledge break building mingw-w64-openssl but the fix is atleast easy as openssl uses a perl configure script you can simply put /usr/bin/perl before the configure command and it will build with no problem again.

[revelator]

another addition is dlfcn-win32, it breaks glib2's module handler even though it is not listed as a dependency glib2 will still link to it if found. Probably also breaks a lot of other packages that will prefer the dlopen mechanism over the windows loadlibrary ones.

[cyrilarnould]

One easy way to improve upon this would be to modify the makepkg-mingw wrapper to print warnings if certain mingw-w64 packages are installed.

One problem with this would be that the warning gets generated even if the package in question is an explicit make dependency. Currently I haven't found any PKGBUILDs in the MINGW-packages repo that depend on mingw-w64-sed or mingw-w64-grep though.

mingw-w64-julia makedepends on mingw-w64-diffutils, while mingw-w64-tiledb depends on mingw-w64-file. Quite a few packages have dependencies on mingw-w64-perl or mingw-w64-dlfcn.

EDIT: another approach would be to rename the sed and grep executables to mingw32-sed and mingw32-grep, similar to how the mingw-w64-make executable is called mingw32-make.

[revelator]

for dlfcn-win32 a small change to the layout might be handy, instead of installing the headers in /mingw/include we could install them in /mingw/include/dlfcn-win32 then adjust the pkgconfig to point to that location. the downside is when a project who depends on it (which are most since on unix dlfcn.h is a system header and pkgconfig is newer used to find it) we would have to CFLAGS+=" -I$MINGW_PREFIX/include/dlfcn-win32" but it does work, it just takes a little more work.