Hi Corinna, Perhaps you are willing to shed some light here (otherwise I am forced to embark on a (really) long journey w/ gdb) ...
As I wrote in - https://cygwin.com/pipermail/cygwin/2026-January/259234.html "I have Cygwin (using setup.exe) installed in e:/Cygwin and in e:/Cygwin2; there is no difference between the two instances, except for the topdir." After mounting e:/Cygwin2 in Cygwin, a cygwin-exe (like getfacl.exe) from e:/Cygwin2 cannot be invoked "in place" (retval = 127), like /top/usr/bin/getfacl.exe --version /etc/fstab: - e:/Cygwin2 mounted on /top - e:/Cygwin2{bin,etc,lib} mounted on /top/{bin,etc,lib) However, the curious thing is, that a mingw-exe (like strace.exe) can be invoked "in place" ... (of course, the same applies if e:/Cygwin is mounted in Cygwin2) Long ago (1.7.25, August 2013) [a], you made it possible to invoke an 32-bit executable belonging to an 32-bits instance of Cygwin, FROM an 64-bits instance of Cygwin ... (yes, I know, 32 bits support has gone since 2022 (3.4) ). As I remembered that being possible - yes, I agree, it was 10 years ago, I thought it somewhat peculiar that the above failed now. --- I have also several instances of Cygwin (cygwin1.dll) BUILT here ... One of them, in /drv/e/rel3.7-test (yes, /drv is substituted for /cygdrive in /etc/fstab) 3.7 ...? i.e., the test-release from 2025-12-10 ... built using cygport (prep, compile, install) configure switches: --without-mingw-progs, --disable-doc, --disable-dumper (but not the utils! and cygserver) cygport installed (last phase) here: /drv/e/rel3.7-test/cygwin-3.7.0-0.332.g43ddce194c49.x86_64/inst (Yes, the path is no joke of mine; I copying it here from what I see on my laptop. Sigh.) ldd /drv/e/rel3.7-test/cygwin-3.7.0-0.332.g43ddce194c49.x86_64/\ inst/bin/getfacl ntdll.dll => /drv/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffa060e0000) KERNEL32.DLL => /drv/c/WINDOWS/System32/KERNEL32.DLL (0x7ffa04610000) KERNELBASE.dll => /drv/c/WINDOWS/System32/KERNELBASE.dll (0x7ffa033d0000) cygwin1.dll => /drv/e/rel3.7-test/cygwin-3.7.0-0.332.g43ddce194c49.x86_64/inst/bin/cygwin1.dll (0x7ff9df1c0000) Now, How can I verify that getfacl is working, USING the cugwin1.dll from above, i.e. verify getfacl "in place"? ??? /drv/e/rel3.7-test/cygwin-3.7.0-0.332.g43ddce194c49.x86_64/\ inst/bin/getfacl --version returns 127 (as all my attempts do to make getfacl work "in place"). (Yes, of course, I can copy getfacl to some place else, but then it runs with the cygwin1.dll from /usr/bin, not the one from the install area) (but, again, no problem w/ strace) At the end I hacked up the "official" cygwin.bat -- see further down. (At the bottom of the .bat file, I included the response from mount and the one from getfacl --version) As prep. - I read the Users Guide (ch4), - several URLs from MS (dynamic-link library search order, dynamic-link redirection ...) - ploughed through the mailing-list - read ch5 of Hart's 4th ed. of "Windows System Programming", the par. related to "dynamic link libraries" - gave winsup/cygwin/dlfcn.cc a hard link (dlopen()) However my knowledge of Windows is utterly insufficient (in fact I have none). Still, I am intrigued by the failure, because I expected it to work, and it does for mingw executables (So, something else is giving the "No go"). So, if you are able to tell "from the top of year head" why it fails for getfacl, BUTygwin.com not for strace, I would be grateful ... [a] - https://sourceware.org/legacy-ml/cygwin/2013-08/msg00423.html ( Re: Why are the 32- and 64-bit cygwin1.dlls incompatible? ) --- Hacked-up cygwin.cat: @echo off setlocal enableextensions REM set TERM= set TERM=xterm-256color REM cd /d "%~dp0bin" && .\bash --login -i :: moved bin up ::cd /d "e:\rel3.7-test\cygwin-3.7.0-0.332.g43ddce194c49.x86_64\inst" && bin\bash.exe --login -i cd /d "e:\rel3.7-test\cygwin-3.7.0-0.332.g43ddce194c49.x86_64\inst" && bin\bash.exe REM start line w/ REM or :: :: This exercise suggets that root's mount-point is "preventing" the ability to verify executables, that were :: were installed outside their regular place in the tree (/usr/bin) :: it also suggests that the install recipe sucks: had to reorganize the tree (i.e. move directories upwards) :: REORGANIZE ... :: 64-@@ cd /drv/e/rel3.7-test/cygwin-3.7.0-0.332.g43ddce194c49.x86_64/inst/usr :: MOVE bin lib etc sbin one directory up (they should be peer to usr and below inst) :: and only then ADD: :: 64-@@ cp -p /usr/bin/bash.exe /drv/e/rel3.7-test/cygwin-3.7.0-0.332.g43ddce194c49.x86_64/inst/bin :: 64-@@ cp -p /usr/bin/mount.exe /drv/e/rel3.7-test/cygwin-3.7.0-0.332.g43ddce194c49.x86_64/inst/bin :: 64-@@ cp -p /usr/bin/ls.exe /drv/e/rel3.7-test/cygwin-3.7.0-0.332.g43ddce194c49.x86_64/inst/bin :: 64-@@ cp -p /usr/bin/id.exe /drv/e/rel3.7-test/cygwin-3.7.0-0.332.g43ddce194c49.x86_64/inst/bin :: 64-@@ cp -p /usr/bin/{cygintl-8.dll,cygiconv-2.dll} cygwin-3.7.0-0.332.g43ddce194c49.x86_64/inst/bin :: MORE CREATED: (as bash complains) :: 64-@@ mkdir /drv/e/rel3.7-test/cygwin-3.7.0-0.332.g43ddce194c49.x86_64/inst/tmp :: 64-@@ chmod 1777 /drv/e/rel3.7-test/cygwin-3.7.0-0.332.g43ddce194c49.x86_64/inst/tmp :: 64-@@ ls -l /drv/e/rel3.7-test/cygwin-3.7.0-0.332.g43ddce194c49.x86_64/inst :: total 12 :: drwxr-xr-x 1 Henri Users 0 Jan 14 10:58 bin :: drwxr-xr-x 1 Henri Users 0 Jan 8 03:23 etc :: drwxr-xr-x 1 Henri Users 0 Jan 14 10:16 lib :: drwxr-xr-x 1 Henri Users 0 Jan 8 03:23 sbin :: drwxrwxrwt 1 Henri None 0 Jan 14 09:44 tmp :: drwxr-xr-x 1 Henri Users 0 Jan 14 12:02 usr <= originally bin lib etc and sbin were here :: 64-@@ ./CygwinX.bat :: Executing '64' .bashrc, $- = himBH, login_shell off :: Did not source *profile* ... <==== only my .bashrc is sourced (hey, HOME was not touched) :: ForceV2 = 1 :: bash-5.2$ mount :: E:/rel3.7-test/cygwin-3.7.0-0.332.g43ddce194c49.x86_64/inst/bin on /usr/bin type ntfs (binary,auto) :: E:/rel3.7-test/cygwin-3.7.0-0.332.g43ddce194c49.x86_64/inst/lib on /usr/lib type ntfs (binary,auto) :: E:/rel3.7-test/cygwin-3.7.0-0.332.g43ddce194c49.x86_64/inst on / type ntfs (binary,auto) :: C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) :: E: on /cygdrive/e type ntfs (binary,posix=0,user,noumount,auto) :: bash-5.2$ getfacl --version :: getfacl (cygwin) 3.7.0 <==== Wow! :: Get POSIX ACL information :: Copyright (C) 2000 - 2026 Cygwin Authors :: This is free software; see the source for copying conditions. There is NO :: warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. :: bash-5.2$ ====== -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
