DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 60FCI3Av1616498
Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 60FCI3Av1616498
Authentication-Results: delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=MlKGcOkF
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E00E64BA2E34
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1768479482;
	bh=ONfTUWsMyGVvhPdSB4AfmY7SM/oCsASMYGwnx5jGELM=;
	h=Date:Subject:To:List-Id:List-Unsubscribe:List-Archive:List-Post:
	 List-Help:List-Subscribe:From:Reply-To:From;
	b=MlKGcOkF4hjfSeQ5VT54md0iekVY1otoWLXna3z3QaFxu6Vjw7eqz1RkrhuYDR9j/
	 7qNADwhVjSXFWPB7//OQfWLSm7Y80qPceKe3ZpwYg8MR+bd1MLuLPRB34ecXgN/qsd
	 1jwuyx8BIer2axCokphPoTHmY4Zx+uB3fbFj8h0w=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C88D34BA2E2D
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C88D34BA2E2D
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1768479430; cv=none;
 b=r/ELsxOwtIVyV3fmsQAzAKNJBa4CIligfakY7+sLlKcM7JwuuG9eDhnMdiqWDdzfPBRAb+zAaoLL0T3QqQM3y/nIo9yd5L2W4JtG4lMu20gVrIDeUJ32keHZ3UhPtLj75FsI4wXalCbfT0dZgf5Kjk3Y8RDVCVJWT5IIDYwmh44=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
 t=1768479430; c=relaxed/simple;
 bh=w1tEDvWrY1tQRKWbRN8q6Y3p5lT7FoveW35mGw6JWMU=;
 h=DKIM-Signature:Message-ID:Date:MIME-Version:From:Subject:To;
 b=sFo+sRgmVgZ43DE4+RpIK3iQ5+sv3zB47jQiNZKUDfneBQNaxsLo7vrUQGk64GkNNLbCXOqDyn8LhXqdSBsqSpNrsdqb2WqYtOHIT4Vqn9gN+3LSknjj/IHFWFtlC1Fp6+C9yGHN6Rk3pNWzmq6SvynWKevguSOrQYieh+hzzko=
ARC-Authentication-Results: i=1; server2.sourceware.org
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C88D34BA2E2D
X-KPN-MessageId: 234feb9c-f20c-11f0-9696-005056abbe64
X-KPN-MID: 33|BV0gZUJ3/BrJvOPVU36ks33xvy/kAAruDVIwKTi9L0bDFZi/34K+yiig3cUKXqw
 oF5R2flTPaE7uctBI+9jb3RdYAwl/icSmdD3qtglsilo=
X-KPN-VerifiedSender: Yes
X-CMASSUN: 33|FkF8KCCzZJHBEUv59UPsHNmJkhpzpxtrtkOg9NeeFDWlNmtKvcvKbc5xxizax7Q
 XmnuWiYShCWtPqzH991Ddxg==
X-Originating-IP: 77.173.35.122
Message-ID: <1a032a35-b052-414e-9acc-8bfc605ce260@xs4all.nl>
Date: Thu, 15 Jan 2026 13:17:08 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
Subject: Why cannot an installed (by cygport) executable be run "in place"?
To: cygwin AT cygwin DOT com
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: "J.H. vd Water via Cygwin" <cygwin AT cygwin DOT com>
Reply-To: "J.H. vd Water" <dhr-incognito AT xs4all DOT nl>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

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