Weird (path) problems with cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 ...
Mon Aug 14 20:56:05 GMT 2023
On Aug 14 19:29, Roland Mainz via Cygwin wrote:
> On Mon, Aug 14, 2023 at 6:25 PM Roland Mainz <email@example.com> wrote:
> > On Mon, Aug 14, 2023 at 12:21 PM Corinna Vinschen via Cygwin
> > <firstname.lastname@example.org> wrote:
> > > On Aug 11 13:36, Mainz, Roland via Cygwin wrote:
> > > > In our case we have a project with both custom binaries and sources
> > > > both hosted on the filesystem as /home/rmainz/ (i.e. filesystem
> > > > mounted on H:, and then bind mount to /home/rmainz).
> > > >
> > > > After updating Cygwin to 3.5.0-0.384.g9939aa7d0945.x86_64 the build
> > > > now fails *IF* I access the binaries with their full absolute path AND
> > > > the sources with their absolute path:
> > > > ---- snip ----
> > > > $ cd /home/rmainz/tmp/try10_rde_new_rds/RDE-Development/build_windows4/tmp
> > > > $ ls -l x.cpp
> > > > -rw-r--r-- 1 rmainz rovdevel 110 Aug 11 15:32 x.cpp
> > > > $ /home/rmainz/tmp/try10_rde_new_rds/Dependencies/win/qt/qt_5_15_2/Tools/mingw810_64/bin/c++ $PWD/x.cpp
> > > > c++.exe: error: /home/rmainz/tmp/try10_rde_new_rds/RDE-Development/build_windows4/tmp/x.cpp: No such file or directory
> > > > c++.exe: fatal error: no input files
> > > > compilation terminated.
> > > > ---- snip ----
> > >
> > > I can't reproduce this:
> > >
> > > $ net use H: <blah>
> > Is <blah> Samba, CIFS or NFS ?
> > > $ mount -o exec H: /home/rmainz
> > > $ cd /home/rmainz/tmp
> > > $ cp /bin/cat.exe .
> > > $ mkdir baz
> > > $ echo foo > baz/bar
> > > $ /home/rmainz/tmp/cat $PWD/baz/bar
> > > foo
> > Grumpf... ;-(
> > ... I'm still seeing this problem.
> > The sources we are building are proprietary (sorry), but I can
> > reproduce this with both CITI's NFSv4.1 and Windows 10 builtin NFSv3
> > clients.
I switched the share to MSFT NFSv3
$ mount | grep H:
H: on /home/rmainz type nfs (binary,exec,user)
and the result is the same. Note that Cygwin supports MSFT NFSv3 but
not CITI NFSv4.1 internally. No gurantee that Cygwin always does what
is necessary for that other NFS.
> It seems the issue can be reduced to this on Cygwin
> 3.5.0-0.388.g1a646ad7970a.x86_64 - c++ with H:/path/.../x.cpp works,
> c++ with /home/rmainz/path/.../x.cpp does not.
Is that c++ a Cygwin binary or a native binary? For kicks I wrote
a q&d cat as mingw executable and retried the test. It happened
exactly what I expect to happen:
$ /home/rmainz/tmp/cat $PWD/baz/bar
Can't open /home/rmainz/tmp/baz/bar
Obviously, the native binary has no idea about the Cygwin mount points.
I tried this under 3.4.7 and the latest 3.5.0 with the same result.
If this c++ is a native binary, I wonder how it ever is supposed to work
with Cygwin mount points.
I also created the subdirs you're using under the assumption it has to do
with longer pathnames. I.e. I created
and moved cat.exe there, and I created
and moved my bar file in there. Then I called
$ /home/rmainz/tmp/winnfstest/hummingbirdnfstest1/try10_rde_new_rds/Dependencies/win/qt/qt_5_15_2/Tools/mingw810_64/bin/cat /home/rmainz/tmp/winnfstest/hummingbirdnfstest1/try10_rde_new_rds/RDE-Development/build_windows5/tmp/bar
With the mingw cat I get the output
Can't open /home/rmainz/tmp/winnfstest/hummingbirdnfstest1/try10_rde_new_rds/RDE-Development/build_windows5/tmp/bar
With Cygwin's cat I get the output
I get the same result, independently of using 3.4.7 or 3.5.0-0.388.
Whatever happens there, it has something to do with either the c++
binary, or with something *in* the longer path which is weird. I can't
judge that from here.
More information about the Cygwin