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?

coreutils/GNUmakefile

Lines 480 to 491 in 73d1bce

	rm -f $(DESTDIR)$(LIBSTDBUF_DIR)/libstdbuf*
	-rm -d $(DESTDIR)$(LIBSTDBUF_DIR) 2>/dev/null || true
	endif
	ifeq (${MULTICALL}, y)
	rm -f $(addprefix $(INSTALLDIR_BIN)/,$(PROG_PREFIX)coreutils)
	endif
	rm -f $(addprefix $(INSTALLDIR_BIN)/$(PROG_PREFIX),$(PROGS))
	rm -f $(INSTALLDIR_BIN)/$(PROG_PREFIX)[
	rm -f $(addprefix $(DESTDIR)$(DATAROOTDIR)/zsh/site-functions/_$(PROG_PREFIX),$(PROGS))
	rm -f $(addprefix $(DESTDIR)$(DATAROOTDIR)/bash-completion/completions/$(PROG_PREFIX),$(PROGS).bash)
	rm -f $(addprefix $(DESTDIR)$(DATAROOTDIR)/fish/vendor_completions.d/$(PROG_PREFIX),$(addsuffix .fish,$(PROGS)))
	rm -f $(addprefix $(DESTDIR)$(DATAROOTDIR)/man/man1/$(PROG_PREFIX),$(addsuffix .1,$(PROGS)))

[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