Open HazardyKnusperkeks opened 1 year ago
Try uninstalling mingw-w64-sed so the msys version is used.
Yeah that works for that. But shouldn't the UCRT variant also work?
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.
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?
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.
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.
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.
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
.
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.
Description
I have sed from the msys package, as wall as the UCRT64:
When invoking
makepkg-mingw
formingw64-arm-none-eabi-gdb
I get the same error I had on #14082. I investigated a bit and the linesed -i "/ac_cpp=/s/\$CPPFLAGS/\$CPPFLAGS -O2/" libiberty/configure
from thePKGBUILD
turns into the invocationC:\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
toC:/msys64/
.Verification
Windows Version
Microsoft Windows [Version 10.0.19043.2130]
MINGW environments affected
Expected behavior
The sed call is not altered.
Actual behavior
The sed call is altered.
Repro steps
makepkg-mingw
forgcc
orarm-none-abi-gdb
(and possibly others too?) for UCRT64Are you willing to submit a PR?
If I get a hint where to look at, yes.