Re: cmake suddenly stopped working

[Norton Allen]

Rolling back cmake from 3.17.3-2 to 3.14.5-1 seems to have resolved the 
problem.


Any idea why no one else seems to be seeing this problem with 3.17.3-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

Re: cmake suddenly stopped working

[Norton Allen]

On 11/17/2020 6:48 PM, Norton Allen wrote:

On 11/17/2020 6:21 PM, Norton Allen wrote:

On 11/17/2020 5:48 PM, Mark Geisert wrote:

Norton Allen wrote:

Is anyone else seeing this? Any suggestions?


I'm not seeing it.  'cmake --help' works for me.
Does 'ldd /usr/bin/cmake' give any hint? 


ldd did not complain, but your question reminded me that I should try 
running under strace. That produce the complaint:


   The procedure entry point
   _ZNSt19basic_ostringstreamlcSt11char_traitslcESalcEEC1Ev could not
   be located in the dynamic link library C:\cygwin64\bin\cmake.exe

(I had to type that in, as I could not copy from strace's error dialog.)

That looks like it might be an issue with the g++ library? Any chance 
there was a change in the library that might require a recompile/relink?


I will try rolling that one back. 



Rolling back to gcc-g++ 9.3.0 did not help.

I did find that entry point string in cmake.exe (all the lowercase 
'L's I typed in that are actually capital i's. My font makes no 
distinction) and I was able to locate a matching string in 
/lib/gcc/x86_64-pc-cygwin/9.3.0/libstdc++.a, but not in 
libstdc++.dll.a. Running strings on the /usr/bin/cygstdc++-6.dll 
showed the same information. Maybe I need to roll back further!


This seems to be the crux of it. That entry point is simply not in the 
g++ shared library. I have not figured out why this cropped up today, 
since it is not present in the current (10.2.0-1) or previous (9.3.0-2) 
versions. I will trying going back to 7.4.0.1, but it's hard to imagine 
it's been gone so long and I haven't seen the problem before today.


    nort@easwhlpt3425080 /usr/bin
    $ strings cygstdc++-6.dll | grep 
_ZNSt19basic_ostringstreamIcSt11char_traits

    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEE3strERKSs
    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEE4swapERS3_
    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEEC1EOS3_
_ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEEC1ERKSsSt13_Ios_Openmode
_ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEEC1ESt13_Ios_Openmode
    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEEC2EOS3_
_ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEEC2ERKSsSt13_Ios_Openmode
_ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEEC2ESt13_Ios_Openmode
    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEED0Ev
    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEED1Ev
    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEED2Ev
    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEEaSEOS3_

    nort@easwhlpt3425080 /usr/bin
    $ strings cmake.exe | grep _ZNSt19basic_ostringstreamIcSt11char_traits
    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEEC1Ev
    _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEED1Ev

Does this seem like a problem that is likely to be resolved by 
rebuilding cmake?



--
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

Re: cmake suddenly stopped working

[Norton Allen]

On 11/17/2020 6:21 PM, Norton Allen wrote:

On 11/17/2020 5:48 PM, Mark Geisert wrote:

Norton Allen wrote:

Is anyone else seeing this? Any suggestions?


I'm not seeing it.  'cmake --help' works for me.
Does 'ldd /usr/bin/cmake' give any hint? 


ldd did not complain, but your question reminded me that I should try 
running under strace. That produce the complaint:


   The procedure entry point
   _ZNSt19basic_ostringstreamlcSt11char_traitslcESalcEEC1Ev could not
   be located in the dynamic link library C:\cygwin64\bin\cmake.exe

(I had to type that in, as I could not copy from strace's error dialog.)

That looks like it might be an issue with the g++ library? Any chance 
there was a change in the library that might require a recompile/relink?


I will try rolling that one back. 



Rolling back to gcc-g++ 9.3.0 did not help.

I did find that entry point string in cmake.exe (all the lowercase 'L's 
I typed in that are actually capital i's. My font makes no distinction) 
and I was able to locate a matching string in 
/lib/gcc/x86_64-pc-cygwin/9.3.0/libstdc++.a, but not in libstdc++.dll.a. 
Running strings on the /usr/bin/cygstdc++-6.dll showed the same 
information. Maybe I need to roll back further!



--
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

Re: Please add /cygdrive/c/Windows/Sysnative to the default PATH

[tealhill via Cygwin]

On 2020-11-17 4:23 PM, Thomas Wolff wrote:

Am 17.11.2020 um 20:54 schrieb tealhill via Cygwin:

>>

Cygwin's /etc/profile sets the PATH.

Could /etc/profile please also add /cygdrive/c/Windows/Sysnative to 
the end of the PATH?

>

It doesn't add any other Windows folders so why this one.


### Summary

Why should Cygwin add Sysnative to $PATH?  As a workaround for 
Microsoft's failure to add Sysnative to %PATH%.


### Full explanation

Cygwin imports the Windows %PATH% variable at startup.

It would be ideal if Microsoft would add Sysnative to the default 
Windows %PATH%.  Such a change would help Cygwin users and others.  But 
I doubt that Microsoft will make this change.


Therefore, I am suggesting that Cygwin work around Microsoft's omission. 
 My suggested workaround is for Cygwin to add Sysnative to its own 
$PATH, automatically.


--
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

Re: [ITA] wget

[Brian Inglis]

On 2020-11-17 12:10, Achim Gratz wrote:

Brian Inglis writes:

I dug up some Debian, Fedora, and OpenSuSE patches, and added them to the 
cygport.
OpenSuSE patches appear only to be available in their source package,
or online in their HTML page, for which I came up with a script to
grab a package's patch URLs, scrape those web pages for the patch
source, and convert from HTML to patch text. Do you know if there is
any way to access OBS patches as plain text?


Nothing that I've used before, but it wouldn't hurt to ask.  There
obviously is some sort of an API that the osc CLI is using (I don't know
any details of that either), but how far that extends to plain HTTPS
REST requests I don't know.


This build avoids autoreconf (from Eric).


That is probably not urgent, but I'd check if it can be re-enabled.  For
a while Cygwin had a too old autoconf version that would not work with
some packages tha twere using the newer ones, but that's no longer an
issue I'd think.


It would make sense to list DIFF_EXCLUDES in DISTCLEANFILES to avoid
them being packaged in the first place, as long as that did not break
the build.

So should I set DISTCLEANFILES to all the files *created* in the
following log extracts, and set DIFF_EXCLUDES to those for which
patches are created, or could more of each list be added to both?


In principle you should remove all files that are recreated anyway in
DISTCLEANFILES.  Now, generated files showing up in the diff at all is a
likely deficiency in configure, as these should not be generated in the
source directory at all, I'd think.  But getting a project that isn't
quite cleaned up for a separate build dir to put the files in the right
place (and later find them) can be quite an adventure.


Thanks again, that appears to be working after I tracked down one outlyer, and I 
pushed the updates to run under CI, which now also builds and tests cleaner.


I will try defaulting src_compile to allow autoreconfig, and push if it works.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: cmake suddenly stopped working

[Norton Allen]

On 11/17/2020 5:48 PM, Mark Geisert wrote:

Norton Allen wrote:

Is anyone else seeing this? Any suggestions?


I'm not seeing it.  'cmake --help' works for me.
Does 'ldd /usr/bin/cmake' give any hint? 


ldd did not complain, but your question reminded me that I should try 
running under strace. That produce the complaint:


   The procedure entry point
   _ZNSt19basic_ostringstreamlcSt11char_traitslcESalcEEC1Ev could not
   be located in the dynamic link library C:\cygwin64\bin\cmake.exe

(I had to type that in, as I could not copy from strace's error dialog.)

That looks like it might be an issue with the g++ library? Any chance 
there was a change in the library that might require a recompile/relink?


I will try rolling that one back.


--
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

Re: cmake suddenly stopped working

[Mark Geisert]

Norton Allen wrote:

Windows 10

Cygwin installed all up to date

cmake 3.17.3-2, which does not appear to have changed since August

Symptoms: cmake fails silently with (or without) any arguments, including --help. 
Exit code is 127


That exit code usually indicates a missing library at runtime.


I tried to reinstall cmake, the file appears to be identical

cygcheck -s and cygcheck /usr/bin/cmake both look OK to to me, though I'd be happy 
to upload if anyone is interested.


My AV is ESET. Tried disabling it to no effect.

This could have been caused by a recent cygwin update. The following were all 
installed last Friday. Would anyone like to guess which are worth checking? I will 
cross-check with the cygcheck output for cmake.


Is anyone else seeing this? Any suggestions?


I'm not seeing it.  'cmake --help' works for me.
Does 'ldd /usr/bin/cmake' give any hint?

..mark
--
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

cmake suddenly stopped working

[Norton Allen]

Windows 10

Cygwin installed all up to date

cmake 3.17.3-2, which does not appear to have changed since August

Symptoms: cmake fails silently with (or without) any arguments, 
including --help. Exit code is 127


I tried to reinstall cmake, the file appears to be identical

cygcheck -s and cygcheck /usr/bin/cmake both look OK to to me, though 
I'd be happy to upload if anyone is interested.


My AV is ESET. Tried disabling it to no effect.

This could have been caused by a recent cygwin update. The following 
were all installed last Friday. Would anyone like to guess which are 
worth checking? I will cross-check with the cygcheck output for cmake.


Is anyone else seeing this? Any suggestions?

   Nov 13 11:30 gdb.lst.gz
   Nov 13 11:30 git.lst.gz
   Nov 13 11:30 gcc-g++.lst.gz
   Nov 13 11:30 libsource-highlight4.lst.gz
   Nov 13 11:30 openssh.lst.gz
   Nov 13 11:29 gcc-core.lst.gz
   Nov 13 11:29 libboost_regex1.66.lst.gz
   Nov 13 11:29 make.lst.gz
   Nov 13 11:29 libfido2.lst.gz
   Nov 13 11:29 libsource-highlight-common.lst.gz
   Nov 13 11:29 libzstd1.lst.gz
   Nov 13 11:29 libisl22.lst.gz
   Nov 13 11:29 libicu61.lst.gz
   Nov 13 11:29 libguile2.2_1.lst.gz
   Nov 13 11:29 libcbor.lst.gz
   Nov 13 11:29 libjsoncpp24.lst.gz
   Nov 13 11:29 screen.lst.gz
   Nov 13 11:29 libncurses-devel.lst.gz
   Nov 13 11:29 less.lst.gz
   Nov 13 11:29 graphviz.lst.gz
   Nov 13 11:29 file.lst.gz
   Nov 13 11:29 doxygen.lst.gz
   Nov 13 11:29 cygwin-doc.lst.gz
   Nov 13 11:29 bzip2.lst.gz


--
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

Re: Please add /cygdrive/c/Windows/Sysnative to the default PATH

[Thomas Wolff]

Am 17.11.2020 um 20:54 schrieb tealhill via Cygwin:

Dear all:

### Background information (you can skip this)

 ...

### The problem

32-bit tools, such as 32-bit Cygwin, don't usually see the real 
System32 directory.  Instead, when they try to look inside System32, 
Windows shows them the contents of a different directory, which 
contains only 32-bit System32 tools.


If 32-bit Cygwin needs to run a 64-bit tool, such as pluck.exe (from 
Pluckeye) or wsl.exe (from the Windows Subsystem for Linux), it must 
look in a different directory instead.  It must look in 
C:\Windows\Sysnative.  In this virtual folder, 32-bit Cygwin can see 
all the 64-bit System32 tools.


If you try to run pluck.exe without specifying that it's in 
/cygdrive/c/Windows/Sysnative, you'll get the output:


[user@host ~]$ pluck
-bash: pluck: command not found

This 'virtual folder' stuff is non-obvious and confusing.  It took me 
some time to figure it all out.
I ran into this kind of problem myself. These virtual folders are a 
nuisance and it's bothersome and tricky to find out, especially as 
Sysnative is hidden by default.
But that's a Windows issue, not a cygwin issue. Cygwin doesn't handle 
other Windows paths either.


### Proposed solution

Cygwin's /etc/profile sets the PATH.

Could /etc/profile please also add /cygdrive/c/Windows/Sysnative to 
the end of the PATH?
It doesn't add any other Windows folders so why this one. You should do 
that in your ~/.profile.
I'd suggest however to make those virtual folders visible from Cygwin, 
so you could find the hidden stuff from /Windows with ls, echo, or `find`.

Thomas
--
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

Please add /cygdrive/c/Windows/Sysnative to the default PATH

[tealhill via Cygwin]

Dear all:

### Background information (you can skip this)

I use Pluckeye 0.99.60 for Windows.  This is a self-control tool, 
available online.  It can help to stop me from visiting certain 
time-wasting websites.


I also use Pluckeye's command-line component, pluck.exe.  [I invoke the 
tool from Bash 4.4.12.  I'm running Bash on 32-bit Cygwin 
3.1.7(0.340/5/3) on 64-bit Windows 10 build 19041.]


pluck.exe is a 64-bit tool, stored in C:\Windows\System32.

### The problem

32-bit tools, such as 32-bit Cygwin, don't usually see the real System32 
directory.  Instead, when they try to look inside System32, Windows 
shows them the contents of a different directory, which contains only 
32-bit System32 tools.


If 32-bit Cygwin needs to run a 64-bit tool, such as pluck.exe (from 
Pluckeye) or wsl.exe (from the Windows Subsystem for Linux), it must 
look in a different directory instead.  It must look in 
C:\Windows\Sysnative.  In this virtual folder, 32-bit Cygwin can see all 
the 64-bit System32 tools.


If you try to run pluck.exe without specifying that it's in 
/cygdrive/c/Windows/Sysnative, you'll get the output:


[user@host ~]$ pluck
-bash: pluck: command not found

This 'virtual folder' stuff is non-obvious and confusing.  It took me 
some time to figure it all out.


### Proposed solution

Cygwin's /etc/profile sets the PATH.

Could /etc/profile please also add /cygdrive/c/Windows/Sysnative to the 
end of the PATH?


### Conclusion

Thank you for reading this!

Also, I thank all of you who help out with the Cygwin project.

--
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

Re: git repositories for cygwin packaging - please test

[Achim Gratz]

Brian Inglis writes:
> Could anyone please check and advise if the attached .git/config will
> allow me to push to the playground repo and later branch for testing,
> or demo the appropriate .git/config entries or git config commands to
> do so properly?

I usually define my own repo schemes in the global (user) Git config:

--8<---cut here---start->8---
[url "ssh://sourceware.org/git/"]
pushInsteadOf = cygwin:
[url "ssh://cyg...@cygwin.com"]
pushInsteadOf = git://cygwin.com
[url "git://cygwin.com/git/cygwin-packages"]
InsteadOf = cygpack:
[url "ssh://cyg...@cygwin.com/git/cygwin-packages"]
pushInsteadOf = cygpack:
--8<---cut here---end--->8---

which then enables me to address the repo  like this (each package is a
submodule in an umbrella repository:

--8<---cut here---start->8---
[submodule "perl"]
url = cygpack:/perl
active = true
--8<---cut here---end--->8---

THis also works on the command line, so if I ever want to check out
something quickly it is a lot easier to type.  I never configure the
playground as a local branch, I've posted how to push to that branch and
remove it if and when you need it earlier.

> Is there any way to move tags to a later commit once pushed?

A tag is just a special commit, so as with all things Git: no, unless
you can rewrite history, i.e. force-push.  Just do not tag things you
haven't published.

> Finally are there other CI jobs.cgi?params=... other than id,
> e.g. jobs.cgi?by=Brian+Inglis?

Yes, that database is now large enough that filtering would be helpful.
Probably a case of SHTDI, PTC… :-)


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [ITA] wget

[Achim Gratz]

Brian Inglis writes:
> I dug up some Debian, Fedora, and OpenSuSE patches, and added them to the 
> cygport.
> OpenSuSE patches appear only to be available in their source package,
> or online in their HTML page, for which I came up with a script to
> grab a package's patch URLs, scrape those web pages for the patch
> source, and convert from HTML to patch text. Do you know if there is
> any way to access OBS patches as plain text?

Nothing that I've used before, but it wouldn't hurt to ask.  There
obviously is some sort of an API that the osc CLI is using (I don't know
any details of that either), but how far that extends to plain HTTPS
REST requests I don't know.

> This build avoids autoreconf (from Eric).

That is probably not urgent, but I'd check if it can be re-enabled.  For
a while Cygwin had a too old autoconf version that would not work with
some packages tha twere using the newer ones, but that's no longer an
issue I'd think.

> It would make sense to list DIFF_EXCLUDES in DISTCLEANFILES to avoid
> them being packaged in the first place, as long as that did not break
> the build.
>
> So should I set DISTCLEANFILES to all the files *created* in the
> following log extracts, and set DIFF_EXCLUDES to those for which
> patches are created, or could more of each list be added to both?

In principle you should remove all files that are recreated anyway in
DISTCLEANFILES.  Now, generated files showing up in the diff at all is a
likely deficiency in configure, as these should not be generated in the
source directory at all, I'd think.  But getting a project that isn't
quite cleaned up for a separate build dir to put the files in the right
place (and later find them) can be quite an adventure.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: g++ and c++17 filesystem

[René Berber via Cygwin]

On 11/17/2020 9:15 AM, Kristian Ivarsson via Cygwin wrote:


The filesystem-library as a part of C++17 seems to have some defects and
flaws in the cygwin-package and pretty much every lexical- and canonical
operation works in mysterious ways (or not at all)

[snip]

https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32

--
R.Berber
--
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

Re: Open MPI broken (November 2 release) ?

[Marco Atzeri via Cygwin]

On 17.11.2020 16:13, Dennis Willen via Cygwin wrote:

Looks like copy/paste mangled the lines.  I'll try again.  Is the openMPI 
distribution not picking up all the libraries that should come along?
Denny@DESKTOP-BEBCMC4 ~/MPI_tests$ mpifort 
testmpi.f90/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
 cannot find 
-lhwloc/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: 
cannot find 
-levent_core/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
 cannot find 
-levent_pthreads/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
 cannot find -lzcollect2: error: ld returned 1 exit status



can you send me the log files ?
It seems your system has problem in properly breaking the lines

I do not see problem on the /usr/lib/pkgconfig
files

$ grep  Libs ompi.pc
# dependencies), so only list these in Libs.private.
Libs: -L${libdir} -L${libdir}  -lmpi
Libs.private: -lhwloc -levent_core -levent_pthreads -lz
--
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

How to compile only cygwin1.dll in newlib-cygwin repository?

[Biswapriyo Nath via Cygwin]

Is it possible to compile only cygwin1.dll in newlib-cygwin
repository? I want to skip building all docs and the installation of
xmlto like programs. Also there is an error:
../../../../winsup/cygwin/gendef: No such file or directory
Any hint?
--
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

Re: Open MPI broken (November 2 release) ?

[Dennis Willen via Cygwin]

(Last attempt to add CF/LF ...)
Is the openMPI install not picking up all the libraries that it should?

-Original Message-
From: Dennis Willen via Cygwin 
To: cygwin@cygwin.com 
Sent: Mon, Nov 16, 2020 3:21 pm
Subject: Open MPI broken (November 2 release) ?

I tried re-compiling some things after updating to openmpi 4.0.5 and am getting 
some unexpected failures from mpifort and mpicc:

$ mpifort -O3 
testmpi.f90/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
 cannot find 
-lhwloc/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: 
cannot find 
-levent_core/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
 cannot find 
-levent_pthreads/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
 cannot find -lzcollect2: error: ld returned 1 exit status

Denny@DESKTOP-BEBCMC4 ~/MPI_tests$

I have some working executables from October 26, so I assume there is a problem 
or something else that I need to update.  An example causing the above problem 
follows.  Running Cygwin on an Intel i9-9900K.  Thanks for your help.

Example:
program 
testmpi!!!  
MPI tests.!!  - Hello World!  - Broadcast and reduce!  - Pass along real array! 
 -!  -!
!implicit 
noneinclude 'mpif.h'integer:: myproc, numproc, ierr, len, 
istatus(mpi_status_size)character(mpi_max_processor_name):: hostnameinteger:: 
nreal*4:: y, z, x(1024)!!  Hello world.!call mpi_init(ierr)call 
mpi_comm_rank(mpi_comm_world, myproc, ierr)call mpi_comm_size(mpi_comm_world, 
numproc, ierr)call mpi_get_processor_name(hostname, len, 
ierr)write(6,'(i5,a19,a6)') myproc, ': Hello world from ', hostnamecall 
mpi_barrier(mpi_comm_world,ierr)!!  Broadcast and reduce.!y = 0.0z = 
0.0if(myproc.eq.0) y = 1.0call mpi_bcast(y, 1, mpi_real, 0, mpi_comm_world, 
ierr)call mpi_reduce(y, z, 1, mpi_real, mpi_sum, 0, mpi_comm_world,  
ierr)if(myproc.eq.0) write(6,*) numproc, ' should be ', zcall 
mpi_barrier(mpi_comm_world,ierr)!!  Up the chain and back to the 
start.!if(myproc==0) then  do n=1, 1024    x(n) = float(n)    enddoelse  do 
n=1, 1024    x(n) = -float(n)    enddo  call mpi_recv(x, 1024, mpi_real, 
myproc-1, mpi_any_tag,  &                mpi_comm_world, istatus, ierr)  
endifif(myprochttps://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:    https://cygwin.com/ml/#unsubscribe-simple
--
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

g++ and c++17 filesystem

[Kristian Ivarsson via Cygwin]

Hi folks

The filesystem-library as a part of C++17 seems to have some defects and
flaws in the cygwin-package and pretty much every lexical- and canonical
operation works in mysterious ways (or not at all)


Following output with g++cygwin

 $ uname -a
 CYGWIN_NT-10.0 JOKK 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin

 $ g++ --version
 g++ (GCC) 10.2.0
 Copyright (C) 2020 Free Software Foundation, Inc.
 This is free software; see the source for copying conditions.  There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 $ g++ -std=c++17 main.cpp

 $ ./a.exe
 true
 C:/Temp
 filesystem error: cannot make canonical path: No such file or directory
[C:/Temp]


Following output with mingw (that also is a bit strange (note the last
"generic" (i.e. posix) output))

 $ .\g++.exe --version
 g++.exe (MinGW.org GCC Build-2) 9.2.0
 Copyright (C) 2019 Free Software Foundation, Inc.
 This is free software; see the source for copying conditions.  There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 $ .\g++.exe -std=c++17 main.cpp 

 $ .\a.exe
 true
 C:/Temp
 C:\Temp


Following output with cl (that seems to be the most standard-conformant)

 C:\>cl /std:c++17 main.cpp
 Microsoft (R) C/C++ Optimizing Compiler Version 19.27.29112 for x86
 Copyright (C) Microsoft Corporation.  All rights reserved.

 main.cpp

 /out:main.exe
 main.obj

 C:\>main.exe
 true
 C:/Temp
 C:/Temp



I have failed to find out exactly where the defect are though and I also do
have a hard time to see where/how/if there's a gcc/g++/mingw- or
libstdc++-fork for the cygwin package where this breaks


Does anyone have any ideas about this and know of any patches or (hot)fixes
to this ? 

I haven't tried out all the mingw generic/lexical/canonical functions yet,
but maybe they're flawed as well


Thanx in advance



Best regards,
Kristian




#include 
#include 
#include 

// g++ -std=c++17 main.cpp


int main()
{

   try
   {
  const std::filesystem::path path{"C:\\Temp"};
  std::cout << std::boolalpha << std::filesystem::exists(path) << 
std::noboolalpha << std::endl;
  std::cout << path.generic_u8string() << std::endl;
  std::cout << std::filesystem::canonical(path).generic_u8string() << 
std::endl;
   }
   catch(const std::exception& e)
   {
  std::cerr << e.what() << std::endl;
   }


   return 0;
}

--
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

Re: Open MPI broken (November 2 release) ?

[Dennis Willen via Cygwin]

Looks like copy/paste mangled the lines.  I'll try again.  Is the openMPI 
distribution not picking up all the libraries that should come along?
Denny@DESKTOP-BEBCMC4 ~/MPI_tests$ mpifort 
testmpi.f90/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
 cannot find 
-lhwloc/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: 
cannot find 
-levent_core/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
 cannot find 
-levent_pthreads/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
 cannot find -lzcollect2: error: ld returned 1 exit status
Denny@DESKTOP-BEBCMC4 ~/MPI_tests$ cat testmpi.f90program 
testmpi!!!  
MPI tests for Raspberry Pi cluster.!!  - Hello World!  - Broadcast and reduce!  
- Pass along real array!  -!  
-!!implicit 
noneinclude 'mpif.h'integer:: myproc, numproc, ierr, len, 
istatus(mpi_status_size)character(mpi_max_processor_name):: hostnameinteger:: 
nreal*4:: y, z, x(1024)!!  Hello world.!call mpi_init(ierr)call 
mpi_comm_rank(mpi_comm_world, myproc, ierr)call mpi_comm_size(mpi_comm_world, 
numproc, ierr)call mpi_get_processor_name(hostname, len, 
ierr)write(6,'(i5,a19,a6)') myproc, ': Hello world from ', hostnamecall 
mpi_barrier(mpi_comm_world,ierr)!!  Broadcast and reduce.!y = 0.0z = 
0.0if(myproc.eq.0) y = 1.0call mpi_bcast(y, 1, mpi_real, 0, mpi_comm_world, 
ierr)call mpi_reduce(y, z, 1, mpi_real, mpi_sum, 0, mpi_comm_world,  &          
      ierr)if(myproc.eq.0) write(6,*) numproc, ' should be ', zcall 
mpi_barrier(mpi_comm_world,ierr)!!  Up the chain and back to the 
start.!if(myproc==0) then  do n=1, 1024    x(n) = float(n)    enddoelse  do 
n=1, 1024    x(n) = -float(n)    enddo  call mpi_recv(x, 1024, mpi_real, 
myproc-1, mpi_any_tag,  &                mpi_comm_world, istatus, ierr)  
endifif(myproc
To: cygwin@cygwin.com 
Sent: Mon, Nov 16, 2020 3:21 pm
Subject: Open MPI broken (November 2 release) ?

I tried re-compiling some things after updating to openmpi 4.0.5 and am getting 
some unexpected failures from mpifort and mpicc:
$ mpifort -O3 
testmpi.f90/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
 cannot find 
-lhwloc/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: 
cannot find 
-levent_core/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
 cannot find 
-levent_pthreads/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
 cannot find -lzcollect2: error: ld returned 1 exit status
Denny@DESKTOP-BEBCMC4 ~/MPI_tests$
I have some working executables from October 26, so I assume there is a problem 
or something else that I need to update.  An example causing the above problem 
follows.  Running Cygwin on an Intel i9-9900K.  Thanks for your help.
Example:
program 
testmpi!!!  
MPI tests for Raspberry Pi cluster.!!  - Hello World!  - Broadcast and reduce!  
- Pass along real array!  -!  
-!!implicit 
noneinclude 'mpif.h'integer:: myproc, numproc, ierr, len, 
istatus(mpi_status_size)character(mpi_max_processor_name):: hostnameinteger:: 
nreal*4:: y, z, x(1024)!!  Hello world.!call mpi_init(ierr)call 
mpi_comm_rank(mpi_comm_world, myproc, ierr)call mpi_comm_size(mpi_comm_world, 
numproc, ierr)call mpi_get_processor_name(hostname, len, 
ierr)write(6,'(i5,a19,a6)') myproc, ': Hello world from ', hostnamecall 
mpi_barrier(mpi_comm_world,ierr)!!  Broadcast and reduce.!y = 0.0z = 
0.0if(myproc.eq.0) y = 1.0call mpi_bcast(y, 1, mpi_real, 0, mpi_comm_world, 
ierr)call mpi_reduce(y, z, 1, mpi_real, mpi_sum, 0, mpi_comm_world,  &          
      ierr)if(myproc.eq.0) write(6,*) numproc, ' should be ', zcall 
mpi_barrier(mpi_comm_world,ierr)!!  Up the chain and back to the 
start.!if(myproc==0) then  do n=1, 1024    x(n) = float(n)    enddoelse  do 
n=1, 1024    x(n) = -float(n)    enddo  call mpi_recv(x, 1024, mpi_real, 
myproc-1, mpi_any_tag,  &                mpi_comm_world, istatus, ierr)  
endifif(myprochttps://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:    https://cygwin.com/ml/#unsubscribe-simple
--
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