date:20160726

On 7/26/16, 12:02 PM, Mark Geisert wrote:

>If this turns out to be a workable solution, I am willing to be maintainer
>of the glue library Bill is offering.

I have created a new repository here:

https://github.com/billziss-gh/cygfuse

It contains the following:

- fuse.cygport
- cygfuse.c
- The implementation of cygfuse.dll; this is WinFsp specific at this
time.
- fuse.pc.in
- Pkg-config file.
- inc/fuse
- FUSE headers from the WinFsp project.

[NOTE:
The FUSE headers may give the future maintainer some trouble. They are
admittedly a convoluted way of doing things. At the time I wrote them I
wanted them to serve as public headers offering a FUSE API for native
*and* Cygwin apps. I also wanted to have the option of not needing to link
with a libfuse.a or cygfuse.dll, thence the heavy use of “static inline”.

I expect that a future maintainer would refactor those heavily or perhaps
ditch them altogether and switch to the libfuse headers.]

To build the FUSE package, try:

$ make cygport
$ cd fuse-2.8-4.x86_64/dist/fuse/
$ tar -C/ -xaf fuse-2.8-4.tar.xz

To test that things work, clone my sshfs repo from:

https://github.com/billziss-gh/sshfs

And issue the following commands:

$ autoreconf -i
$ ./configure
$ make
$ ./sshfs -o idmap=user user@host: Y:   # do this from a non-admin 
prompt
...
$ pkill sshfs

I have not changed the license yet, but will do so if Mark (or someone
else) takes over the repo.

Bill

PS: I am going AWOL this Friday.

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.6.0-0.2

On Jul 26 15:30, Ken Brown wrote:
> On 7/26/2016 1:37 PM, Corinna Vinschen wrote:
> > Now for some testing of the new API...? :)
> 
> There seems to be a collation bug.  Here's a test case, extracted from the
> emacs test suite:
> 
> $ cat collation_test.c
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> int
> main (void)
> {
>   locale_t loc = newlocale (LC_COLLATE_MASK | LC_CTYPE_MASK,
> "en_US.UTF-8", 0);
>   if (!loc)
> {
>   perror ("newlocale");
>   exit (1);
> }
> 
>   wchar_t *p1 = L"xyzzy", *p2 = L"XYZZY";
>   errno = 0;
>   int res = wcscoll_l (p1, p2, loc);
>   if (errno)
> {
>   perror ("wcscoll_l");
>   exit (1);
> }
>   char res_ch = res < 0 ? '<' : res > 0 ? '>' : '=';
>   freelocale (loc);
>   printf ("\"%ls\" %c \"%ls\" in locale en_US.UTF-8\n", p1, res_ch, p2);
> }
> 
> $ gcc collation_test.c
> 
> $ ./a
> "xyzzy" > "XYZZY" in locale en_US.UTF-8

Thanks a lot for the testcase.  I applied a patch, but it's late here so
I create a new testversion tomorrow.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: [ITP] FUSE 2.8

On 7/26/16, 1:07 PM, Adrien JUND wrote:


>Excellent idea Bill !
>I am absolutely willing to do it !
>
>Dokan install folder can also be retrieved from the registry so it is
>a way to go with dlopen and dlsym mechanism.

Great. I am glad that this seems like it might work.

>Since I think all fuse wrapper in this fuse project should propose the
>same FUSE VERSION,
>I will need some time for updating it Dokan fuse that is currently 2.7
>when WinFSP is 2.8.

I agree.

Bill

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.6.0-0.2

2016-07-26 Thread Denis Excoffier

> On 2016-07-26 16:00, Corinna Vinschen wrote:
> 
> Hi Cygwin developers and maintainers,
> Hi everyone else,
> 
> 
> I uploaded a new Cygwin test release 2.6.0-0.2.
> 
> Supposed to fix the problems reported in
> https://cygwin.com/ml/cygwin/2016-07/msg00274.html and followups.
> 
Hello,

Is this test release expected to work on 32 bits?

I have a CYGWIN_NT-6.1-WOW (W7 + 32bits) and my .bat file (that contains
("bash --long -i") breefly opens but immediately closes with
no text output. Permissions on the cygwin1.dll file are correct.

2.6.0-0.1 does the same. However, 2.5.2-1 is ok, and
snapshots dated 20160714 and 20160719 were ok also.

I desactivated my .profile, in order that LC_CTYPE=fr_FR@euro
does not enter into the picture, but same result.

I also recompiled from the sources, no error, but same result.

Latest packages.

Regards,

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.6.0-0.1

2016-07-26 Thread Jim Reisert AD1C

On Tue, Jul 26, 2016 at 8:04 AM, Corinna Vinschen wrote:

> Hopefully fixed in 2.6.0-0.2 which I just uploaded and announced.

Yes, fixed, thanks.  There are no dumb bugs, only the ones you don't find.

-- 
Jim Reisert AD1C, , http://www.ad1c.us

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ITP] FUSE 2.8

2016-07-26 Thread Adrien JUND

Excellent idea Bill !
I am absolutely willing to do it !

Dokan install folder can also be retrieved from the registry so it is
a way to go with dlopen and dlsym mechanism.

Since I think all fuse wrapper in this fuse project should propose the
same FUSE VERSION,
I will need some time for updating it Dokan fuse that is currently 2.7
when WinFSP is 2.8.

Thank you Mark Geisert for willing to maintain it !

2016-07-26 20:38 GMT+02:00 Bill Zissimopoulos :
> On 7/25/16, 11:27 PM, Mark Geisert wrote:
>
>
>>Bill Zissimopoulos writes:
>>> - Rename the package to winfsp-fuse, but have it somehow “satisfy”
>>> packages that require “fuse” (e.g. SSHFS, FUSEPY). This would allow
>>> multiple *-fuse packages to exist in the setup database and the user
>>> chooses which one they want. My understanding based on Marco’s answer is
>>> that this is not currently supported by Cygwin’s dependency system.
>>
>>You could define a package "fuse" with no contents and a dependency on
>>package "winfsp-fuse".  Then later when/if another FUSE implementation
>>becomes available, "somebody" could replace the "fuse" package with
>>whatever is required to get alternatives support for the variants.
>
> BTW, here is another alternative that I have been mulling around.
>
> I can take the current Cygwin package source, place it under a liberal
> license like the BSD and create a separate project out of it. The intent
> of the new project would be to support different FUSE solutions for
> Windows using a *single* package. Currently it only supports WinFsp, but
> it could be modified to support Dokany or other solutions.
>
> There are many benefits to such an approach IMO:
>
> - A single FUSE package and a single cygfuse.dll.
> - Works out of the box with all supported Windows user mode file system
> solutions.
> - No changes in Cygwin’s dependency system or setup.exe required.
> - No user confusion.
>
> The current FUSE package is actually very simple. It looks in the registry
> to see if/where WinFsp is installed and then loads the WinFsp DLL using
> dlopen and the WinFsp-FUSE symbols using dlsym. Presumably the same
> technique could work with Dokany or other solution.
>
> https://github.com/billziss-gh/winfsp/tree/master/opt/cygfuse
>
> To clarify I do not volunteer to maintain such a project. Only to
> kickstart it by contributing the existing package code. I would hope that
> another maintainer emerges, one who is both unaffiliated to the existing
> projects (Dokany, WinFsp, etc.) to ensure fairness and one that has
> Cygwin’s interests in mind.
>
> Let me know.
>
> Bill
>

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.6.0-0.2

2016-07-26 Thread Ken Brown


On 7/26/2016 1:37 PM, Corinna Vinschen wrote:

Now for some testing of the new API...? :)


There seems to be a collation bug.  Here's a test case, extracted from 
the emacs test suite:


$ cat collation_test.c
#include 
#include 
#include 
#include 
#include 

int
main (void)
{
  locale_t loc = newlocale (LC_COLLATE_MASK | LC_CTYPE_MASK,
"en_US.UTF-8", 0);
  if (!loc)
{
  perror ("newlocale");
  exit (1);
}

  wchar_t *p1 = L"xyzzy", *p2 = L"XYZZY";
  errno = 0;
  int res = wcscoll_l (p1, p2, loc);
  if (errno)
{
  perror ("wcscoll_l");
  exit (1);
}
  char res_ch = res < 0 ? '<' : res > 0 ? '>' : '=';
  freelocale (loc);
  printf ("\"%ls\" %c \"%ls\" in locale en_US.UTF-8\n", p1, res_ch, p2);
}

$ gcc collation_test.c

$ ./a
"xyzzy" > "XYZZY" in locale en_US.UTF-8

Ken

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: httpd-2.4.23 notice "No slotmem from mod_heartmonitor"

2016-07-26 Thread Dominic.R.Jones

>> Activating mod_slotmem_shm (as a shared module) resolved this issue and
>> allowed httpd to start.  However, httpd now produces the following notice
>> on (successful) startup:
>> 
>> [Mon Jul 25 09:27:40.718810 2016] [lbmethod_heartbeat:notice] [pid
2345] AH02282: No slotmem from mod_heartmonitor
>> 
>> I'm wondering if there changes to the static modules included in the new
version's package.  The changelog
>> for httpd itself didn't suggest any changes between these two versions
that would cause configuration differences.
>
>I don't know about Apache and these modules, but in order for SHM to be
> avilable, you must run cygserver.

cygserver is running.

After doing some more research, I suspect that the issue may lie in
mod_lbmethod_heartbeat being compiled into httpd while depending on
mod_heartmonitor (apparently to provide slotmem).
mod_heartmonitor is not compiled into the build.  Thus, even if it is enabled
as a shared module, I think that it is loaded after mod_libmethod_heartbeat
and thus is not available when mod_libmethod_heartbeat starts.  If this is the
case, it makes sense that this notice appears.

If this is correct, the solution would appear to be compiling mod_heartmonitor
into the package as a static module.


-

Dominic R. Jones, Ph.D.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ITP] FUSE 2.8

On 7/26/16, 12:02 PM, Mark Geisert wrote:

>Bill Zissimopoulos writes:
>> BTW, here is another alternative that I have been mulling around.
>> 
>[...]
>
>Very interesting.  I'll need a little more time to investigate; github is
>throwing unicorns at the moment.

Yes, I noticed that. I think it is back up.

>If this turns out to be a workable solution, I am willing to be maintainer
>of the glue library Bill is offering.

Excellent! Please let me know.

Bill

Re: [ITP] FUSE 2.8

2016-07-26 Thread Mark Geisert

Bill Zissimopoulos writes:
> BTW, here is another alternative that I have been mulling around.
> 
[...]

Very interesting.  I'll need a little more time to investigate; github is 
throwing unicorns at the moment.

Could the Dokany folks consider whether this kind of wrapping might work 
for them too?  I'm guessing they'll have a different a list of symbols to 
be dlsym'd (unless there's a common API) and possibly a different method 
to determine whether their driver is installed.

If this turns out to be a workable solution, I am willing to be maintainer 
of the glue library Bill is offering.
Thanks,

..mark

--
captcha: durability

Re: [ITP] FUSE 2.8

On 7/25/16, 11:27 PM, Mark Geisert wrote:

>Bill Zissimopoulos writes:
>> - Rename the package to winfsp-fuse, but have it somehow “satisfy”
>> packages that require “fuse” (e.g. SSHFS, FUSEPY). This would allow
>> multiple *-fuse packages to exist in the setup database and the user
>> chooses which one they want. My understanding based on Marco’s answer is
>> that this is not currently supported by Cygwin’s dependency system.
>
>You could define a package "fuse" with no contents and a dependency on
>package "winfsp-fuse".  Then later when/if another FUSE implementation
>becomes available, "somebody" could replace the "fuse" package with
>whatever is required to get alternatives support for the variants.

BTW, here is another alternative that I have been mulling around.

I can take the current Cygwin package source, place it under a liberal
license like the BSD and create a separate project out of it. The intent
of the new project would be to support different FUSE solutions for
Windows using a *single* package. Currently it only supports WinFsp, but
it could be modified to support Dokany or other solutions.

There are many benefits to such an approach IMO:

- A single FUSE package and a single cygfuse.dll.
- Works out of the box with all supported Windows user mode file system
solutions.
- No changes in Cygwin’s dependency system or setup.exe required.
- No user confusion.

The current FUSE package is actually very simple. It looks in the registry
to see if/where WinFsp is installed and then loads the WinFsp DLL using
dlopen and the WinFsp-FUSE symbols using dlsym. Presumably the same
technique could work with Dokany or other solution.

https://github.com/billziss-gh/winfsp/tree/master/opt/cygfuse

To clarify I do not volunteer to maintain such a project. Only to
kickstart it by contributing the existing package code. I would hope that
another maintainer emerges, one who is both unaffiliated to the existing
projects (Dokany, WinFsp, etc.) to ensure fairness and one that has
Cygwin’s interests in mind.

Let me know.

Bill

Re: [ITP] FUSE 2.8

2016-07-26 Thread Mark Geisert

Adrien JUND writes:
> >You could define a package "fuse" with no contents and a dependency 
on
> >package "winfsp-fuse".  Then later when/if another FUSE 
implementation
> >becomes available, "somebody" could replace the "fuse" package with
> >whatever is required to get alternatives support for the variants.

> I have not officially open request now but right after we found a
> solution to handle fuse wrapper packages,
> I will apply for dokan as well as winfsp.
> 
> Also, I think that packages binary dependent to a fuse wrapper would 
not work
> if it is another wrapper that is installed.
> So shall we not just let the package dependent to fuse, explicit the
> wrapper that he will use ?

Erm, I'm belatedly comprehending it's two independent FUSE 
implementations and not two versions with some common history.  OK.  If 
there's a documented binary API at some level of the FUSE definition 
that both implementations provide then that's what the proposed "fuse" 
package could export.  Both implementations would then independently 
supply code that meets the API.  I'm not sure how much extra work this 
means for both projects.

If a common API-level interface is unworkable for whatever reason, then 
we'll just have to live with two independent fuse implementations.  
Tools like sshfs will have to be supplied by both projects and will only 
work with the correct underlying FUSE implementation.

Something alternatives-like would be nice for an end user to switch 
between implementations, but I don't know if that's workable.  Should it 
be possible to have both implementations installed at the same time?

..mark

--
captcha: homely

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.6.0-0.2

On Jul 26 11:09, Jim Reisert AD1C wrote:
> I can also confirm the xdg menu problems are fixed.  Thanks!

Good news from both of you.

Now for some testing of the new API...? :)


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: problem building with cmake under cygwin (need clang)


On 26/07/2016 18:52, LMH wrote:

Marco Atzeri wrote:

On 26/07/2016 17:10, LMH wrote:




-- The C compiler identification is GNU 4.9.3


the current C Gnu compiler is 5.4.0
so you have not the latest setup

-- Check for working CXX compiler: /usr/bin/clang -- broken

CMake Error at
/usr/share/cmake-3.3.2/Modules/CMakeTestCXXCompiler.cmake:54 (message):
  The C++ compiler "/usr/bin/clang" is not able to compile a simple test
  program.



and I guess not the last clang... at it was not recognized at all.

Please upgrade cygwin packages and eventually we can discuss again.

A copy of cygcheck.out after the upgrade will be appreciated
see   https://cygwin.com/problems.html


Regards
Marco



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.6.0-0.2

2016-07-26 Thread Jim Reisert AD1C

I can also confirm the xdg menu problems are fixed.  Thanks!

-- 
Jim Reisert AD1C, , http://www.ad1c.us

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: problem building with cmake under cygwin (need clang)

2016-07-26 Thread LMH


Marco Atzeri wrote:

On 26/07/2016 17:10, LMH wrote:

Csaba Raduly wrote:




Steps for building in a separate build directory:

mkdir _build
cd_build
cmake ..

Csaba



I looked for the syntax for this when I first started. I assumed the the
author put the CMakeLists.txt file in the right place. I almost never
have my make file in the src directory when using gnu make, so this
looked the same to me. I didn't find any doc about how to have the
CMakeLists.txt and the src in different directories.



Csaba was clear but it seems you are misunderstanding,
the call to cmake is

cmake [options] 

so I will put together his suggestion and Tony's one:

$ git pull https://bitbucket.org/tomilov/quickhull/src
$ ls src/
CMakeLists.txt  include  README.md  src  test
$ mkdir build
$ cd build
$ cmake -DCMAKE_CXX_COMPILER=clang  ../src

the "build" directory is in this case parallel to the "src" one.

Unfortunately it will fail on "Compiler does not support C++1z standard"
and you will need to modify the original CMakeLists.txt.
I cut
---
-CHECK_CXX_COMPILER_FLAG("-std=gnu++1z" COMPILER_SUPPORTS_CXX1Z)
-if(NOT COMPILER_SUPPORTS_CXX1Z)
-message(FATAL_ERROR "Compiler does not support C++1z standard")
-endif()
-add_compile_options("-std=gnu++1z")
---

But there are other issues on the road; I passed some with

cmake -DCMAKE_CXX_COMPILER=clang -DCMAKE_CXX_FLAGS="-std=gnu++1z
-I/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/include/c++/
-I/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/include/c++/x86_64-pc-cygwin/" ../src

but the build stop here
--
/pub/temp/src/src/simple_use.cpp:146:16: fatal error: no member named 'chrono' 
in
namespace 'std'
 using std::chrono::duration_cast;
   ~^
15 warnings and 1 error generated.
make[2]: *** [CMakeFiles/qh.dir/build.make:66:
CMakeFiles/qh.dir/src/simple_use.cpp.o] Error 1
---

and I am out of my C++ knowledge

Regards
Marco

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple




Thanks you for the clarification.

I implemented your steps,

$ ls src/
CMakeLists.txt  include  README.md  src  test

$ mkdir build

$ cd build/

$ cmake -DCMAKE_CXX_COMPILER=clang  ../src

I get the following output, which is the same error output I was getting before. It 
is different then the errors you are specifying.


-- The C compiler identification is GNU 4.9.3
-- The CXX compiler identification is unknown
CMake Warning at /usr/share/cmake-3.3.2/Modules/Platform/CYGWIN.cmake:15 
(message):
  CMake no longer defines WIN32 on Cygwin!

  (1) If you are just trying to build this project, ignore this warning or
  quiet it by setting CMAKE_LEGACY_CYGWIN_WIN32=0 in your environment or in
  the CMake cache.  If later configuration or build errors occur then this
  project may have been written under the assumption that Cygwin is WIN32.
  In that case, set CMAKE_LEGACY_CYGWIN_WIN32=1 instead.

  (2) If you are developing this project, add the line

set(CMAKE_LEGACY_CYGWIN_WIN32 0) # Remove when CMake >= 2.8.4 is required

  at the top of your top-level CMakeLists.txt file or set the minimum
  required version of CMake to 2.8.4 or higher.  Then teach your project to
  build on Cygwin without WIN32.
Call Stack (most recent call first):
  /usr/share/cmake-3.3.2/Modules/CMakeSystemSpecificInformation.cmake:36 
(include)
  CMakeLists.txt:1 (project)


-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/clang
-- Check for working CXX compiler: /usr/bin/clang -- broken
CMake Error at /usr/share/cmake-3.3.2/Modules/CMakeTestCXXCompiler.cmake:54 
(message):
  The C++ compiler "/usr/bin/clang" is not able to compile a simple test
  program.

  It fails with the following output:

   Change Dir: 
/cygdrive/g/shared_data/SMD/ATomilov_quickhull/build/CMakeFiles/CMakeTmp

  Run Build Command:"/usr/bin/make.exe" "cmTC_e1f3f/fast"

  /usr/bin/make -f CMakeFiles/cmTC_e1f3f.dir/build.make
  CMakeFiles/cmTC_e1f3f.dir/build

  make[1]: Entering directory
  '/cygdrive/g/shared_data/SMD/ATomilov_quickhull/build/CMakeFiles/CMakeTmp'

  Building CXX object CMakeFiles/cmTC_e1f3f.dir/testCXXCompiler.cxx.o

  /usr/bin/clang -o CMakeFiles/cmTC_e1f3f.dir/testCXXCompiler.cxx.o -c

/cygdrive/g/shared_data/SMD/ATomilov_quickhull/build/CMakeFiles/CMakeTmp/testCXXCompiler.cxx


  CMakeFiles/cmTC_e1f3f.dir/build.make:65: recipe for target

Re: problem building with cmake under cygwin (need clang)


On 26/07/2016 17:10, LMH wrote:

Csaba Raduly wrote:




Steps for building in a separate build directory:

mkdir _build
cd_build
cmake ..

Csaba



I looked for the syntax for this when I first started. I assumed the the
author put the CMakeLists.txt file in the right place. I almost never
have my make file in the src directory when using gnu make, so this
looked the same to me. I didn't find any doc about how to have the
CMakeLists.txt and the src in different directories.



Csaba was clear but it seems you are misunderstanding,
the call to cmake is

   cmake [options] 

so I will put together his suggestion and Tony's one:

$ git pull https://bitbucket.org/tomilov/quickhull/src
$ ls src/
CMakeLists.txt  include  README.md  src  test
$ mkdir build
$ cd build
$ cmake -DCMAKE_CXX_COMPILER=clang  ../src

the "build" directory is in this case parallel to the "src" one.

Unfortunately it will fail on "Compiler does not support C++1z standard"
and you will need to modify the original CMakeLists.txt.
I cut
---
-CHECK_CXX_COMPILER_FLAG("-std=gnu++1z" COMPILER_SUPPORTS_CXX1Z)
-if(NOT COMPILER_SUPPORTS_CXX1Z)
-message(FATAL_ERROR "Compiler does not support C++1z standard")
-endif()
-add_compile_options("-std=gnu++1z")
---

But there are other issues on the road; I passed some with

cmake -DCMAKE_CXX_COMPILER=clang -DCMAKE_CXX_FLAGS="-std=gnu++1z 
-I/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/include/c++/ 
-I/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/include/c++/x86_64-pc-cygwin/" ../src


but the build stop here
--
/pub/temp/src/src/simple_use.cpp:146:16: fatal error: no member named 
'chrono' in namespace 'std'

using std::chrono::duration_cast;
  ~^
15 warnings and 1 error generated.
make[2]: *** [CMakeFiles/qh.dir/build.make:66: 
CMakeFiles/qh.dir/src/simple_use.cpp.o] Error 1

---

and I am out of my C++ knowledge

Regards
Marco

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: httpd-2.4.23 notice "No slotmem from mod_heartmonitor"

2016-07-26 Thread Achim Gratz

  faa.gov> writes:
> Activating mod_slotmem_shm (as a shared module) resolved this issue and
allowed httpd to start.  However,
> httpd now produces the following notice on (successful) startup:
> 
> [Mon Jul 25 09:27:40.718810 2016] [lbmethod_heartbeat:notice] [pid
2345] AH02282: No slotmem from mod_heartmonitor
> 
> I'm wondering if there changes to the static modules included in the new
version's package.  The changelog
> for httpd itself didn't suggest any changes between these two versions
that would cause configuration differences.

I don't know about Apache and these modules, but in order for SHM to be
avilable, you must run cygserver.


Regards,
Achim.





--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.6.0-0.2

2016-07-26 Thread Ken Brown


On 7/26/2016 10:00 AM, Corinna Vinschen wrote:

Hi Cygwin developers and maintainers,
Hi everyone else,


I uploaded a new Cygwin test release 2.6.0-0.2.

Supposed to fix the problems reported in
https://cygwin.com/ml/cygwin/2016-07/msg00274.html and followups.


Confirmed.

Thanks.

Ken


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: problem building with cmake under cygwin (need clang)

2016-07-26 Thread LMH


Tony Kelman wrote:

LMH  molconn.com> writes:


It looks like I need to point CMAKE_CXX_COMPILER_ID to clang, but I am not

sure how

to do that. I don't know if the problem is with the CMakeLists.txt file,

the way I am

calling cmake, or with my local cygwin configuration.



Are you setting -DCMAKE_CXX_COMPILER=clang ?


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple




I tried a few things like,
cmake -DCMAKE_CXX_COMPILER=/usr/bin/clang++ ./src


That gets me a different set of errors,


CMake Error at /usr/share/cmake-3.3.2/Modules/CMakeTestCXXCompiler.cmake:54 
(message):
  The C++ compiler "/usr/bin/clang++" is not able to compile a simple test
  program.

  It fails with the following output:

   Change Dir: 
/cygdrive/g/shared_data/SMD/ATomilov_quickhull/tomilov-quickhull-7faf277d6cc2_cmake/CMakeFiles/CMakeTmp



  Run Build Command:"/usr/bin/make.exe" "cmTC_35956/fast"

  /usr/bin/make -f CMakeFiles/cmTC_35956.dir/build.make
  CMakeFiles/cmTC_35956.dir/build

  make[1]: Entering directory

'/cygdrive/g/shared_data/SMD/ATomilov_quickhull/tomilov-quickhull-7faf277d6cc2_cmake/CMakeFiles/CMakeTmp'


  Building CXX object CMakeFiles/cmTC_35956.dir/testCXXCompiler.cxx.o

  /usr/bin/clang++ -o CMakeFiles/cmTC_35956.dir/testCXXCompiler.cxx.o -c

/cygdrive/g/shared_data/SMD/ATomilov_quickhull/tomilov-quickhull-7faf277d6cc2_cmake/CMakeFiles/CMakeTmp/testCXXCompiler.cxx


  CMakeFiles/cmTC_35956.dir/build.make:65: recipe for target
  'CMakeFiles/cmTC_35956.dir/testCXXCompiler.cxx.o' failed

  make[1]: Leaving directory

'/cygdrive/g/shared_data/SMD/ATomilov_quickhull/tomilov-quickhull-7faf277d6cc2_cmake/CMakeFiles/CMakeTmp'


  Makefile:126: recipe for target 'cmTC_35956/fast' failed

  make[1]: *** [CMakeFiles/cmTC_35956.dir/testCXXCompiler.cxx.o] Error 127

  make: *** [cmTC_35956/fast] Error 2


  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:1 (project)


This is odd that it can't seem to build a test program. Csaba suggests that I should 
have left the CMakeLists.txt file outside of the src directory, but I haven't figured 
out how to run cmake like that yet. I'm not sure that has anything to do with the 
test build failure, so I suspect that there is still some local config problem going on.


Marco suggests some problems with the CMakeLists.txt, so I'm not sure which to try to 
run down first.


LMH






--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: Older versions of Cygwin setup.exe

2016-07-26 Thread Secure Hell

Hi Peter,

I would take any and all past versions of the setup.exe, setup-x86.exe and
setup-x86_64.exe binary that you have regardless of version. Ideally, I wish
there was a history log somewhere which included the file hash (e.g. MD5,
SHA1) of the installer and the version/platform but I will accept hashes or
actual binaries.

Any help would be appreciated. Feel free to ping me offlist
.

Thanks.

-Original Message-
From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of
Peter A. Castro
Sent: Thursday, July 14, 2016 2:55 PM
To: Cygwin List 
Subject: Re: Older versions of Cygwin setup.exe

On Thu, 14 Jul 2016, Marco Atzeri wrote:

> Date: Thu, 14 Jul 2016 18:13:47 +0200
> From: Marco Atzeri 
> To: cygwin@cygwin.com
> Subject: Re: Older versions of Cygwin setup.exe
> 
> On 14/07/2016 17:09, Secure Hell wrote:
>> Are older versions of the setup.exe, setup-x86.exe, setup-x86_64.exe 
>> available for download anywhere? It's really the installer I'm after 
>> and not the actual packages those installers install.
>> 
>> I would settle for a hash list if that exists (i.e. MD5, SHA1 and/or 
>> SHA256).
>> 
>> Any help appreciated. Thanks.
>> 
> http://www.fruitbat.org/Cygwin/#cygwinlegacy1.5

Just to chime in on this (which is OT for the list, I believe, but...) I do
collect a smattering of setup versions overtime, but not all.

There's an assumption that newer versions of Setup can largely handle
installing older releases (up to a point, I'll grant).

That may not necessarily be true in the future, which is why I do collect
snapshots of setup in case someone finds the latest doesn't work for them.

Still, as Cygwin and Setup have evolved over time, I do try and ensure older
Setup is available just in case.

If there's a specific version of Setup the OP is looking for, I can check my
archives to see if I have it, or something near it.

--
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
"Cats are just autistic Dogs" -- Dr. Tony Attwood

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: problem building with cmake under cygwin (need clang)

2016-07-26 Thread LMH


Csaba Raduly wrote:

On Tue, Jul 26, 2016 at 2:45 AM, LMH  wrote:

Hello,

I am trying to compute the convex hull of a high dimensional space (46D x
2000 rows). The qhull app available in cygwin/math is based on relatively
old code and runs out of memory.

I found another version the is supposed to be able to do higher dimensions.

https://bitbucket.org/tomilov/quickhull/src

This version is set up to build with cmake, so I installed cmake in cygwin
and ran it as,

cmake ./src

Note, I had to copy CMakeLists.txt into the src directory to get this to
work. If I don't do that, I get the error,


That usually won't work. Instead of copying CMakeLists.txt to the src
directory, you should specify the directory where CMakeLists.txt is
located when invoking CMake.

Steps for building in a separate build directory:

mkdir _build
cd_build
cmake ..

Csaba



I looked for the syntax for this when I first started. I assumed the the author put 
the CMakeLists.txt file in the right place. I almost never have my make file in the 
src directory when using gnu make, so this looked the same to me. I didn't find any 
doc about how to have the CMakeLists.txt and the src in different directories.


The structure of the downloaded archive looked like,
/tomilov-quickhull-7faf277d6cc2
 /include/quickhull.hpp
 /src/quickhull.cpp
 /src/randombox.cpp
 /src/simple_use.cpp
 /test/...test files
 .gitignore
 CMakeLists.txt
 README.md

I did,

cd ./tomilov-quickhull-7faf277d6cc2
cmake ./src

this is when I got the error message about no CMakeLists.txt file in /src.

What is the syntax for running cmake in

/tomilov-quickhull-7faf277d6cc2

with the CMakeLists.txt file at

/tomilov-quickhull-7faf277d6cc2/CMakeLists.txt

and the src files in

/tomilov-quickhull-7faf277d6cc2/src

?

Is this something you do with the --build flag? It looks like you can use that to 
specify where the project will be built but I don't see anything there about the 
location of the src files.


Thanks,

LMH

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: System tray menu tuning & Xwin0.log in mintty console with startx

On 25/07/2016 22:14, pigreco erre wrote:

Hello Marco,
Excuse me but I don't specify before that I try to use Cygwin-Portable version
that I find on the web.

This explain why the menu was talking german
http://www.cybesystems.com/index.php?option=com_jdownloads=download=6:cygwinportable-1-0-paf=2=101

But you should rise the issues with the author.

Here we only support the full version
https://www.cygwin.com/

I put it in my pendrive. I use in various exam the program VIM EMACS & GCC so
to have a them in portable cyg version is very confortable.
Sorry if I forgot to add this information :-(
However, I have essentially only one problem:
when I run "startx" on mintty bash environment I see on the screen like a
splash log file directly. Why?
What can I erase the echoin on the screen when it execs the script "startx?"
I don't reach to put off the stdout on the screen when I call "startx".

Don't start the X server from mintty or open more than one
Mintty windows.

Could I solve this?
(take into account that there is a difference with startxwin.
When I run "startxwin",It starts without echo-splash on the screen the X-server
message).
With reference to the other question, I solve it.
Thank you again
Alessandro

My solution on USB disk is a link in the Cygwin root dir
with "Target"

E:\cygwin64\bin\run.exe --quote /usr/bin/bash.exe -l -c "cd; exec
/usr/bin/startxwin"

and with "Start in"

E:\cygwin64\bin

Regards
Marco

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.6.0-0.1

On Jul 26 09:13, Corinna Vinschen wrote:
> On Jul 25 15:05, Jim Reisert AD1C wrote:
> > On Mon, Jul 25, 2016 at 1:49 PM, Ken Brown wrote:
> > 
> > > I'm also unable to start xterm from the xwin-xdg-menu (under System 
> > > Tools).
> > > Nothing happens when I click on XTerm, and I see the following error
> > > message:
> > >
> > > $ cat .xsession-errors
> > > executing 'xterm', pid 9928
> > > (pid 9928 stderr) execl failed: No such file or directory
> > > pid 9928 exited with status 127
> > 
> > Same here.  "Cygwin Terminal" won't launch from xdg either, but I can
> > start a stand-alone Cygwin Terminal from *outside* of xdg.
> > 
> > /etc/X11/xinit/startxwinrc: line 32: [: too many arguments
> > /etc/X11/xinit/xinitrc-common: line 20: [: too many arguments
> > Excessive file argument "Sync/Home/.Xresources"
> > 1 error in preprocessor.
> > Can't create dir /cygdrive/c/Users/reisert/Desktop/Box Sync/Box
> > Sync/Home/Desktop
> > Can't create dir /cygdrive/c/Users/reisert/Desktop/Box Sync/Box
> > Sync/Home/Downloads
> > Can't create dir /cygdrive/c/Users/reisert/Desktop/Box Sync/Box
> > Sync/Home/Templates
> > Can't create dir /cygdrive/c/Users/reisert/Desktop/Box Sync/Box 
> > Sync/Home/Public
> > Can't create dir /cygdrive/c/Users/reisert/Desktop/Box Sync/Box
> > Sync/Home/Documents
> > Can't create dir /cygdrive/c/Users/reisert/Desktop/Box Sync/Box 
> > Sync/Home/Music
> > Can't create dir /cygdrive/c/Users/reisert/Desktop/Box Sync/Box
> > Sync/Home/Pictures
> > Can't create dir /cygdrive/c/Users/reisert/Desktop/Box Sync/Box 
> > Sync/Home/Videos
> > executing 'xterm', pid 4560
> > (pid 4560 stderr) execl failed: No such file or directory
> > pid 4560 exited with status 127
> 
> Checking now myself, thanks for the report.  It would be
> *incredibly* helpful to find a simpler testcase, though.

Hopefully fixed in 2.6.0-0.2 which I just uploaded and announced.

This one has a chance for "dumb bug of the year"...


Thanks again for your reports,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.6.0-0.2

Hi Cygwin developers and maintainers,
Hi everyone else,


I uploaded a new Cygwin test release 2.6.0-0.2.

Supposed to fix the problems reported in
https://cygwin.com/ml/cygwin/2016-07/msg00274.html and followups.

===

For those building Cygwin from source, the new code is only available
in the topic/locales branch yet.

===

The 2.6.0 release is going to introducing the locale_t datatype, as well
as all functions related to locale_t locales and per-thread locales per
POSIX-1.2008.

So, rather than just providing a single, per-process locale, you can now
create new locales ("newlocale") and set it as locale for the current
thread ("uselocale") or use it directly with one of the new functions
taking a locale_t as parameter (i.e. isalpha_l).

The full list of new interfaces is:

  newlocale, freelocale, duplocale, uselocale

  isalnum_l, isalpha_l, isascii_l, isblank_l, iscntrl_l, isdigit_l,
  isgraph_l, islower_l, isprint_l, ispunct_l, isspace_l, isupper_l,
  iswalnum_l, iswalpha_l, iswblank_l, iswcntrl_l, iswctype_l,
  iswdigit_l, iswgraph_l, iswlower_l, iswprint_l, iswpunct_l,
  iswspace_l, iswupper_l, iswxdigit_l, isxdigit_l
  
  toascii_l, tolower_l, toupper_l, towctrans_l, towlower_l, towupper_l,
  wctrans_l, wctype_l

  strcasecmp_l, strcoll_l, strncasecmp_l, strxfrm_l

  wcscasecmp_l, wcscoll_l, wcstrncasecmp_l, wcstrxfrm_l

  strfmon_l, strftime_l

===

Since this is brand-new code, this code *will* have bugs.

It would be very helpful if interested developers and Cygwin package
maintainers could give this new stuff some good testing.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

TEST RELEASE: Cygwin 2.6.0-0.2

Hi Cygwin developers and maintainers,
Hi everyone else,


I uploaded a new Cygwin test release 2.6.0-0.2.

Supposed to fix the problems reported in
https://cygwin.com/ml/cygwin/2016-07/msg00274.html and followups.

===

For those building Cygwin from source, the new code is only available
in the topic/locales branch yet.

===

The 2.6.0 release is going to introducing the locale_t datatype, as well
as all functions related to locale_t locales and per-thread locales per
POSIX-1.2008.

So, rather than just providing a single, per-process locale, you can now
create new locales ("newlocale") and set it as locale for the current
thread ("uselocale") or use it directly with one of the new functions
taking a locale_t as parameter (i.e. isalpha_l).

The full list of new interfaces is:

  newlocale, freelocale, duplocale, uselocale

  isalnum_l, isalpha_l, isascii_l, isblank_l, iscntrl_l, isdigit_l,
  isgraph_l, islower_l, isprint_l, ispunct_l, isspace_l, isupper_l,
  iswalnum_l, iswalpha_l, iswblank_l, iswcntrl_l, iswctype_l,
  iswdigit_l, iswgraph_l, iswlower_l, iswprint_l, iswpunct_l,
  iswspace_l, iswupper_l, iswxdigit_l, isxdigit_l
  
  toascii_l, tolower_l, toupper_l, towctrans_l, towlower_l, towupper_l,
  wctrans_l, wctype_l

  strcasecmp_l, strcoll_l, strncasecmp_l, strxfrm_l

  wcscasecmp_l, wcscoll_l, wcstrncasecmp_l, wcstrxfrm_l

  strfmon_l, strftime_l

===

Since this is brand-new code, this code *will* have bugs.

It would be very helpful if interested developers and Cygwin package
maintainers could give this new stuff some good testing.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

Re: [ITP] FUSE 2.8

2016-07-26 Thread Adrien JUND

>You could define a package "fuse" with no contents and a dependency on
>package "winfsp-fuse".  Then later when/if another FUSE implementation
>becomes available, "somebody" could replace the "fuse" package with
>whatever is required to get alternatives support for the variants.
I have not officially open request now but right after we found a
solution to handle fuse wrapper packages,
I will apply for dokan as well as winfsp.

Also, I think that packages binary dependent to a fuse wrapper would not work
if it is another wrapper that is installed.
So shall we not just let the package dependent to fuse, explicit the
wrapper that he will use ?

2016-07-26 10:45 GMT+02:00 Herbert Stocker :
> Hi all,
>
> On 7/26/2016 8:27 AM, Mark Geisert wrote:
>>
>> You could define a package "fuse" with no contents and a dependency on
>> package "winfsp-fuse".  Then later when/if another FUSE implementation
>> becomes available, "somebody" could replace the "fuse" package with
>> whatever is required to get alternatives support for the variants.
>
>
> Does setup.exe already have a provision in the GUI to ask the user
> which one they want to chose if two or more packages are able to
> provide the (empty) fuse package?
>
>> I'm wondering if "fuse-" is a better name template than "-fuse" in
>> order to keep the variants near each other in setup.exe's displays.
>
>
> good point.
>
>
> Herbert Stocker

Re: Midnight Commander is very slow when starting and changing directories


On 26/07/2016 11:39, Krzysztof Bociurko wrote:

Tried to list all drive letters (with help of
http://serverfault.com/questions/62578/how-to-get-a-list-of-drive-letters-on-a-system-through-a-windows-shell-bat-cmd)
and:

PS C:\Users\chanibal> wmic logicaldisk get
caption,providername,drivetype,volumename
Caption  DriveType  ProviderName  VolumeName
C:   3SSD
D:  3HDD
E:   5   < this is a DVD drive not
used for months (years?)

And it took close to the 4 seconds - similar to the issue I am experiencing:

PS C:\Users\chanibal> Measure-Command { wmic logicaldisk get
caption,providername,drivetype,volumename }
(...)
TotalSeconds  : 5,0886857
(...)

Disabling the DVD drive with Device Manager changed the above time to
0.063s, changed `ls /cygdrive` time to 0.015s and Midnight Commander
STARTED FINALLY WORKING IN REAL TIME. Thank you!


All right, now the question is WHY did this fail - I think it might be
considered Cygwin bug material, almost none windows app has failed
this way (with the exception of this windows mc build).



If both version of MC are stacked as also wmic, it is because all
asked the same thing to windows and it took 4 seconds
to receive and answer.

Not cygwin bug. Eventually of your DVD driver.

My DVD D: takes no time

 $ time /cygdrive/c/windows/System32/wbem/WMIC.exe logicaldisk get 
caption,providername,drivetype,volumename

Caption  DriveType  ProviderName  VolumeName
C:   3
D:   5
E:   3HD-Atzeri3

real0m0.156s
user0m0.015s
sys 0m0.062s





--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Midnight Commander is very slow when starting and changing directories

2016-07-26 Thread Krzysztof Bociurko

Tried to list all drive letters (with help of
http://serverfault.com/questions/62578/how-to-get-a-list-of-drive-letters-on-a-system-through-a-windows-shell-bat-cmd)
and:

PS C:\Users\chanibal> wmic logicaldisk get
caption,providername,drivetype,volumename
Caption  DriveType  ProviderName  VolumeName
C:   3SSD
D:  3HDD
E:   5   < this is a DVD drive not
used for months (years?)

And it took close to the 4 seconds - similar to the issue I am experiencing:

PS C:\Users\chanibal> Measure-Command { wmic logicaldisk get
caption,providername,drivetype,volumename }
(...)
TotalSeconds  : 5,0886857
(...)

Disabling the DVD drive with Device Manager changed the above time to
0.063s, changed `ls /cygdrive` time to 0.015s and Midnight Commander
STARTED FINALLY WORKING IN REAL TIME. Thank you!


All right, now the question is WHY did this fail - I think it might be
considered Cygwin bug material, almost none windows app has failed
this way (with the exception of this windows mc build).



2016-07-26 8:55 GMT+02:00 David Macek :
> On 25. 7. 2016 17:34, Krzysztof Bociurko wrote:
>> I have found this issue in a new incarnation - and this time it is NOT
>> with midnight commander but basic gnu utils.
>> Again it's the 4 seconds lost.
>>
>> $ time ls /cygdrive/
>> c  d
>>
>> real0m4.065s
>> user0m0.000s
>> sys 0m0.015s
>>
>> `ls /cygdrive/c` or `ls /cygdrive/d` take around 0.013s.
>
> Is it possible there's another -- unavailable -- drive letter, and the driver 
> needs to wait 4 seconds before declaring it unavailable/disconnected?
>
> --
> David Macek
>



-- 
Krzysztof Bociurko

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: problem building with cmake under cygwin (need clang)


On 26/07/2016 09:47, Csaba Raduly wrote:

On Tue, Jul 26, 2016 at 8:16 AM, Marco Atzeri  wrote:



 CMake Error at CMakeLists.txt:22 (message):
   Compiler does not support C++1z standard

if you look on CMakeLists.txt you will find is expecting a flag
as "-std=gnu++1z"  that looks a bit strange for a not gnu compiler


Clang implements many of GCC's extensions. -std=gnu++1something means
"C++ 1something with GNU extensions". Clang understands that just
fine.

Csaba



may be, but it seems not so in this case

-- Performing Test COMPILER_SUPPORTS_CXX1Z - Failed
CMake Error at CMakeLists.txt:22 (message):
  Compiler does not support C++1z standard

I am skeptical of all this portion
-
CHECK_CXX_COMPILER_FLAG("-stdlib=libc++" COMPILER_SUPPORTS_LIBCXX)
if(NOT COMPILER_SUPPORTS_LIBCXX)
message(FATAL_ERROR "libc++ not installed or libc++ not supported 
by clang++")

endif()
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++")

CHECK_CXX_COMPILER_FLAG("-std=gnu++1z" COMPILER_SUPPORTS_CXX1Z)
if(NOT COMPILER_SUPPORTS_CXX1Z)
message(FATAL_ERROR "Compiler does not support C++1z standard")
endif()
add_compile_options("-std=gnu++1z")
--

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ITP] FUSE 2.8

2016-07-26 Thread Herbert Stocker


Hi all,

On 7/26/2016 8:27 AM, Mark Geisert wrote:

You could define a package "fuse" with no contents and a dependency on
package "winfsp-fuse".  Then later when/if another FUSE implementation
becomes available, "somebody" could replace the "fuse" package with
whatever is required to get alternatives support for the variants.


Does setup.exe already have a provision in the GUI to ask the user
which one they want to chose if two or more packages are able to
provide the (empty) fuse package?


I'm wondering if "fuse-" is a better name template than "-fuse" in
order to keep the variants near each other in setup.exe's displays.


good point.


Herbert Stocker

Re: problem building with cmake under cygwin (need clang)

2016-07-26 Thread Csaba Raduly

On Tue, Jul 26, 2016 at 2:45 AM, LMH  wrote:
> Hello,
>
> I am trying to compute the convex hull of a high dimensional space (46D x
> 2000 rows). The qhull app available in cygwin/math is based on relatively
> old code and runs out of memory.
>
> I found another version the is supposed to be able to do higher dimensions.
>
> https://bitbucket.org/tomilov/quickhull/src
>
> This version is set up to build with cmake, so I installed cmake in cygwin
> and ran it as,
>
> cmake ./src
>
> Note, I had to copy CMakeLists.txt into the src directory to get this to
> work. If I don't do that, I get the error,

That usually won't work. Instead of copying CMakeLists.txt to the src
directory, you should specify the directory where CMakeLists.txt is
located when invoking CMake.

Steps for building in a separate build directory:

mkdir _build
cd_build
cmake ..

Csaba
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: problem building with cmake under cygwin (need clang)

2016-07-26 Thread Csaba Raduly

On Tue, Jul 26, 2016 at 8:16 AM, Marco Atzeri  wrote:
>
> On 26/07/2016 02:45, LMH wrote:
>>
>> Hello,
>>
>> I am trying to compute the convex hull of a high dimensional space (46D
>> x 2000 rows). The qhull app available in cygwin/math is based on
>> relatively old code and runs out of memory.
>>
>> I found another version the is supposed to be able to do higher
>> dimensions.
>>
>> https://bitbucket.org/tomilov/quickhull/src
>>
>> This version is set up to build with cmake, so I installed cmake in
>> cygwin and ran it as,
>>
>> cmake ./src
>>
>> Note, I had to copy CMakeLists.txt into the src directory to get this to
>> work. If I don't do that, I get the error,
>>
>> CMake Error: The source directory
>>
>> "/cygdrive/g/shared_data/SMD/ATomilov_quickhull/tomilov-quickhull-7faf277d6cc2_cmake/src"
>> does not appear to contain CMakeLists.txt.
>>
>> When I have copied the CMakeLists.txt file into ./src, cmake runs but I
>> get the error,
>>
>> CMake Error at CMakeLists.txt:11 (message):
>>   only clang supported currently
>>
>> this comes from the conditional,
>>
>> if(NOT "${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang")
>> message(FATAL_ERROR "only clang supported currently")
>> endif()
>>
>> in CMakeLists.txt.
>>
>> I have installed clang from cygwin, but I still get the same error. I
>> added the following line to CMakeLists.txt,
>>
>> message(STATUS "${CMAKE_CXX_COMPILER_ID}")
>>
>> and I get "GNU" as the value for CMAKE_CXX_COMPILER_ID, at least that is
>> the value if I got the syntax correct for the message statement.
>>
>> It looks like I need to point CMAKE_CXX_COMPILER_ID to clang, but I am
>> not sure how to do that. I don't know if the problem is with the
>> CMakeLists.txt file, the way I am calling cmake, or with my local cygwin
>> configuration.
>>
>> Suggestions would be appreciated.
>>
>> LMH
>>
>>
>
>
> the build system of quickhull has some serious problem.
>
> set
>
> CMAKE_CXX_COMPILER   /usr/bin/clang-3.8.exe
> CMAKE_C_COMPILER /usr/bin/clang-3.8.exe
>
> after you will hit
>
>  CMake Error at CMakeLists.txt:22 (message):
>Compiler does not support C++1z standard
>
> if you look on CMakeLists.txt you will find is expecting a flag
> as "-std=gnu++1z"  that looks a bit strange for a not gnu compiler

Clang implements many of GCC's extensions. -std=gnu++1something means
"C++ 1something with GNU extensions". Clang understands that just
fine.

Csaba
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.6.0-0.1

On Jul 25 15:05, Jim Reisert AD1C wrote:
> On Mon, Jul 25, 2016 at 1:49 PM, Ken Brown wrote:
> 
> > I'm also unable to start xterm from the xwin-xdg-menu (under System Tools).
> > Nothing happens when I click on XTerm, and I see the following error
> > message:
> >
> > $ cat .xsession-errors
> > executing 'xterm', pid 9928
> > (pid 9928 stderr) execl failed: No such file or directory
> > pid 9928 exited with status 127
> 
> Same here.  "Cygwin Terminal" won't launch from xdg either, but I can
> start a stand-alone Cygwin Terminal from *outside* of xdg.
> 
> /etc/X11/xinit/startxwinrc: line 32: [: too many arguments
> /etc/X11/xinit/xinitrc-common: line 20: [: too many arguments
> Excessive file argument "Sync/Home/.Xresources"
> 1 error in preprocessor.
> Can't create dir /cygdrive/c/Users/reisert/Desktop/Box Sync/Box
> Sync/Home/Desktop
> Can't create dir /cygdrive/c/Users/reisert/Desktop/Box Sync/Box
> Sync/Home/Downloads
> Can't create dir /cygdrive/c/Users/reisert/Desktop/Box Sync/Box
> Sync/Home/Templates
> Can't create dir /cygdrive/c/Users/reisert/Desktop/Box Sync/Box 
> Sync/Home/Public
> Can't create dir /cygdrive/c/Users/reisert/Desktop/Box Sync/Box
> Sync/Home/Documents
> Can't create dir /cygdrive/c/Users/reisert/Desktop/Box Sync/Box 
> Sync/Home/Music
> Can't create dir /cygdrive/c/Users/reisert/Desktop/Box Sync/Box
> Sync/Home/Pictures
> Can't create dir /cygdrive/c/Users/reisert/Desktop/Box Sync/Box 
> Sync/Home/Videos
> executing 'xterm', pid 4560
> (pid 4560 stderr) execl failed: No such file or directory
> pid 4560 exited with status 127

Checking now myself, thanks for the report.  It would be
*incredibly* helpful to find a simpler testcase, though.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: Midnight Commander is very slow when starting and changing directories

2016-07-26 Thread David Macek

On 25. 7. 2016 17:34, Krzysztof Bociurko wrote:
> I have found this issue in a new incarnation - and this time it is NOT
> with midnight commander but basic gnu utils.
> Again it's the 4 seconds lost.
> 
> $ time ls /cygdrive/
> c  d
> 
> real0m4.065s
> user0m0.000s
> sys 0m0.015s
> 
> `ls /cygdrive/c` or `ls /cygdrive/d` take around 0.013s.

Is it possible there's another -- unavailable -- drive letter, and the driver 
needs to wait 4 seconds before declaring it unavailable/disconnected?

--
David Macek



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [ITP] FUSE 2.8

2016-07-26 Thread Mark Geisert

Bill Zissimopoulos writes:
> - Rename the package to winfsp-fuse, but have it somehow “satisfy”
> packages that require “fuse” (e.g. SSHFS, FUSEPY). This would allow
> multiple *-fuse packages to exist in the setup database and the user
> chooses which one they want. My understanding based on Marco’s answer is
> that this is not currently supported by Cygwin’s dependency system.

You could define a package "fuse" with no contents and a dependency on 
package "winfsp-fuse".  Then later when/if another FUSE implementation 
becomes available, "somebody" could replace the "fuse" package with 
whatever is required to get alternatives support for the variants.

I'm wondering if "fuse-" is a better name template than "-fuse" in 
order to keep the variants near each other in setup.exe's displays.

..mark

Re: problem building with cmake under cygwin (need clang)