now [3].
ii) Would it be convenient for you to update also the "mingw"
package(s) from current version 4.8.3 to more recent 4.9.2 the same
way you have done it for "gcc"?
Kind regards,
Vasiliy
[1] https://www.cygwin.com/ml/cygwin-announce/2015-02/msg8.html
"U
I'm happy to provide you with an update on 'extra operand --test-name'
occasionally being fed to 'basename' by some testsuites, which was
fixed by Automake maintainers:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14840
On Fri, Jul 12, 2013 at 11:19 PM, Vasiliy w
>
>> On Fri, Jul 12, 2013 at 09:21:40PM +0200, Vasiliy wrote:
>> Marco, you're right, it's the problem in their 'run_tests' file, I've
>> got baffled due to a lack of time. However, there's likely an issue
>> with Automake not recognizing &
06 +0200 marco atzeri wrote:
>
> basename has no testname options. So I do not understand why
> it should be a basename problem...
>
> specially as it is the same on linux
> http://linux.die.net/man/1/basename
>
> not clear to me what is aborting
> could you clarify ?
&g
Hello,
When trying to 'make check' Open MPI from the SVN sources I observe
the following issue with 'basename' from 'coreutils' Cygwin package:
basename: extra operand `--test-name'
Try `basename --help' for more information.
--> Testing
test-driver: line 95: Aborted (core dumpe
Thank you, Csaba,
I was able to track down a stranded library which shouldn't be there,
and now it works!
I've also tracked down that problem with 'test-driver'. Look at that:
$ gdb --args /usr/bin/sh /usr/share/automake-1.14/test-driver
GNU gdb (GDB) 7.6.50.20130320-cvs
Copyright (C) 2013 Free
Help needed: whenever I run 'make check' I'm experiencing the same
kind or error:
copying 'test-driver' from... to... upon (auto)configure phase, then,
when checking:
test-driver: line 95: Segmentation fault
It's likely due to some mis-compiled binary on my system. How to track it down?
--
Probl
Hello,
I could not get any output from 'gnutls' Cygwin64 package. Could
somebody invoke it as follows:
gnutls-cli - GnuTLS client
or any other example.
Compiled from the sources it passes many tests, but still no luck,
very strange, indeed.
Thank you in advance.
Best regards
Please, take a look at:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/ddk/ntddk.h (why '/mingw/'?)
which has:
#include
which in turn causes a lot of conflicting types errors with winnt.h,
besides complaining wdm.h is not being found
--
Problem reports: http://cygwin.com/problems.html
FAQ
On 6/17/2013, Larry wrote:
That is the way it works for non-test packages.
I'm not sure what mirror you're using but on mirror.mcs.anl.gov, bash
4.1.11 is the only version available for x64.
~~~
No, it does not.
I've compiled, and installed bash 4.2.45 for x64, and made appropriate
changes in
cygwin dot com
Date: Mon, 17 Jun 2013 15:01:37 -0400
Subject: Re: [Feature request] Setup64.exe should respect more recent
packages' version
References:
Reply-to: cygwin at cygwin dot com
On 6/17/2013 2:54 PM, Vasiliy wrote:
Could it be possible for Setup64.exe
Could it be possible for Setup64.exe that it would not offer
downgrading packages by default if their more recent counterparts are
installed? Example of an undesirable behavior: installed is bash 4.2,
but 4.1 version is wrongly suggested, etc.
--
Problem reports: http://cygwin.com/problems.h
ok, it seems that newlib/libc/stdlib/environ.c has not made its way
into cygwin1.dll and/or libcygwin.a; shouldn't that be included?
From: Corinna Vinschen
To: cygwin at cygwin dot com
Date: Wed, 12 Jun 2013 11:53:15 +0200
Subject: Re: __cygwin_environ, __imp_envir
I have compiled 'gnubik' from GNU Ftp, and it fails with:
$ gnubik
(gnubik:28564): GdkGLExt-WARNING **: Window system doesn't support OpenGL.
Upon checking, I couldn't see any longer XWin's -wgl option working,
though no warnings were issued. Is that all right?:
$ uname -srvm
CYGWIN_NT-6.1 1.7.
Sorry, my fault, please ignore this one.
C:\cygwin\bin\...
needed to be
C:\cygwin64\bin\...
-- Forwarded message --
From: Vasiliy
Date: Sat, Jun 8, 2013 at 9:56 PM
Subject: x86_64-pc-cygwin-windres.exe vs. cygwin1.dll v1.17.20 version mismatch
To: cygwin
45 [main] x86_64
arded message --
From: Vasiliy
Date: Sat, Jun 8, 2013 at 5:47 PM
Subject: chown --recursive [OWNER][:[GROUP]] ... doesn't work
To: cygwin
chown --recursive *.* doesn't change ownership for all files,
single files are proceeded ok
$ uname -srvm
CYGWIN_NT-6.1 1.7.20(0.266/5/3)
chown --recursive *.* doesn't change ownership for all files,
single files are proceeded ok
$ uname -srvm
CYGWIN_NT-6.1 1.7.20(0.266/5/3) 2013-06-06 17:36 x86_64
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://
uot; (should be "libicons.la" as well)
Best,
Vasiliy
-- Forwarded message --
From: Charles Wilson
To: The Cygwin Mailing List
Date: Fri, 07 Jun 2013 09:59:03 -0400
Subject: Re: Fwd: Cygwin64: mkshortcut - Segmentation fault
References:
I have no idea what this means.
Please, check/note:
> libcygicons.dll.a < is being *installed* to /usr/lib from the sources instead
> of > libicons.dll.a < compiled (!)
Best,
Vasiliy
-- Forwarded message ------
From: Vasiliy
Date: Fri, Jun 7, 2013 at 2:35 PM
Subject: Cygwin64: mkshortcut - Segmen
Original suspect:
user@host /etc/postinstall
$ cat /etc/postinstall/xinit.sh
/usr/bin/mkdir -p "$(/usr/bin/cygpath $CYGWINFORALL -P)/Cygwin-X"
/usr/bin/mkshortcut $CYGWINFORALL -P -i /usr/bin/XWin.exe -n
"Cygwin-X/XWin Server" -a "/usr/bin/bash.exe -l -c
/usr/bin/startxwin.exe" /usr/bi
git clone git://github.com/ifduyue/urlfetch.git
cd urlfetch
python setup.py install
*or*
python3 setup.py install
causes Segmentation fault (also visible in Python 3, if installed
"manually": import urlfetch)
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://
21 matches
Mail list logo
