Re: httpd immediate segfault on startup [solution]

[nemozny]

Jim Garrison-3 wrote
>> 
>> Anyway, to fix "everything", just do: 1) Install cygrunsrv (this is
>> done only once) 2) Run /usr/bin/cygserver-config (this is done only
>> once) 3) Start Apache (/usr/sbin/apachectl ... options ...)
>> 

This helped, thanks!
Only you have to run that cygserver service:
$ cygrunsrv -S cygserver

Then you can safely start httpd.



--
View this message in context: 
http://cygwin.1069669.n5.nabble.com/httpd-immediate-segfault-on-startup-tp120044p122778.html
Sent from the Cygwin list mailing list archive at Nabble.com.

--
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: Cygwin installer: "Next" button should not be default on "Select Packages" page

[Brian Mathis]

On Tue, Nov 17, 2015 at 5:21 PM, Andrey Repin  wrote:
> Greetings, Brian Mathis!
>
>> Current behavior:
>> I have, many times, started typing something into the Search box at
>> the top of the page and instinctively press Enter.  Because the Next
>> button is default, this causes the installer to advance to the
>> installation stage (which may take a while as the actual installation
>> occurs, so it is not easy to quickly go back and change the package
>> selection).
>
>> Expected result:
>> Search filter should be applied and installer should not advance to
>> next stage until Next button. is explicitly clicked.
>
> The "Next" button should be the default action, however, in your specific use
> case, the current behavior is, indeed, undesirable.


Why "should" it be the default action?  Without specific reasoning
behind such a statement, it has no merit.


>> It doesn't matter that the search box dynamically updates the results;
>> there is still a natural instinct to press Enter after typing in the
>> search query.
>
> I don't know. I've long since unlearned that habit.
> And not only because of Cygwin setup. Many applications adopted the same
> pattern of dynamically filtered list, and it is actually very useful.


Seeing as it is a "habit" that you had to unlearn, it only reinforces
that this is incorrect behavior for this case.  Users should not have
to unlearn/relearn a common behavior just for a single control in a
single application.  The argument is not in consistency of coding
(i.e. all panels have "Next" as default, so this one also should), but
consistency of user experience (i.e. when I type something into a
search box and then press Enter, I expect a search to be initiated).

Whether the list is filtered dynamically is beyond the point.  Dynamic
filtering can stay as it is, just the Enter key should either also
initiate filtering (which is probably redundant), or it should simply
do nothing.


> --
> With best regards,
> Andrey Repin
> Tuesday, November 17, 2015 19:18:50
>
> Sorry for my terrible english...
>

--
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: ssh ControlMaster re-broken

[Zhu, Binbin (Nokia - CN/Hangzhou)]

Hi,

Specifically, it worked in 
2.2.0(0.289/5/3) 2015-08-03 12:49 i686 Cygwin

But failed in 
2.2.0(0.289/5/3) 2015-08-03 12:49 i686 Cygwin

Both i686 and x86_64...

Br, Bin
LTE C-PLANE

-Original Message-
From: Zhu, Binbin (Nokia - CN/Hangzhou) 
Sent: Tuesday, November 17, 2015 8:46 PM
To: 'cygwin@cygwin.com' 
Subject: ssh ControlMaster re-broken

Hi,

It worked month ago, but it failed after reinstall.

1. Create shared session: ssh -vvv -nNf -o ControlMaster=yes -o 
ControlPath="$HOME/.ssh/ctl/%L-%r@%h:%p"  remote-host
Output in accepting new connection: 
$ debug1: multiplexing control connection
debug3: fd 5 is O_NONBLOCK
debug3: fd 5 is O_NONBLOCK
debug1: channel 1: new [mux-control]
debug3: channel_post_mux_listener: new mux channel 1 fd 5
debug3: mux_master_read_cb: channel 1: hello sent
debug3: mux_master_read_cb: channel 1 packet type 0x0001 len 4
debug2: process_mux_master_hello: channel 1 slave version 4
debug3: mux_master_read_cb: channel 1 packet type 0x1004 len 4
debug2: process_mux_alive_check: channel 1: alive check
debug3: mux_master_read_cb: channel 1 packet type 0x1002 len 41
debug2: process_mux_new_session: channel 1: request tty 1, X 0, agent 0, subsys 
0, term "xterm", cmd "", env 0
mm_receive_fd: no message header
process_mux_new_session: failed to receive fd 0 from slave

2. Client output:
$ ssh -vvv -o ControlPath="$HOME/.ssh/ctl/%L-%r@%h:%p" remote-host
OpenSSH_7.1p1, OpenSSL 1.0.2d 9 Jul 2015
debug2: fd 3 setting O_NONBLOCK
debug2: mux_client_hello_exchange: master version 4
debug3: mux_client_forwards: request forwardings: 0 local, 0 remote
debug3: mux_client_request_session: entering
debug3: mux_client_request_alive: entering
debug3: mux_client_request_alive: done pid = 10144
debug3: mux_client_request_session: session request sent
mux_client_request_session: read from master failed: Connection reset by peer
debug2: ssh_connect: needpriv 0

Could you help?

Br, Bin


--
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: ssh ControlMaster re-broken

[Larry Hall (Cygwin)]

On 11/18/2015 7:26 AM, Zhu, Binbin (Nokia - CN/Hangzhou) wrote:

Hi,

Specifically, it worked in
2.2.0(0.289/5/3) 2015-08-03 12:49 i686 Cygwin

But failed in
2.2.0(0.289/5/3) 2015-08-03 12:49 i686 Cygwin

Both i686 and x86_64...


Did notice that the "uname" information you provided is the same in the
working and failure cases?  Maybe you pasted the wrong results in one case?


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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: ssh ControlMaster re-broken

[Corinna Vinschen]

On Nov 17 12:46, Zhu, Binbin (Nokia - CN/Hangzhou) wrote:
> Hi,
> 
> It worked month ago, but it failed after reinstall.
> 
> 1. Create shared session: ssh -vvv -nNf -o ControlMaster=yes -o 
> ControlPath="$HOME/.ssh/ctl/%L-%r@%h:%p"  remote-host
> Output in accepting new connection: 
> $ debug1: multiplexing control connection
> debug3: fd 5 is O_NONBLOCK
> debug3: fd 5 is O_NONBLOCK
> debug1: channel 1: new [mux-control]
> debug3: channel_post_mux_listener: new mux channel 1 fd 5
> debug3: mux_master_read_cb: channel 1: hello sent
> debug3: mux_master_read_cb: channel 1 packet type 0x0001 len 4
> debug2: process_mux_master_hello: channel 1 slave version 4
> debug3: mux_master_read_cb: channel 1 packet type 0x1004 len 4
> debug2: process_mux_alive_check: channel 1: alive check
> debug3: mux_master_read_cb: channel 1 packet type 0x1002 len 41
> debug2: process_mux_new_session: channel 1: request tty 1, X 0, agent 0, 
> subsys 0, term "xterm", cmd "", env 0
> mm_receive_fd: no message header
> process_mux_new_session: failed to receive fd 0 from slave
  ^^
  failed attempt at descriptor passing

> 2. Client output:
> $ ssh -vvv -o ControlPath="$HOME/.ssh/ctl/%L-%r@%h:%p" remote-host
> OpenSSH_7.1p1, OpenSSL 1.0.2d 9 Jul 2015
> debug2: fd 3 setting O_NONBLOCK
> debug2: mux_client_hello_exchange: master version 4
> debug3: mux_client_forwards: request forwardings: 0 local, 0 remote
> debug3: mux_client_request_session: entering
> debug3: mux_client_request_alive: entering
> debug3: mux_client_request_alive: done pid = 10144
> debug3: mux_client_request_session: session request sent
> mux_client_request_session: read from master failed: Connection reset by peer
> debug2: ssh_connect: needpriv 0
> 
> Could you help?

Are you really sure it ever worked?  To the best of my knowledge the
control master stuff always required descriptor passing via AF_LOCAL
sockets, which is not available under Cygwin.


Corinna

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


pgpHpIfYduxwL.pgp
Description: PGP signature

Re: Symlink targets dereferenced when winsymlinks:native

[Corinna Vinschen]

On Nov 17 23:28, David Macek wrote:
> Hi.
> 
> I went through the UG looking for differences between regular Cygwin
> symlinks and NTFS symlinks, but couldn't find this documented. It
> seems that when using winsymlinks:native, the target path is first
> dereferenced before storing it in the link.

It's a result of the native symlink being a Windows path.  The
ultimate conversion from POSIX to Windows path dereferences all
symlinks.

> That doesn't happed when
> using regular symlink files. Is this behaviour intentional / known?
> 
> If it matters, the use case is `ln -sf /proc/self/fd /dev/fd`.

It matters.  This is a bug in Cygwin, a missing test in fact.  It should
never allow to create native symlinks to targets which only exist inside
of Cygwin.  Consider that /proc/self/fd has no meaning to non-Cygwin
processes at all.  Creating this symlink as native symlink doesn't make
any sense, they should always be generated as Cygwin-only symlinks.

Thanks for the report, I'll apply a matching patch.


Corinna

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


pgp1k3vzaiPCx.pgp
Description: PGP signature

Re: fnmatch() doesn't work with character classes?

[Corinna Vinschen]

On Nov 18 05:52, Dustin Boyd wrote:
> fnmatch() does not appear to work with character classes or character
> equivalents. regcomp(), however, does work with character classes, but
> not character equivalents. Is this behavior one should expect? I've
> tested with Debian, and it matches in both cases.

The behaviour is expected.  Debian uses glibc, Cygwin doesn't.

> I sent this to the Cygwin ML rather than the Newlib ML just because of
> the fact that it may be locale-related, which is a problem on Cygwin's
> end, not Newlib's, if it's a problem at all.

That's right in this case because Cygwin has its own fnmatch and regcomp.
Both are taken from FreeBSD.  So the support for character classes and
character equivalents match what FreeBSD supports.


Corinna

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


pgptJEMKsB6qY.pgp
Description: PGP signature

Re: Symlink targets dereferenced when winsymlinks:native

[David Macek]

On 18. 11. 2015 18:55, Corinna Vinschen wrote:
> On Nov 17 23:28, David Macek wrote:
>> Hi.
>>
>> I went through the UG looking for differences between regular Cygwin
>> symlinks and NTFS symlinks, but couldn't find this documented. It
>> seems that when using winsymlinks:native, the target path is first
>> dereferenced before storing it in the link.
> 
> It's a result of the native symlink being a Windows path.  The
> ultimate conversion from POSIX to Windows path dereferences all
> symlinks.

Should that behaviour stay? If not, I can send a patch for the UG.

>> That doesn't happed when
>> using regular symlink files. Is this behaviour intentional / known?
>>
>> If it matters, the use case is `ln -sf /proc/self/fd /dev/fd`.
> 
> It matters.  This is a bug in Cygwin, a missing test in fact.  It should
> never allow to create native symlinks to targets which only exist inside
> of Cygwin.  Consider that /proc/self/fd has no meaning to non-Cygwin
> processes at all.  Creating this symlink as native symlink doesn't make
> any sense, they should always be generated as Cygwin-only symlinks.
> 
> Thanks for the report, I'll apply a matching patch.

Cool.

-- 
David Macek



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Symlink targets dereferenced when winsymlinks:native

[Corinna Vinschen]

On Nov 18 19:13, David Macek wrote:
> On 18. 11. 2015 18:55, Corinna Vinschen wrote:
> > On Nov 17 23:28, David Macek wrote:
> >> Hi.
> >>
> >> I went through the UG looking for differences between regular Cygwin
> >> symlinks and NTFS symlinks, but couldn't find this documented. It
> >> seems that when using winsymlinks:native, the target path is first
> >> dereferenced before storing it in the link.
> > 
> > It's a result of the native symlink being a Windows path.  The
> > ultimate conversion from POSIX to Windows path dereferences all
> > symlinks.
> 
> Should that behaviour stay?

Yes.  Consider that neither Cygwin or Interix symlinks with SYSTEM bit
set, nor symlinks using WIndows shortcuts make any sense as part of a
native symlink.  As a result, Cygwin does a full path conversion from
POSIX to symlink-less Windows path to crate native symlinks.

> If not, I can send a patch for the UG.

UG?

> > Thanks for the report, I'll apply a matching patch.
> 
> Cool.

https://sourceware.org/git/?p=newlib-cygwin.git;h=8cdd7bad219ba2657e381bd0d716594c50a6ef62


Corinna

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


pgpvwz2U4wL5Y.pgp
Description: PGP signature

Re: Symlink targets dereferenced when winsymlinks:native

[Warren Young]

On Nov 18, 2015, at 12:48 PM, Corinna Vinschen wrote:
> 
>> If not, I can send a patch for the UG.
> 
> UG?

User guide.

--
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: Symlink targets dereferenced when winsymlinks:native

[Corinna Vinschen]

On Nov 18 13:01, Warren Young wrote:
> On Nov 18, 2015, at 12:48 PM, Corinna Vinschen wrote:
> > 
> >> If not, I can send a patch for the UG.
> > 
> > UG?
> 
> User guide.

Ouch, right, thanks :)

Patches to the documentation are *always* welcome.


Corinna

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


pgp5mqVIHcJuy.pgp
Description: PGP signature

RE: Can MKS Toolkit and Cygwin safely co-exist on Windows servers?

[Buchbinder, Barry (NIH/NIAID) [E]]

Peter A. Castro sent the following at Monday, November 16, 2015 9:17 PM
>
>Oh! I've been there and tried to do that but was shutdown for corporate
>policy reasons. Remember that business wants someone to shoot at when
>things break. That license you have for MKS means your company can
>demand support from someone. Cygwin is "free" and support is really just
>this email list and "WJM". :)

I believe that paid support is available from Red Hat.

http://www.redhat.com/services/custom/cygwin/

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.
  The above is just for informational purposes and is not
  an endorsement or recommendation.

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

gfortran segfaults on "Hello world"

[Thomas Koenig]

Hi,

gfortran appears to be broken (segfault) with the newest cygwin
version I just downloaded. It segfaults on a "Hello, world" program.
gcc works fine.

The warnings on the GMP and MPFR headers make me suspect that some
dependency may be broken.

Here's what happens:

$ gfortran.exe hello.f
: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ which gfortran
/usr/bin/gfortran

$ ldd /usr/lib/gcc/x86_64-pc-cygwin/4.9.3/f951.exe
ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll 
(0x7ff96d54)
KERNEL32.DLL => /cygdrive/c/Windows/system32/KERNEL32.DLL 
(0x7ff96b8d)
KERNELBASE.dll => /cygdrive/c/Windows/system32/KERNELBASE.dll 
(0x7ff96a76)

cygcloog-isl-4.dll => /usr/bin/cygcloog-isl-4.dll (0x3fc70)
cygwin1.dll => /usr/bin/cygwin1.dll (0x18004)
cyggmp-10.dll => /usr/bin/cyggmp-10.dll (0x3fb61)
cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3fa2f)
cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3f69d)
cygisl-10.dll => /usr/bin/cygisl-10.dll (0x3f68e)
cygmpc-3.dll => /usr/bin/cygmpc-3.dll (0x3f63f)
cygmpfr-4.dll => /usr/bin/cygmpfr-4.dll (0x3f639)
cygz.dll => /usr/bin/cygz.dll (0x3f493)
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fbc5)

$ gfortran -v hello.f
Driving: gfortran -v hello.f -l gfortran -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/4.9.3/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with: 
/cygdrive/i/szsz/tmpp/gcc/gcc-4.9.3-1.x86_64/src/gcc-4.9.3/configure 
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-4.9.3-1.x86_64/src/gcc-4.9.3 
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc 
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C 
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin 
--target=x86_64-pc-cygwin --without-libiconv-prefix 
--without-libintl-prefix --libexecdir=/usr/lib --enable-shared 
--enable-shared-libgcc --enable-static 
--enable-version-specific-runtime-libs --enable-bootstrap 
--enable-__cxa_atexit --with-dwarf2 --with-tune=generic 
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite 
--enable-threads=posix --enable-libatomic --enable-libgomp 
--disable-libitm --enable-libquadmath --enable-libquadmath-support 
--enable-libssp --enable-libada --enable-libgcj-sublibs 
--disable-java-awt --disable-symvers 
--with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as 
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix 
--without-libintl-prefix --with-system-zlib --enable-linker-build-id

Thread model: posix
gcc version 4.9.3 (GCC)
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-cygwin/4.9.3/f951.exe hello.f -ffixed-form 
-quiet -dumpbase hello.f -mtune=generic -march=x86-64 -auxbase hello 
-version -fintrinsic-modules-path 
/usr/lib/gcc/x86_64-pc-cygwin/4.9.3/finclude -o /tmp/ccsadurw.s

GNU Fortran (GCC) version 4.9.3 (x86_64-pc-cygwin)
compiled by GNU C version 4.9.3, GMP version 6.0.0, MPFR 
version 3.1.2-p11, MPC version 1.0.3

warning: GMP header version 6.0.0 differs from library version 6.1.0.
warning: MPFR header version 3.1.2-p11 differs from library version 3.1.3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran (GCC) version 4.9.3 (x86_64-pc-cygwin)
compiled by GNU C version 4.9.3, GMP version 6.0.0, MPFR 
version 3.1.2-p11, MPC version 1.0.3

warning: GMP header version 6.0.0 differs from library version 6.1.0.
warning: MPFR header version 3.1.2-p11 differs from library version 3.1.3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Any ideas?

Regards

Thomas

--
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: gfortran segfaults on "Hello world"

[Tim Prince]

On 11/18/2015 5:26 PM, Thomas Koenig wrote:

Hi,

gfortran appears to be broken (segfault) with the newest cygwin
version I just downloaded. It segfaults on a "Hello, world" program.
gcc works fine.

The warnings on the GMP and MPFR headers make me suspect that some
dependency may be broken.

Here's what happens:

$ gfortran.exe hello.f
: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ which gfortran
/usr/bin/gfortran

$ ldd /usr/lib/gcc/x86_64-pc-cygwin/4.9.3/f951.exe
 ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll
(0x7ff96d54)
 KERNEL32.DLL => /cygdrive/c/Windows/system32/KERNEL32.DLL
(0x7ff96b8d)
 KERNELBASE.dll => /cygdrive/c/Windows/system32/KERNELBASE.dll
(0x7ff96a76)
 cygcloog-isl-4.dll => /usr/bin/cygcloog-isl-4.dll (0x3fc70)
 cygwin1.dll => /usr/bin/cygwin1.dll (0x18004)
 cyggmp-10.dll => /usr/bin/cyggmp-10.dll (0x3fb61)
 cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3fa2f)
 cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3f69d)
 cygisl-10.dll => /usr/bin/cygisl-10.dll (0x3f68e)
 cygmpc-3.dll => /usr/bin/cygmpc-3.dll (0x3f63f)
 cygmpfr-4.dll => /usr/bin/cygmpfr-4.dll (0x3f639)
 cygz.dll => /usr/bin/cygz.dll (0x3f493)
 cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fbc5)

$ gfortran -v hello.f
Driving: gfortran -v hello.f -l gfortran -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/4.9.3/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/gcc/gcc-4.9.3-1.x86_64/src/gcc-4.9.3/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-4.9.3-1.x86_64/src/gcc-4.9.3
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin
--target=x86_64-pc-cygwin --without-libiconv-prefix
--without-libintl-prefix --libexecdir=/usr/lib --enable-shared
--enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --enable-bootstrap
--enable-__cxa_atexit --with-dwarf2 --with-tune=generic
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libgomp
--disable-libitm --enable-libquadmath --enable-libquadmath-support
--enable-libssp --enable-libada --enable-libgcj-sublibs
--disable-java-awt --disable-symvers
--with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --enable-linker-build-id
Thread model: posix
gcc version 4.9.3 (GCC)
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
  /usr/lib/gcc/x86_64-pc-cygwin/4.9.3/f951.exe hello.f -ffixed-form
-quiet -dumpbase hello.f -mtune=generic -march=x86-64 -auxbase hello
-version -fintrinsic-modules-path
/usr/lib/gcc/x86_64-pc-cygwin/4.9.3/finclude -o /tmp/ccsadurw.s
GNU Fortran (GCC) version 4.9.3 (x86_64-pc-cygwin)
 compiled by GNU C version 4.9.3, GMP version 6.0.0, MPFR
version 3.1.2-p11, MPC version 1.0.3
warning: GMP header version 6.0.0 differs from library version 6.1.0.
warning: MPFR header version 3.1.2-p11 differs from library version 3.1.3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran (GCC) version 4.9.3 (x86_64-pc-cygwin)
 compiled by GNU C version 4.9.3, GMP version 6.0.0, MPFR
version 3.1.2-p11, MPC version 1.0.3
warning: GMP header version 6.0.0 differs from library version 6.1.0.
warning: MPFR header version 3.1.2-p11 differs from library version 3.1.3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Any ideas?

upgrade gmp and mpfr to current versions.  I prefer the gfortran 5.2 
binary, or a 6.0 bootstrapped from 5.2, all using those current cygwin 
gmp and mpfr releases.

--
Tim Prince

--
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: gfortran segfaults on "Hello world"

[Thomas Koenig]

Hi,


Cygwin64 now offers a choice among 4.9.2-3, 4.9.3-1, and 5.2.0-1.  I
have the last one installed, and in addition a recently built 6.0 on my
Haswell laptop.  I’m fairly certain I have used the 4.9.3 successfully
in the past.  It looks like you need to update to the current gmp and
mpfr.  Normally, cygwin install.exe would tell you to do that if you
install a gcc and gfortran built against those.


I just installed 5.2.0, and got the same warning about mismatched
libraries and the same segfault.


If you really wanted 4.9.3-1 running against the older gmp and mpfr, you
could build it yourself.


The library versions are *newer* than what both 4.9.3 and 5.2.0 from the
distribution are built against.  This may or may not be the cause of the
problem; either way gfortran is currently broken on Cygwin 64.

If your sytem is running fine, don't upgrade :-)

Building gfortran myself under Cygwin has not been a happy experience
for me in the past (although I do it quite regularly on Linux, of
course).  Maybe I'll give it a spin.

Regards

Thomas



--
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: gfortran segfaults on "Hello world"

[Achim Gratz]

Thomas Koenig writes:
> The warnings on the GMP and MPFR headers make me suspect that some
> dependency may be broken.

No, they simply have been updated after gcc was built.

> warning: GMP header version 6.0.0 differs from library version 6.1.0.

Can you downgrade to libgmp10-6.0.0a-2 and check if that solves the
problem for you?  There has been no API bump and the libraries are
supposed to be binary compatible, but maybe gcc is doing something funky
with some internals.

> warning: MPFR header version 3.1.2-p11 differs from library version
> 3.1.3.

The current version really is just rolling up the patches of the former
and an official rename and it's been in place for long enough to be an
unlikely candidate for breakage.


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

--
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: gmp-6.1.0-1

[Achim Gratz]

Nem W Schlecht writes:
> Today I noticed that some of my Perl DBI scripts (connecting to MSSQL)
> had been failing since Nov 10th (causing perl core dumps).  Thinking
> it was just a needed re-compile, I recompiled DBD::Sybase, which
> compiled fine, but core dumped during testing.  I then tried to
> recompile the DBI module and that was causing gcc to core dump!
>
> I went through my list of installs from that day and eventually found
> that this update was causing the problem.  I backed it from 6.1.0-1 to
> 6.0.0a-2 and now everything is working just fine again for me
> (DBD::Sybase and compiling DBI).
>
> Nothing else seems to be affected by this - just my database access (I
> don't use another database on this host).  I have another host running
> cygwin that is very close to this host (Windows 7 x64, Cygwin 2.3.1)
> and it does *NOT* have the same issue.  Both are running SQL Server
> 2014 Developer (x64).
>
> I'd be happy to help debug this issue, but I'm not sure where to
> start.  Any suggestions?

As this doesn't seem to happen on all machines it would probably be useful


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

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

--
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: gmp-6.1.0-1

[Achim Gratz]

Nem W Schlecht writes:
> Today I noticed that some of my Perl DBI scripts (connecting to MSSQL)
> had been failing since Nov 10th (causing perl core dumps).  Thinking
> it was just a needed re-compile, I recompiled DBD::Sybase, which
> compiled fine, but core dumped during testing.  I then tried to
> recompile the DBI module and that was causing gcc to core dump!
>
> I went through my list of installs from that day and eventually found
> that this update was causing the problem.  I backed it from 6.1.0-1 to
> 6.0.0a-2 and now everything is working just fine again for me
> (DBD::Sybase and compiling DBI).
>
> Nothing else seems to be affected by this - just my database access (I
> don't use another database on this host).  I have another host running
> cygwin that is very close to this host (Windows 7 x64, Cygwin 2.3.1)
> and it does *NOT* have the same issue.  Both are running SQL Server
> 2014 Developer (x64).
>
> I'd be happy to help debug this issue, but I'm not sure where to
> start.  Any suggestions?

As this doesn't seem to happen on all machines it would probably be
useful to know which architectures are affected.


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

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

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