The installation script should use absolute paths for `ln`

[XhstormR]

When building on Windows, and executing the linked mutilcall program, because the generated ln.exe has higher priority than the default /usr/bin/ln.exe, it won't add the .exe suffix by default. Therefore, executing ln -f coreutils ls will result in an error, indicating that coreutils cannot be found. However, if you use ln -f coreutils.exe ls.exe, it will work.

Therefore, when linking, we need to use the absolute path of the ln file to prevent using the ln file that was just generated.

cd /d/bld/uutils-coreutils_1762957332295/_h_env/bin && ln -f coreutils df 
cd /d/bld/uutils-coreutils_1762957332295/_h_env/bin && ln -f coreutils dir 
cd /d/bld/uutils-coreutils_1762957332295/_h_env/bin && ln -f coreutils dircolors 
cd /d/bld/uutils-coreutils_1762957332295/_h_env/bin && ln -f coreutils dirname 
cd /d/bld/uutils-coreutils_1762957332295/_h_env/bin && ln -f coreutils du 
cd /d/bld/uutils-coreutils_1762957332295/_h_env/bin && ln -f coreutils echo 
cd /d/bld/uutils-coreutils_1762957332295/_h_env/bin && ln -f coreutils env 
cd /d/bld/uutils-coreutils_1762957332295/_h_env/bin && ln -f coreutils expand 
cd /d/bld/uutils-coreutils_1762957332295/_h_env/bin && ln -f coreutils expr 
cd /d/bld/uutils-coreutils_1762957332295/_h_env/bin && ln -f coreutils factor 
cd /d/bld/uutils-coreutils_1762957332295/_h_env/bin && ln -f coreutils false 
cd /d/bld/uutils-coreutils_1762957332295/_h_env/bin && ln -f coreutils fmt 
cd /d/bld/uutils-coreutils_1762957332295/_h_env/bin && ln -f coreutils fold 
cd /d/bld/uutils-coreutils_1762957332295/_h_env/bin && ln -f coreutils hashsum 
cd /d/bld/uutils-coreutils_1762957332295/_h_env/bin && ln -f coreutils head 
cd /d/bld/uutils-coreutils_1762957332295/_h_env/bin && ln -f coreutils hostname 
cd /d/bld/uutils-coreutils_1762957332295/_h_env/bin && ln -f coreutils join 
cd /d/bld/uutils-coreutils_1762957332295/_h_env/bin && ln -f coreutils link 
cd /d/bld/uutils-coreutils_1762957332295/_h_env/bin && ln -f coreutils ln 
cd /d/bld/uutils-coreutils_1762957332295/_h_env/bin && ln -f coreutils ls 
ln.exe: failed to create hard link 'coreutils' => 'ls': No such file or directory
make: *** [GNUmakefile:477: install] Error 1

(%BUILD_PREFIX%) %SRC_DIR%>echo Failed with error #2. 
Failed with error #2.

[oech3]

????? https://packages.msys2.org/packages/mingw-w64-ucrt-x86_64-uutils-coreutils cc @ognevny

[ognevny]

what's wrong? I don't understand your question

[oech3]

the generated ln.exe has higher priority than the default /usr/bin/ln.exe

GNUmakefile does not have such logic.

[oech3]

mingw package is fine because MSYS2 is using patched system coreutils to append .exe. But uutils ls does not. Right?

[ognevny]

mingw package is fine because MSYS2 is using patched system coreutils to append .exe. But uutils ls does not. Right?

wdym? in msys2 there is only one ln - from GNU coreutils: https://packages.msys2.org/package/coreutils?repo=msys&variant=x86_64. even if uutils version is installed, uu-ln will be available, but not ln

[oech3]

https://packages.msys2.org/packages/mingw-w64-ucrt-x86_64-uutils-coreutils has .exe because you used GNU ln which has ability to append .exe ?

[oech3]

Oh I see. @XhstormR is trying to install uutils ls to ~~/.cargo/bin which is part of~ PATH by make install. It is not problem for packager.

And... uutils/coreutils would not support cygwin specific behavior... Even we move ln to bottom of PROGS of GNUmakefile, 2nd install operation cause this bug again.

/usr/bin/ls is not a solution for people installed uutils ln to there.

[XhstormR]

The problem here is that we're using two different types of ln: one that comes with the environment, and the other generated by the ln linker we just created, since we are cd to the bin dir.

cd /d/bld/uutils-coreutils_1762957332295/_h_env/bin && ln -f coreutils ln 
cd /d/bld/uutils-coreutils_1762957332295/_h_env/bin && ln -f coreutils ls 
ln.exe: failed to create hard link 'coreutils' => 'ls': No such file or directory

[oech3]

Workaround: make LN="/path/to/yourln". I think this project should not fix this issue (until cygwin/mingw target was supported by uutils officially).

[oech3]

Do you want to fix make uninstall using rm too? https://github.com/uutils/coreutils/blob/73d1bce20d060d636b06e2aba024eb8088ca3e6c/GNUmakefile#L480-L491

[XhstormR]

@oech3 I'm not sure, since we are not change working dir in uninstall rules, it's up to you.

[oech3]

I guess we can close this issue now as cygwin build was uploaded to MSYS

[XhstormR]

Now, I am using a workaround like for /f "usebackq delims=" %%A in (``where ln``) do set "LN=%%A", not a real fix.

https://github.com/conda-forge/uutils-coreutils-feedstock/blob/1c92c35b0af6275f7f5fdabc0b8c274b6ae401e2/recipe/build.bat#L6

[oech3]

I don't want to solve this issue via system ln.exe and install.exe because 2nd make install would use uutils/ln at PATH cause the issue again.