Re: 64bit (g)fortran JNI
On 04/12/2011 07:38 AM, Hans Horn wrote: Folks, has anybody got any experience interfacing (g)fortran routines with Java via JNI? I'm on 64bit Windows7 using cygwin x86_64-w64-mingw32-gcc and x86_64-w64-mingw32-gfortran, both v4.5.2 Java: jdk-6u24-windows-x64 Even though I can statically link the JNI code successfully (using gfortran as linker), calling any native method from Java crashes the JVM - even when no fortran code is called at all. What do you mean by native method? Are you trying to call Fortran procedures from Java? In what way does it crash? Can you get a back trace from a debugger? Jerry PS I have no experience with this, just asking some questions to glean additional information. Fortran calling conventions are no exactly the same as C. -- 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: libgfortran3 respin : status and problem
On 03/26/2011 11:18 AM, marco atzeri wrote: --- snip --- Today I have cygwin-1.7.7 , libgfortran3-4.3.4-3, lapack-3.2.2-1, qrupdate-qrupdate-1.1.0-1 fine cygwin-1.7.8 , libgfortran3-4.3.4-4, lapack-3.2.2-2, qrupdate-qrupdate-1.1.1-1 broken (as also octave3.4.0-3) The full source is here, and it is a very tiny lib http://matzeri.altervista.org/cygwin-1.7/qrupdate/ Yes, well, are you going to debug this problem? yes but very slowly, my real job take me real busy and I have little spare time. I just got cygwin-1.7.8 loaded. I am going to see if I can then build gcc/gfortran, and go from there. Marco, please continue your efforts to a reduced example. Jerry -- 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: libgfortran3 respin : status and problem
On 03/26/2011 08:35 AM, Jerry DeLisle wrote: I have been monitoring this thread for the libgfortran maintainer side, but have not had time yet to investigate further. The only platform reporting the issue so far is Cygwin. I am not aware of any changes occurring with 4.3 upstream of Cygwin, but I will check the logs. The latest upstream change in libgfortran was May of 2010. That points to downstream tweaks or not related to libgfortran itself. Jerry -- 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: libgfortran3 respin : status and problem
On 03/26/2011 03:33 AM, marco atzeri wrote:
On Sat, Mar 26, 2011 at 10:45 AM, Corinna Vinschen wrote:
On Mar 26 06:56, marco atzeri wrote:
Hi,
I rebuilt lapack, qrupdate, octave and netcdf with the libgfortran3-4.3.4-4.
( If you wan to try them, install with
setup.exe -X -O -s http://matzeri.altervista.org )
lapack tests passed
netcdf also (i am not 100% sure)
but testing qrupdate I catched another problem.
The test programs go in a never ending loop:
37 15579 [main] tch1dn_sym 4300 fhandler_tty_slave::write: (746):
tty output_mutex: waiting -1 ms
31 15610 [main] tch1dn_sym 4300 fhandler_tty_slave::write: (746):
tty output_mutex: acquired
33 15643 [main] tch1dn_sym 4300 fhandler_tty_slave::write: (789):
tty output_mutex released
That's not an endless loop as far as Cygwin is concerned. When a
process writes to the console, then every write is atomic. To accomplish
that, a mutex is used, like this:
write()
{
acquire mutex
while (there's still something to write)
write it
release mutex
}
So, what you see is a supposedly endless stream of calls to the write
function. Usually, if an error occurs, you would also see an error
message. The only reason you don't see it is if an error already
occured in an earlier call to write. The important would be prior to
the endless loop then. Maybe the testcase doesn't check for errors?
Corinna
the test case is a normal Fortran program that call numerical functions and
print output with a really standard "write" command, nothing fancy.
It used to work fine with previous libgfortran3-4.3.4-3 and cygwin-1.7.7
-
write (*,*)
write (*,*) 'testing Cholesky rank-1 downdate routines.'
write (*,*) 'All residual errors are expected to be small.'
write (*,*)
n = 50
write (*,*) 'sch1dn test:'
call stest(n)
write (*,*) 'dch1dn test:'
call dtest(n)
write (*,*) 'cch1dn test:'
call ctest(n)
write (*,*) 'zch1dn test:'
call ztest(n)
-
subroutine smdump(name,m,n,A,lda)
character(*) name
integer m,n,lda
real A(lda,n)
integer i,j
write (*,1001) name
do i = 1,m
do j = 1,n
write(*,1002) A(i,j)
end do
write(*,*)
end do
--
I have been monitoring this thread for the libgfortran maintainer side, but have
not had time yet to investigate further. The only platform reporting the issue
so far is Cygwin. I am not aware of any changes occurring with 4.3 upstream of
Cygwin, but I will check the logs.
Jerry
--
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 running top on Windows 7
See attached stackdump. This output was followed by a bundle of messages like this: End of stack trace 7247 [sig] top 6112 exception::handle: Error while dumping state (probably corrupted stack) 128235 [sig] top 6112 exception::handle: Error while dumping state (probably corrupted stack) 221305 [sig] top 6112 exception::handle: Error while dumping state (probably corrupted stack) Is there other diagnostics needed? cygcheck -c returns OK for all packages. The top session runs for several minutes fine before this fault occurs. Jerry je...@quasar ~ $ bin/ gcc/ prs/ top.exe.stackdump* je...@quasar ~ $ Stack trace: Frame Function Args 0028B734 76771184 (0288, EA60, , 0028B858) 0028B748 76771138 (0288, EA60, 00A4, 0028B83C) 0028B858 610C6013 (, 0288, 0028B878, ) 0028B938 610C2CA7 (, , , ) 0028B988 610C30BB (17E0, 0028B9B0, 0028BBF0, 0028BBC0) 0028BA48 610C31E1 (17E0, 0006, 0028BA78, 610C3285) 0028BA58 610C321C (0006, 0028CE80, 4004, 610F3943) 0028BA78 610C3285 (, , 00D9F6B8, C004) Exception: STATUS_ACCESS_VIOLATION at eip=61026397 eax=610F163D ebx=61163240 ecx=C010 edx=C014 esi=0008 edi=18F4CC80 ebp=18F4C8E8 esp=18F4C8E0 program=C:\cygwin\bin\top.exe, pid 6112, thread sig cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: Frame Function Args 18F4C8E8 61026397 (61163240, 611A3B45, C004, ) 18F4C908 6102736C (0028B71C, 0001, 0001, ) 18F4C938 61027EA5 (0050, 18F4C974, , ) 18F4CC58 610284CC (0118, 18F4CC80, 00A4, 18F4CD28) 18F4CD38 610C6C1B (61162220, , , ) 18F4CD68 61003DC1 (, , , 61004654) End of stack trace -- 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
Quad precision floating point package for gfortran
We are developing a quad precision floating point library for use with gfortran. When attempting to build the library under Cygwin, we are stopped because: __float128 is not supported when running the ./configure for the package. I suspect the issue may be related to newlib vs glibc, but I really don't know. Do any of the Cygwin maintainers have any hints about this? I am still investigating. It would be nice to have this quad precision capability under Cygwin. The library is a software floating point library and does not depend on having special hardware. We have it running on i686 and x86-64 Linux, but so far no luck under Windows. If I learn more in the next few days, I will report here. Any suggestions would be appreciated. Best regards, Jerry -- 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: gcc Cygwin package maintainer
On 08/07/2010 01:13 PM, Dave Korn wrote: On 07/08/2010 17:59, Jerry DeLisle wrote: Hi, Who is the Cygwin gcc package maintainer? I've been a bit AWOL recently, but I think that's still me :-/ I want to make sure my gfortran 4.6 experimental builds are consistent with Cygwin distributions. I notice I have far fewer configure parameters then I see when I invoke gfortran -v . Most of the --XXXdir= settings are supplied by cygport in order to make the packaging conform to the Cygwin standards. A fair few of them are options that would be on by default anyway, but are just there to be explicit. The most absolutely critical one of all is "--disable-sjlj-exceptions", which is vital for ABI conformance. Any that concern you in particular? I have been using this: ../trunk/configure --prefix=/usr/local/gfortran --enable-languages=c,c++,fortran --enable-threads=posix --enable-sjlj-exceptions --enable-version-specific-runtime-libs --enable-nls --disable-libmudflap --disable-shared --disable-win32-registry --with-system-zlib --enable-checking=release --enable-werror --without-included-gettext --without-x --enable-libgomp So I have sjlj backwards. I will fix that. Then the following I am not sure about. --disable-__cxa_atexit --enable-static --enable-shared --enable-shared-libgcc Shall I include these? Thanks, Jerry -- 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
gcc Cygwin package maintainer
Hi, Who is the Cygwin gcc package maintainer? I want to make sure my gfortran 4.6 experimental builds are consistent with Cygwin distributions. I notice I have far fewer configure parameters then I see when I invoke gfortran -v . Regards, Jerry -- 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: gcc: building gcc-4.5.0 for Cygwin
Paul Bibbings wrote:
Whilst I do use the versions of gcc available as Cygwin packages, I have
also successfully built from source and used other versions. Most
recently I have added gcc-4.4.1, 4.4.3 and a 4.5.0 snapshot (end of Feb
2010). I configure them to build and install in /opt/gcc-{version}. I
then incorporate these into the `alternatives' system and switch using
$alternatives --config gcc/g++ etc.
This has worked fine in the past, but with the recent release of
gcc-4.5.0 I have encountered a problem:
17:59:37 Paul bibbi...@jijou
/cygdrive/d/CPPProjects/Emacs/CPP0x $gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER
=/opt/gcc-4.5.0/libexec/gcc/i686-pc-cygwin/4.5.0/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: ./configure --prefix=/opt/gcc-4.5.0
--enable-bootstrap --enable-version-specific-runtime-libs
--enable-static --enable-shared --enable-shared-libgcc
--disable-__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2
--disable-sjlj-exceptions --enable-languages=c,c++ --disable-symvers
--enable-libgomp --enable-libssp --enable-threads=posix
--with-arch=i686 --with-tune=generic
Thread model: posix
gcc version 4.5.0 (GCC)
Unlike with my builds for gcc-4.4.1 and 4.4.3, say, this build has
dropped a string of .dlls into /opt/gcc-4.5.0/bin:
17:59:41 Paul bibbi...@jijou
/cygdrive/d/CPPProjects/Emacs/CPP0x $ls -l /opt/gcc-4.5.0/bin
total 11320
-rwxr-xr-x 4 ... 604046 Apr 15 09:04 c++.exe
-rwxr-xr-x 1 ... 602030 Apr 15 09:04 cpp.exe
-rwxr-xr-x 1 ... 437743 Apr 15 09:08 cyggcc_s-1.dll
-rwxr-xr-x 1 ... 271146 Apr 15 09:08 cyggomp-1.dll
-rwxr-xr-x 1 ... 55679 Apr 15 09:08 cygssp-0.dll
-rwxr-xr-x 1 ... 5829289 Apr 15 09:07 cygstdc++-6.dll
-rwxr-xr-x 4 ... 604046 Apr 15 09:04 g++.exe
-rwxr-xr-x 3 ... 599400 Apr 15 09:05 gcc.exe
-rwxr-xr-x 1 ... 16117 Apr 15 09:04 gccbug
-rwxr-xr-x 1 ... 136186 Apr 15 09:04 gcov.exe
-rwxr-xr-x 4 ... 604046 Apr 15 09:04 i686-pc-cygwin-c++.exe
-rwxr-xr-x 4 ... 604046 Apr 15 09:04 i686-pc-cygwin-g++.exe
-rwxr-xr-x 3 ... 599400 Apr 15 09:05 i686-pc-cygwin-gcc.exe
-rwxr-xr-x 3 ... 599400 Apr 15 09:05 i686-pc-cygwin-gcc-4.5.0.exe
This now means that there are path issues for running applications built
with gcc-4.5.0 and there are certainly entry point failures:
19:19:14 Paul bibbi...@jijou
/cygdrive/d/CPPProjects/Emacs/CPP0x $cygcheck bin/CPP0x
D:\CPPProjects\Emacs\CPP0x\bin\CPP0x.exe // built: gcc-4.5.0
C:\cygwin\bin\cyggcc_s-1.dll // wrong dll
C:\cygwin\bin\cygwin1.dll
C:\Windows\system32\ADVAPI32.DLL
C:\Windows\system32\ntdll.dll
C:\Windows\system32\KERNEL32.dll
C:\Windows\system32\RPCRT4.dll
C:\cygwin\bin\cygstdc++-6.dll// wrong dll
gdb: unknown target exception 0xc139 at 0x77d69eed
During startup program exited with code 0xc139.
if the runtime sees the corresponding .dlls in /usr/bin first.
Prepending /opt/gcc-4.5.0/bin to the PATH get's round this, of course.
But now it's not as simple for my alternatives configuration: it works
for the build, but now it looks like I might need to control the runtime
too.
My thought is to investigate incorporating the relevant .dlls into the
alternatives system, but before doing that I'd like to check out if
this sounds feasible. Currently I have symlinks in /usr/bin for things
like gcc and g++, with:
/usr/bin/gcc -> /etc/alternatives/gcc
/usr/bin/g++ -> /etc/alternatives/g++
and then:
/etc/alternatives/gcc -> /opt/gcc-4.5.0/bin/gcc.exe
/etc/alternatives/g++ -> /opt/gcc-4.5.0/bin/g++.exe
Can I, then, do the same with the .dlls in question? Is it possible,
for instance, for .dlls to be loadable via symlinks under Cygwin? E.g:
/usr/bin/cygstdc++-6.dll -> /etc/alternatives/cygstdc++-6.dll
/etc/alternatives/cygstdc++-6.dll ->
/opt/gcc-4.5.0/bin/cygstdc++-6.dll
[after $alternatives --config gcc, selecting gcc-4.5.0]
Or are there other options to consider? My aim is to be able to
continue to switch between implementations using `alternatives' alone,
if that is at all possible, and to not have to think about changing and
reverting paths.
Have I perhaps configured/built this incorrectly?
I have not had any problems building with Cygwin 1.7 on WinNT or Win7. You do
have to make sure you have the mpc complex math library installed. Other than
that I have had no problems.
Jerry
--
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 binary updated on GFortran wiki to 4.6
The gfortran binary at the wiki has been updated to latest trunk experimental 4.6. This binary includes c, c++, and fortran compilers. (Note: This is not an official Gnu or Cygwin release.) Let me know if any problems encountered. http://gcc.gnu.org/wiki/GFortranBinaries Regards, Jerry -- 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: Still having problems installing on WinNT 4.0
On 12/28/2009 08:41 PM, Jerry DeLisle wrote: On 12/28/2009 08:18 PM, Christopher Faylor wrote: On Mon, Dec 28, 2009 at 08:05:10PM -0800, Jerry DeLisle wrote: On a separate machine from my previous install problem, setup.exe runs but I get this warning: "The current ini file is from a newer version of setup.exe. If you have any trouble installing, please download a fresh " I have scanned the disks for any ini I can find and there are none remotely related to cygwin. I have also tried downloading setup.exe several times. Continuing on I get: ... setup.bz2 line 2567: syntax error, unexpected STRING Help is much appreciated. You are *not* downloading the latest version of setup.exe which is the version that you'll see in setup.ini - 2.674 . Perhaps some helpful proxy is caching the setup.exe download. I think you are right. I have a way to wget off of a different provider. I will try that and report back Confirmed, the browser I was using was caching the file. I simply used a different browser and it brought in 2.6.. Thanks for catching that for me. Jerry -- 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: Still having problems installing on WinNT 4.0
On 12/28/2009 08:18 PM, Christopher Faylor wrote: On Mon, Dec 28, 2009 at 08:05:10PM -0800, Jerry DeLisle wrote: On a separate machine from my previous install problem, setup.exe runs but I get this warning: "The current ini file is from a newer version of setup.exe. If you have any trouble installing, please download a fresh " I have scanned the disks for any ini I can find and there are none remotely related to cygwin. I have also tried downloading setup.exe several times. Continuing on I get: ... setup.bz2 line 2567: syntax error, unexpected STRING Help is much appreciated. You are *not* downloading the latest version of setup.exe which is the version that you'll see in setup.ini - 2.674 . Perhaps some helpful proxy is caching the setup.exe download. I think you are right. I have a way to wget off of a different provider. I will try that and report back Jerry -- 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
Still having problems installing on WinNT 4.0
On a separate machine from my previous install problem, setup.exe runs but I get this warning: "The current ini file is from a newer version of setup.exe. If you have any trouble installing, please download a fresh " I have scanned the disks for any ini I can find and there are none remotely related to cygwin. I have also tried downloading setup.exe several times. Continuing on I get: ... setup.bz2 line 2567: syntax error, unexpected STRING Help is much appreciated. Jerry -- 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: New 1.7 release setup does not run on WinNT
On 12/27/2009 10:25 AM, Christopher Faylor wrote: On Sun, Dec 27, 2009 at 12:28:47PM -0500, Christopher Faylor wrote: Hold off. I'm fixing setup.exe now. I've uploaded a new version. It seems to work ok on NT4. What is the version number of the new one? I have moved to a new location on a different machine and though it runs, it has a problem with the ini file being newer. Jerry -- 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: New 1.7 release setup does not run on WinNT
Christopher Faylor wrote: On Sun, Dec 27, 2009 at 12:28:47PM -0500, Christopher Faylor wrote: Hold off. I'm fixing setup.exe now. I've uploaded a new version. It seems to work ok on NT4. It appears to be working here as well. Running now. Thanks, Jerry -- 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: New 1.7 release setup does not run on WinNT
Christopher Faylor wrote: On Sun, Dec 27, 2009 at 09:20:11AM -0800, Jerry DeLisle wrote: Jerry DeLisle wrote: Christopher Faylor wrote: On Sun, Dec 27, 2009 at 07:57:37AM -0800, Jerry DeLisle wrote: I have been using the 1.7 beta without any issues up until the official release. I try to run 1.7.1 setup and nothing happens, it just exits without even opening a window. Trying to run the previous version of setup works until it encounters setup.ini which no longer matches the version. Any suggestions? We need more details. What is "WinNT"? NT 3.5? NT 4.0? Windows 2000? NT 4.0 Workstation. Jerry I am going to try a completely fresh install. I have nothing to lose. Hold off. I'm fixing setup.exe now. (But I have to wonder how a completely fresh install is going to work if you can't run setup.exe) To make sure there was not something else I did stupid like trash permissions or have a duplicate dll file in there. However, if you have already discovered the problem, I will hold off. Jerry -- 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: New 1.7 release setup does not run on WinNT
Andy Koppe wrote: 2009/12/27 Jerry DeLisle: I am going to try a completely fresh install. I have nothing to lose. No point in that. I'm afraid you'll need to wait for a setup.exe fix. No problem, I appreciate the help. I do hope this will be fixed. Admittedly there may not be too many users of this older OS, even though it performs quite well. Jerry -- 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: New 1.7 release setup does not run on WinNT
Jerry DeLisle wrote: Christopher Faylor wrote: On Sun, Dec 27, 2009 at 07:57:37AM -0800, Jerry DeLisle wrote: I have been using the 1.7 beta without any issues up until the official release. I try to run 1.7.1 setup and nothing happens, it just exits without even opening a window. Trying to run the previous version of setup works until it encounters setup.ini which no longer matches the version. Any suggestions? We need more details. What is "WinNT"? NT 3.5? NT 4.0? Windows 2000? NT 4.0 Workstation. Jerry I am going to try a completely fresh install. I have nothing to lose. -- 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: New 1.7 release setup does not run on WinNT
Christopher Faylor wrote: On Sun, Dec 27, 2009 at 07:57:37AM -0800, Jerry DeLisle wrote: I have been using the 1.7 beta without any issues up until the official release. I try to run 1.7.1 setup and nothing happens, it just exits without even opening a window. Trying to run the previous version of setup works until it encounters setup.ini which no longer matches the version. Any suggestions? We need more details. What is "WinNT"? NT 3.5? NT 4.0? Windows 2000? NT 4.0 Workstation. Jerry -- 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
New 1.7 release setup does not run on WinNT
I have been using the 1.7 beta without any issues up until the official release. I try to run 1.7.1 setup and nothing happens, it just exits without even opening a window. Trying to run the previous version of setup works until it encounters setup.ini which no longer matches the version. Any suggestions? Jerry -- 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: win7 specific probs; examples; and poor solutions
On 11/20/2009 06:24 PM, Linda Walsh wrote: Andy Koppe wrote: 2009/11/20 Linda Walsh: Some things are obviously not cygwin related. But sometimes it seems like cygwin isn't able to see files that I can see there with explorer. We'd of course need concrete examples for this. I'd love to give you examples, but unless I am sure that it is cygwin that has the problem, I'm not going to put something on here. I did mention, that my 'rash' of problems may have to do with Win7 begin flakey in some way, OR 'linda7' i.e. _me_, having broken something or not understanding how something works. I also mentioned that most of my problems on win7 DO NOT happen on my XP machine. So that indicates it's either win7 specific, OR my configuration on Win7 isn't as detailed nor setup as well as my XP setup which is several years old. If you are not willing to post an example, whether you are sure it's a Cygwin problem or not, so that someone else could try it on their Windows 7 system and possibly answer your question, then stop whining and don't bother posting here. ;) -- 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
Cygwin build of gfortran has been updated
See the wiki: http://gcc.gnu.org/wiki/GFortranBinaries This binary was built with Cygwin-1.7 running on WinNT in VirtualBox on a Linux host. It is provided as a courtesy to expand the gfortran test base and provide users the latest bug fixes and features. Comments and bug reports welcome. Best regards, Jerry -- 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: unable to switch to gcc 4
Hans Horn wrote: Folks, I was trying to make the switch gcc3 -> gcc4 ---snip--- s 16261 Feb 25 2009 /usr/bin/gccbug-3 Am I stupid or what gives? Kindly, H. I think gcc4 is invoked as gcc-4. I usually set up a softlink in my search path. Jerry -- 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: gcc4 and -mno-cygwin
On 10/01/2009 02:21 PM, Jim Reisert AD1C wrote: I understand this error: # gcc-4 -mno-cygwin gcc-4: The -mno-cygwin flag has been removed; use a mingw-targeted cross-compiler. However, I could find no "mingw-targeted cross-compiler" for gcc-4 (though they seem to be there for gcc-3). Does one exist? Thanks - Jim You could try this: http://www.equation.com/servlet/equation.cmd?call=fortran Regards, Jerry -- 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: Core dump on hello world.
On 09/14/2009 02:04 AM, Dave Korn wrote: Dave Korn wrote: Nah, hang on, I'll give the psychic debugging a go. I'm getting something the spirits are talking... or maybe it's just the beer... and they tell me: The problem is that the CPUID instruction in your virtual machine is returning some kind of bogus output that's leading set_fpu() to believe the CPU supports SSE, but the emulation in fact does not, and it blows up here: 0x697826c4: stmxcsr -0x14(%ebp) Also, is your CPU a VIA by any chance, maybe a C7? No, its an AMD Phenom II. However, your hints were correct. I disabled the VirtualBox System::VT-x/AMD-V features and the problem goes away. What Crystal Balls you have! :) Jerry -- 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
Core dump on hello world.
I first noticed this when trying to build and run gfortran 4.5 for my development work on cygwin 1.7. This is on WinNT running in VirtualBox. With 4.5, I get no output at all. With gfortran distributed with Cygwin I get the following. Am I configured wrong? Regards, Jerry $ cat hello.f90 program hello print *, "Hello World!" end program hello $ gfortran-4.exe hello.f90 $ ./a.exe Illegal instruction (core dumped) gdb says: (gdb) r Starting program: /home/jerry/prs/test/a.exe [New thread 162.0xa9] [New thread 162.0x8e] Program received signal SIGILL, Illegal instruction. set_fpu () at ./fpu-target.h:80 80 ./fpu-target.h: No such file or directory. in ./fpu-target.h (gdb) bt #0 set_fpu () at ./fpu-target.h:80 #1 0x004057ff in init () at /gnu/gcc/package/gcc4-4.3.2-2/src/gcc-4.3.2/libgfortran/runtime/main.c:15 5 #2 0x61004eb9 in __main () from /usr/bin/cygwin1.dll #3 0x004011a3 in main (argc=Cannot access memory at address 0x9 ) at /gnu/gcc/package/gcc4-4.3.2-2/src/gcc-4.3.2/libgfortran/fmain.c:11 (gdb) and cygcheck -c : Cygwin Package Information Package Version Status _update-info-dir 00829-1 OK alternatives 1.3.30c-10 OK autoconf 7-10OK autoconf2.1 2.13-10 OK autoconf2.5 2.64-10 OK automake 4-10OK automake1.10 1.10.2-10 OK automake1.11 1.11-10 OK automake1.4 1.4p6-10OK automake1.5 1.5-10 OK automake1.6 1.6.3-11OK automake1.7 1.7.9-10OK automake1.8 1.8.5-10OK automake1.9 1.9.6-10OK base-cygwin 2.0-1 OK base-files 3.8-4 OK base-passwd 3.1-1 OK bash 3.2.49-23 OK binutils 2.19.51-1 OK bison2.3-1 OK bzip21.0.5-10OK coreutils7.0-2 OK crypt1.1-1 OK csih 0.9.1-1 OK cygrunsrv1.34-1 OK cygutils 1.4.0-1 OK cygwin 1.7.0-61OK cygwin-doc 1.5-1 Incomplete dash 0.5.5.1-2 OK dejagnu 20021217-2 OK diffutils2.8.7-1 OK editrights 1.01-2 OK expat2.0.1-1 OK expect 20030128-1 OK findutils4.5.4-1 OK flex 2.5.35-1OK gawk 3.1.7-1 OK gcc-core 3.4.4-999 OK gcc-g++ 3.4.4-999 OK gcc-g77 3.4.4-999 OK gcc-mingw-core 20050522-1 OK gcc-mingw-g++20050522-1 OK gcc-mingw-g7720050522-1 OK gcc-tools-autoconf 2.59-10 OK gcc-tools-automake 1.9.6-10OK gcc4 4.3.2-2 OK gcc4-core4.3.2-2 OK gcc4-fortran 4.3.2-2 OK gcc4-g++ 4.3.2-2 OK gdb 6.8-2 OK gettext 0.17-11 OK gettext-devel0.17-11 OK gmp 4.3.1-3 OK grep 2.5.3-1 OK groff1.19.2-2OK gzip 1.3.12-2OK ipc-utils1.0-1 OK less 429-1 OK libapr1 1.3.8-2 OK libaprutil1 1.3.9-2 OK libbz2_1 1.0.5-10OK libdb4.2 4.2.52.5-2 OK libdb4.5 4.5.20.2-2 OK libexpat12.0.1-1 OK libexpat1-devel 2.0.1-1 OK libffi4 4.3.2-2 OK libgcc1 4.3.2-2 OK libgdbm4 1.8.3-20OK libgettextpo00.17-11 OK libgfortran3 4.3.2-2 OK libgmp-devel 4.3.1-3 OK libgmp3 4.3.1-3 OK libgmpxx44.3.1-3 OK libgomp1 4.3.2-2 OK libiconv21.13-10 OK libintl2 0.12.1-3OK libintl3 0.14.5-1OK libintl8 0.17-11 OK liblzma1 4.999.9beta-10 OK libmpc-devel 0.6-1 OK libmpc1 0.6-1 OK libmpfr-devel2.4.1-4 OK libmpfr1 2.4.1-4 OK libncurses8 5.5-10 OK libncurses9 5.7-14 OK libneon270.28.3-1OK libopenldap2_3_0 2.3.43-1OK libpcre0
Re: [ANNOUNCEMENT] [1.7] Updated: cygwin-1.7.0-58
On 08/13/2009 09:06 AM, Corinna Vinschen wrote: Hi folks, I just uploaded a new Cygwin 1.7 test release, 1.7.0-58. I still refrain from telling stuff like "this is the last test release", but I still hope we're getting really close now, even after I had screwed up so nicely with the 1.7.0-53 and 1.7.0-54 releases :-P Hey, I always say; "If you are going to screw something up, at least do it well!" jerry -- 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: mintty doesn't run on NT4 due to lack of GetConsoleWindow
On 08/06/2009 08:02 AM, Stephan Mueller wrote: Andy Koppe wrote: " (And to be honest I don't see the point in Cygwin 1.7 still supporting " NT4. Anyone willing to stick with an OS that's been unsupported for " five years should be more than happy to stick with Cygwin 1.5.) Agreed, it seems a bit inconsistent, and yet I can think of at least two reasons a user might want an old Windows and a new Cygwin: - user is aiming for as Unixy an experience as possible with minimal Windows interaction, hence always wants latest and greatest Cygwin and hopes never to disturb the Windows OS underneath. - user is happy to upgrade Cygwin because of the price, but would rather not upgrade Windows, because of the price. stephan(); I use NT4 because it is reliable, responsive, and available (I have it already). I use it to test patches for gfortran under Cygwin 1.7. I figure if it works under NT4 with basic win32 features it is a safe bet it will work elsewhere. Maybe I am wrong, but it works for me. I run in VirtualBox on Linux (Linux being my preferred real OS) I provide binaries of gfortran (latest trunk) for Cygwin users as a courtesy and to enable as broad a testing base as I can get for this Gnu software. I wish I could encourage more people to just move to Linux, but I am not unrealistic about that. Regards, Jerry -- 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: 8/04 snapshot was bad. Please try the 8/04 snapshot.
On 08/04/2009 08:27 PM, Christopher Faylor wrote: I screwed up the previous cygwin-20090804 snapshot but there is a new one up now which shouldn't produce a STATUS_EXCEPTION_VIOLATION. Sorry for the inconvenience with the previous one. This one installs and runs fine now on NT 4. Jerry -- 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: Please test the latest snapshot!
On 08/04/2009 07:43 PM, Jerry DeLisle wrote: I tried to bunzip the snapshot and get the following: ~ $ bunzip2.exe cygwin1-20090804.dll.bz2 bunzip2: Data integrity error when decompressing. Input file = cygwin1-20090804.dll.bz2, output file = cygwin1-20090804.dll It is possible that the compressed file(s) have become corrupted. You can use the -tvv option to test integrity of such files. You can use the `bzip2recover' program to attempt to recover data from undamaged sections of corrupted files. bunzip2: Deleting output file cygwin1-20090804.dll, if it exists. ~ Am I doing something wrong? This is with the 56 version of cygwin running. I used wget to fetch the snapshot and it unzips fine. However, completely crashes. The bash shell will not run. The window starts to open and then it terminates. This is on winnt 4.0. Jerry -- 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: Please test the latest snapshot!
I tried to bunzip the snapshot and get the following: ~ $ bunzip2.exe cygwin1-20090804.dll.bz2 bunzip2: Data integrity error when decompressing. Input file = cygwin1-20090804.dll.bz2, output file = cygwin1-20090804.dll It is possible that the compressed file(s) have become corrupted. You can use the -tvv option to test integrity of such files. You can use the `bzip2recover' program to attempt to recover data from undamaged sections of corrupted files. bunzip2: Deleting output file cygwin1-20090804.dll, if it exists. ~ Am I doing something wrong? This is with the 56 version of cygwin running. Jerry -- 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 and gcc 4.5 (experimental) binary for Cygwin-1.7
I have posted a link to gfortran and gcc binaries for the latest gcc experimental 4.5 trunk at the gfortran wiki. This was built under Cygwin-1.7. I do not know if they will run on under Cygwin-1.5. These binaries are pre-release provided for testing purposes. The executables are stripped. The wiki is here: http://gcc.gnu.org/wiki/GFortranBinaries There are instructions for installing provided in the wiki. Please let me know if it works. Regards, Jerry -- 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: Bash initialization w/cygwin-1.7 on NT4
Christopher Faylor wrote: On Mon, Jul 06, 2009 at 10:55:40AM -0700, Jerry DeLisle wrote: Christopher Faylor wrote: --- snip --- I will try the manual process you suggested after I figure out how to get the snapshot and when it is available. Bare in mind that I am using the broken environment to do this. The fact that I could duplicate the problem means that I'm in the same state as you. I managed to extract the snapshot and replace the cygwin1.dll while not running any cygwin apps. Restarting a shell seems to function as before, uninitialized. I then go to /etc/postinstall to find the scripts. They are all suffixed with .done. Are these the scripts I should attempt to run? Yes. You need to do something like: c: cd \cygwin\etc for %f in (*.done) do sh ./%f OK, I have it fixed as follows: 1. Do clean install of cygwin-1.7 selecting bash one revision back. 2. Replace cygwin1.dll with the snapshot of today. 3. Start cygwin shell from desktop icon. 4. cd /etc/postinstall 5. PATH=/bin 6. for filename in ./*.done; do /bin/sh $filename; done; 7. exit 8. restart cygwin shell from desktop icon, all appears well. Thanks Christopher and Dave for your help. Best regards, Jerry -- 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: Bash initialization w/cygwin-1.7 on NT4
Christopher Faylor wrote: --- snip --- I will try the manual process you suggested after I figure out how to get the snapshot and when it is available. Bare in mind that I am using the broken environment to do this. I managed to extract the snapshot and replace the cygwin1.dll while not running any cygwin apps. Restarting a shell seems to function as before, uninitialized. I then go to /etc/postinstall to find the scripts. They are all suffixed with .done. Are these the scripts I should attempt to run? I thought maybe I could just try to reinstall bash after replacing the cygwin1.dll. What do you think? Let me know what you would like me to do to see if this is fixed. Jerry -- 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: Bash initialization w/cygwin-1.7 on NT4
Christopher Faylor wrote: On Mon, Jul 06, 2009 at 12:32:16AM -0400, Christopher Faylor wrote: On Mon, Jul 06, 2009 at 05:20:41AM +0100, Dave Korn wrote: Jerry DeLisle wrote: I am making the switch to 1.7. I started with a clean windows (nt4) environment and went through the usual run of setup-1.7 downloaded today. All appears fine, but bash does not get initialized. pwd is /usr/bin path is not set home directory is not created These are all taken care of nicely for the user with cygwin 1.5 I think this is a bug unless I am missing something in the install process. This is symptomatic of a problem preventing the postinstall scripts >from having run correctly, isn't it? Have a look in your /var/log/setup.log* files, and see what happened to base-files-profile.sh. I can actually duplicate this problem on my NT4 virtual machine. Unfortunately, I won't have a lot of time to track this down next week but I'll get to it if no one else beats me to it. I just checked in a fix for this. It was a pretty embarrassing bug. For some reason, I had decided that it was ok not to check the error return value from an Nt* system call. At least it was an easy fix. For the curious, I debugged it by doing this: set CYWGIN=error_start:gdb When gdb popped up, the stack trace led me straight to the problem. I am generating a new snapshot now but, given the nature of the problem, I'm not entirely sure how to suggest using the snapshot to fix the problem. I guess one thing you could do is just rerun all of the post-install scripts after installing the snapshot cygwin1.dll. Maybe this warrants a cygwin1.dll release. I will try the manual process you suggested after I figure out how to get the snapshot and when it is available. Jerry -- 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: Bash initialization w/cygwin-1.7 on NT4
Christopher Faylor wrote: On Mon, Jul 06, 2009 at 05:20:41AM +0100, Dave Korn wrote: Jerry DeLisle wrote: I am making the switch to 1.7. I started with a clean windows (nt4) environment and went through the usual run of setup-1.7 downloaded today. All appears fine, but bash does not get initialized. pwd is /usr/bin path is not set home directory is not created These are all taken care of nicely for the user with cygwin 1.5 I think this is a bug unless I am missing something in the install process. This is symptomatic of a problem preventing the postinstall scripts from having run correctly, isn't it? Have a look in your /var/log/setup.log* files, and see what happened to base-files-profile.sh. I can actually duplicate this problem on my NT4 virtual machine. Unfortunately, I won't have a lot of time to track this down next week but I'll get to it if no one else beats me to it. I am running NT4 in VirtualBox. In setup.log there are a series of invocations of bash like this: Running: D:\cygwin\bin\bash --norc --noprofile /etc/postinstall/somescript.sh abnormal exit: exit code = 35584 This is on all the post install scripts. I did a very clean install using the previous version of bash and libreadline6 added to the installation. Looking at setup.log.full I see the exception STATUS_STACK_OVERFLOW in all cases. Regards, Jerry -- 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
Bash initialization w/cygwin-1.7 on NT4
I am making the switch to 1.7. I started with a clean windows (nt4) environment and went through the usual run of setup-1.7 downloaded today. All appears fine, but bash does not get initialized. pwd is /usr/bin path is not set home directory is not created These are all taken care of nicely for the user with cygwin 1.5 I think this is a bug unless I am missing something in the install process. Please advise. Jerry -- 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: Bash initialization w/cygwin-1.7
Dave Korn wrote: Jerry DeLisle wrote: Well, I am moving to this thread now. Jerry, can I show you something you must not have realised about how email threading works? Thank you for pointing this out. I usually don't use the thread view in my mail client. I will avoid this breakage in the future as best I can. I will attempt to start a fresh thread. Jerry -- 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: Bash initialization w/cygwin-1.7
Christopher Faylor wrote: On Sun, Jul 05, 2009 at 07:34:24PM -0700, Jerry DeLisle wrote: Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jerry DeLisle on 7/5/2009 1:35 PM: Warning: There are multiple cygwin1.dlls on your path That's probably your culprit. I saw that too and did a full search of the disk and there is only one cygwin1.dll I am also seeing a stack dump for id.exe and one for bash.exe. The id.exe stackdump occurs when I execute cygcheck -s The other symptoms are: none of the startup scripts are being sourced (executed). I end up with a bare shell running with /usr/bin as the current working directory. The only reason I can do anything at all is I added the cygwin bin directory to the windows path. You're still in the wrong thread. Look at the subject. Does it have anything to do with the problem you are having? Apparently it doesn't. It sounds like you are conflating a serious STATUS_ACCESS_VIOLATION which is known to occur on Windows 7 with your not-so-serious "Bash initialization w/cygwin-1.7". My release of binutils means that Eric can respin bash. It doesn't mean that, if you install binutils, it will somehow fix bash. But, I'm not sure why binutils would be to blame for bash not initializing correctly. Well, I am moving to this thread now. I presumed this has something to do with bash, maybe execution of the post install scripts has been messed up. Perhaps the default bash startup scripts are not present at all. Regardless, I was seeing the bash stackdump and that is what lead me to believe it was the other problem (other thread) Jerry -- 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: fresh 1.7, bash fails with STATUS_ACCESS_VIOLATION
Here is some more information: bash-3.2$ ./cygcheck -s >jerrycheck 741 [main] id 85 _cygtls::handle_exceptions: Exception: STATUS_STACK_OVERFLO W 3209 [main] id 85 open_stackdumpfile: Dumping stack trace to id.exe.stackdump garbled output from 'id' command - no uid= found 1206 [main] id 85 _cygtls::handle_exceptions: Exception: STATUS_STACK_OVERFLO W 3157 [main] id 85 open_stackdumpfile: Dumping stack trace to id.exe.stackdump garbled output from 'id' command - no uid= found bash-3.2$ pwd /usr/bin bash-3.2$ Exception: STATUS_STACK_OVERFLOW at eip=6113BCF2 eax=0046F080 ebx=000B ecx=00032C20 edx=00630069 esi=0168 edi=0001 ebp=00224C78 esp=001F4C18 program=D:\cygwin\bin\id.exe, pid 85, thread main cs=001B ds=0023 es=0023 fs=0038 gs= ss=0023 Stack trace: Frame Function Args 00224C78 6113BCF2 (0065, 00224CA8, 60FE001C, 0001) 00500064 00700069 (, , , ) End of stack trace -- 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: fresh 1.7, bash fails with STATUS_ACCESS_VIOLATION
Dave Korn wrote: Vincent R. wrote: bash 3.2.49-22 OK libreadline6 5.2.14-12 OK libreadline7 6.0.3-1OK Jerry DeLisle wrote: bash 3.2.49-22 libreadline6 5.2.14-12 libreadline7 6.0.3-1 Err, ok. So you've got the working versions. So why do you think you're getting the same bug at all? Surely this *has* to be some entirely different issue than the one that's breaking a version of bash that you aren't using on a version of windows that you aren't using? I am very happy to accept that this problem is something else. Vincent sent a note that it is working for him. I am not sure what "working" means. I have a bash prompt, but none of the default environment variables such as prompts and paths and setting up the home directory are complete. My original post was "Bash initialization w/cygwin-1.7" What is next step. Regards, Jerry -- 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: fresh 1.7, bash fails with STATUS_ACCESS_VIOLATION
Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jerry DeLisle on 7/5/2009 1:35 PM: Warning: There are multiple cygwin1.dlls on your path That's probably your culprit. I saw that too and did a full search of the disk and there is only one cygwin1.dll I am also seeing a stack dump for id.exe and one for bash.exe. The id.exe stackdump occurs when I execute cygcheck -s The other symptoms are: none of the startup scripts are being sourced (executed). I end up with a bare shell running with /usr/bin as the current working directory. The only reason I can do anything at all is I added the cygwin bin directory to the windows path. Regards, Jerry -- 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: fresh 1.7, bash fails with STATUS_ACCESS_VIOLATION
See attached file. Regards, Jerry Cygwin Configuration Diagnostics Current System Time: Sun Jul 05 12:28:58 2009 Windows NT 4 Workstation Ver 4.0 Build 1381 Service Pack 6 Path: C:\WINNT\system32 C:\WINNT D:\cygwin-1.7\bin SysDir: C:\WINNT\System32 WinDir: C:\WINNT PWD = '/usr/bin' CYGWIN = 'notitle glob' HOME = '/home/jerry' Use '-r' to scan registry obcaseinsensitive set to 1 a: fd N/AN/A c: hd NTFS 4094Mb 32% CP CS UN PA FC d: hd NTFS 10228Mb 3% CP CS UN PA FC e: cd N/AN/A D:\cygwin/ system binary,auto D:\cygwin\bin/usr/bin system binary,auto D:\cygwin\lib/usr/lib system binary,auto cygdrive prefix /cygdrive userbinary,auto Not Found: awk Not Found: bash Not Found: cat Not Found: cp Not Found: cpp (good!) Not Found: crontab Found: C:\WINNT\system32\find.exe Not Found: gcc Not Found: gdb Not Found: grep Not Found: kill Not Found: ld Not Found: ls Not Found: make Not Found: mv Not Found: patch Not Found: perl Not Found: rm Not Found: sed Not Found: ssh Not Found: sh Not Found: tar Not Found: test Not Found: vi Not Found: vim 61k 2009/03/02 .\cygbz2-1.dll 40k 2009/03/01 .\cygform-8.dll 41k 2009/03/27 .\cygform-9.dll 42k 2009/03/12 .\cyggcc_s-1.dll 315k 2009/06/06 .\cyggmp-3.dll 24k 2009/06/23 .\cyghistory6.dll 25k 2009/06/23 .\cyghistory7.dll 270k 2009/05/07 .\cygicons-0.dll 981k 2009/05/30 .\cygiconv-2.dll 31k 2005/11/20 .\cygintl-3.dll 31k 2009/04/03 .\cygintl-8.dll 5k 2009/06/18 .\cyglsa.dll 9k 2009/06/18 .\cyglsa64.dll 21k 2009/03/01 .\cygmenu-8.dll 21k 2009/03/27 .\cygmenu-9.dll 211k 2009/06/06 .\cygmp-3.dll 66k 2009/03/01 .\cygncurses++-8.dll 334k 2009/03/27 .\cygncurses++-9.dll 237k 2009/03/01 .\cygncurses-8.dll 164k 2009/03/27 .\cygncurses-9.dll 11k 2009/03/01 .\cygpanel-8.dll 11k 2009/03/27 .\cygpanel-9.dll 190k 2009/04/17 .\cygpcre-0.dll 7k 2009/04/17 .\cygpcreposix-0.dll 22k 2002/06/09 .\cygpopt-0.dll 155k 2009/06/23 .\cygreadline6.dll 162k 2009/06/23 .\cygreadline7.dll 66k 2009/03/27 .\cygtic-9.dll 64k 2009/03/02 .\cygz.dll 2376k 2009/06/18 .\cygwin1.dll Cygwin DLL version info: DLL version: 1.7.0 DLL epoch: 19 DLL old termios: 5 DLL malloc env: 28 Cygwin conv: 181 API major: 0 API minor: 210 Shared data: 5 DLL identifier: cygwin1 Mount registry: 3 Cygwin registry name: Cygwin Program options name: Program Options Cygdrive default prefix: Build date: Thu Jun 18 12:51:49 CEST 2009 Shared id: cygwin1S5 61k 2009/03/02 D:\cygwin\bin\cygbz2-1.dll 40k 2009/03/01 D:\cygwin\bin\cygform-8.dll 41k 2009/03/27 D:\cygwin\bin\cygform-9.dll 42k 2009/03/12 D:\cygwin\bin\cyggcc_s-1.dll 315k 2009/06/06 D:\cygwin\bin\cyggmp-3.dll 24k 2009/06/23 D:\cygwin\bin\cyghistory6.dll 25k 2009/06/23 D:\cygwin\bin\cyghistory7.dll 270k 2009/05/07 D:\cygwin\bin\cygicons-0.dll 981k 2009/05/30 D:\cygwin\bin\cygiconv-2.dll 31k 2005/11/20 D:\cygwin\bin\cygintl-3.dll 31k 2009/04/03 D:\cygwin\bin\cygintl-8.dll 5k 2009/06/18 D:\cygwin\bin\cyglsa.dll 9k 2009/06/18 D:\cygwin\bin\cyglsa64.dll 21k 2009/03/01 D:\cygwin\bin\cygmenu-8.dll 21k 2009/03/27 D:\cygwin\bin\cygmenu-9.dll 211k 2009/06/06 D:\cygwin\bin\cygmp-3.dll 66k 2009/03/01 D:\cygwin\bin\cygncurses++-8.dll 334k 2009/03/27 D:\cygwin\bin\cygncurses++-9.dll 237k 2009/03/01 D:\cygwin\bin\cygncurses-8.dll 164k 2009/03/27 D:\cygwin\bin\cygncurses-9.dll 11k 2009/03/01 D:\cygwin\bin\cygpanel-8.dll 11k 2009/03/27 D:\cygwin\bin\cygpanel-9.dll 190k 2009/04/17 D:\cygwin\bin\cygpcre-0.dll 7k 2009/04/17 D:\cygwin\bin\cygpcreposix-0.dll 22k 2002/06/09 D:\cygwin\bin\cygpopt-0.dll 155k 2009/06/23 D:\cygwin\bin\cygreadline6.dll 162k 2009/06/23 D:\cygwin\bin\cygreadline7.dll 66k 2009/03/27 D:\cygwin\bin\cygtic-9.dll 64k 2009/03/02 D:\cygwin\bin\cygz.dll 2376k 2009/06/18 D:\cygwin\bin\cygwin1.dll Cygwin DLL version info: DLL version: 1.7.0 DLL epoch: 19 DLL old termios: 5 DLL malloc env: 28 Cygwin conv: 181 API major: 0 API minor: 210 Shared data: 5 DLL identifier: cygwin1 Mount registry: 3 Cygwin registry name: Cygwin Program options name: Program Options Cygdrive default prefix: Build date: Thu Jun 18 12:51:49 CEST 2009 Shared id: cygwin1S5 Warning: There are multiple cygwin1.dlls on your path Can't find the cygrunsrv utility, skipping services check. Cygwin Package Information Package Version _update-info-dir 00826-1 alternatives 1.3.30c-10 ash 20040127-4 base-cygwin 2.0-1 base-files 3.8-4 base-passwd 3.1-1 bash 3.2.49-22 binutils
Re: fresh 1.7, bash fails with STATUS_ACCESS_VIOLATION
Moving to this thread: Vincent R. wrote: >> I backed down on bash version which required install of libreadline6. >> >> bash still fails. This is on NT4. >> >> Maybe I need a different combination of binutils, libreadline, and bash. > I >> will play with this for a bit. >> >> Jerry > > I have installed new binutils and previous bash version and now it works > for me. > > > I am not having the same results so I am going to delete all and start fresh > > again. Fresh install still broken with backing down one rev on bash and using libreadline6. Jerry -- 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] [1.7] Updated: binutils-2.19.51-1
Vincent R. wrote: I backed down on bash version which required install of libreadline6. bash still fails. This is on NT4. Maybe I need a different combination of binutils, libreadline, and bash. I will play with this for a bit. Jerry I have installed new binutils and previous bash version and now it works for me. I am not having the same results so I am going to delete all and start fresh again. Jerry -- 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] [1.7] Updated: binutils-2.19.51-1
Dave Korn wrote: --- snip --- This is not a binutils bug report any longer! Try downgrading bash; there's a problem with the new libreadline7 build, which hopefully a respin with gcc-4 and this new binutils will fix. cheers, DaveK I backed down on bash version which required install of libreadline6. bash still fails. This is on NT4. Maybe I need a different combination of binutils, libreadline, and bash. I will play with this for a bit. Jerry -- 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] [1.7] Updated: binutils-2.19.51-1
Christopher Faylor wrote: I've made a new version of binutils available for installation. This is a much-needed, much-delayed refresh against the current CVS. It should work better with gcc-4. The list of changes is included after the unsubscribe info. This is a list of changes from three binutils NEWS files. Some entries may not be pertinent to Cygwin. Thanks Christopher, this was much needed. Best regards, Jerry -- 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
Bash initialization w/cygwin-1.7
I am making the switch to 1.7. I started with a clean windows (nt4) environment and went through the usual run of setup-1.7 downloaded today. All appears fine, but bash does not get initialized. pwd is /usr/bin path is not set home directory is not created These are all taken care of nicely for the user with cygwin 1.5 I think this is a bug unless I am missing something in the install process. Please advise. Jerry -- 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-1.7 on WinNT Workstation 4.0
Christopher Faylor wrote: On Sun, Jun 21, 2009 at 06:45:48AM -0700, Jerry DeLisle wrote: Current 1.7 documentation states that Cygwi-1.7 will not work on Win 95, 98, or Me. Does this also include Win NT? I tried installing on Win NT and I get the following when trying to open a terminal. 78 [main] bash 139 tty_list::allocate: No tty allocated Any help or clarification would be appreciated. Please provide cygcheck output. Found the problem with cygcheck. I had a duplicate cygwin1.dll in path. Thanks, Jerry -- 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
Cygwin-1.7 on WinNT Workstation 4.0
Current 1.7 documentation states that Cygwi-1.7 will not work on Win 95, 98, or Me. Does this also include Win NT? I tried installing on Win NT and I get the following when trying to open a terminal. 78 [main] bash 139 tty_list::allocate: No tty allocated Any help or clarification would be appreciated. Jerry -- 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: bash bug, setup, or permissions?
Jerry DeLisle wrote: While attempting to run the gcc testsuite today I am getting this error. Bash appears to then lock up. If I attempt to close the terminal window, I get a windows error dialog about failing to respond. If I select to end the hung task, it terminates and the bash command prompt comes back. Any help appreciated. Jerry Additional info: $ cd / je...@winnt / $ less bash.exe.stackdump Exception: STATUS_STACK_OVERFLOW at eip=61126F82 eax=0046F080 ebx=0022CCA6 ecx=00032C00 edx=00630069 esi=00A0 edi=0001 ebp=00224C58 esp=001F4BF8 program=C:\cygwin\bin\bash.exe, pid 222, thread main cs=001B ds=0023 es=0023 fs=0038 gs= ss=0023 Stack trace: Frame Function Args 00224C58 61126F82 (005C0030, 00610050, 00740072, 00740069) 49110 [main] bash 222 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIO LATION 55869 [main] bash 222 _cygtls::handle_exceptions: Error while dumping state (p robably corrupted stack) bash.exe.stackdump (END) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
bash bug, setup, or permissions?
While attempting to run the gcc testsuite today I am getting this error. Bash appears to then lock up. If I attempt to close the terminal window, I get a windows error dialog about failing to respond. If I select to end the hung task, it terminates and the bash command prompt comes back. Any help appreciated. Jerry Test Run By jerry on Sun Feb 8 18:29:32 2009 Native configuration is i686-pc-cygwin === gfortran tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for targe t. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /home/jerry/gcc/gcc44/gcc/testsuite/config/default.exp as tool-and-target- specific interface file. Running /home/jerry/gcc/gcc44/gcc/testsuite/gfortran.dg/debug/debug.exp ... 472 [main] sh 84 C:\cygwin\bin\sh.exe: *** fatal error - can't create tty_li st::mutex 'cygwin1S4.tty_list::mutex.0', Win32 error 6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cygwin gfortran 4.4 build
I have updated the Cygwin build of gfortran 4.4 experimental on the gfortran wiki to 10-19-2008 trunk. This is not a regular Cygwin package. http://gcc.gnu.org/wiki/GFortranBinaries Please let me know if anyone has any problems with it. Best regards, Jerry -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: UTF-8 Terminal - How to?
Jason Pyeron wrote: We use utf teraterm which has a cygterm built in. http://www.google.com/search?source=ig&hl=en&rlz=&q=teraterm+utf http://ttssh2.sourceforge.jp/ -- Thank you very much. This looks like it will work well. Jerry -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
UTF-8 Terminal - How to?
Hi folks, I am implementing UTF-8 encoding capability for gfortran. I can test fine on linux platforms because the gnome-terminal has UTF-8 capability built in. How can I achieve similar capability in a Cygwin terminal so that I can test the gfortran Cygwin build? The gfortran library code paths are different on Cygwin because of things like CR-LF line ends, so I really should test it. Good suggestions welcome. Jerry -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Memory leak problem reported with gfortran
Corinna Vinschen wrote: On Feb 5 17:23, Jerry DeLisle wrote: Corinna Vinschen wrote: On Feb 4 17:24, Christopher Faylor wrote: On Mon, Feb 04, 2008 at 01:25:27PM -0800, Jerry DeLisle wrote: The test also appears very clean on Linux. The gfortran library is implemented in C. I need to examine some dumps from the compiler and I will get back with you off list if I don't spot the problem. I am fairly certain that Corinna would want to keep any correspondence on-list. Yup, that's right. OK, we have isolated the problem now. Confirming its in the libgfortran. The reason we did not see it on Linux is because we just did not run out of memory yet and when the test program completes, it does actually free what was allocated. We are failing to reuse an already allocated block so we were allocating a new one for every single WRITE to the string. Thanks for all your help. Thanks for letting us know. Corinna An interim patch to gcc 4.3 has been committed to svn. see gcc bugzilla pr35063 for details. It was a mutex lock issue. Not closing the handle after the lock was no longer needed. Jerry -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Memory leak problem reported with gfortran
Corinna Vinschen wrote: On Feb 4 17:24, Christopher Faylor wrote: On Mon, Feb 04, 2008 at 01:25:27PM -0800, Jerry DeLisle wrote: The test also appears very clean on Linux. The gfortran library is implemented in C. I need to examine some dumps from the compiler and I will get back with you off list if I don't spot the problem. I am fairly certain that Corinna would want to keep any correspondence on-list. Yup, that's right. OK, we have isolated the problem now. Confirming its in the libgfortran. The reason we did not see it on Linux is because we just did not run out of memory yet and when the test program completes, it does actually free what was allocated. We are failing to reuse an already allocated block so we were allocating a new one for every single WRITE to the string. Thanks for all your help. Jerry -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Memory leak problem reported with gfortran
Dave Korn wrote: On 04 February 2008 22:25, Christopher Faylor wrote: On Mon, Feb 04, 2008 at 01:25:27PM -0800, Jerry DeLisle wrote: The test also appears very clean on Linux. The gfortran library is implemented in C. I need to examine some dumps from the compiler and I will get back with you off list if I don't spot the problem. I am fairly certain that Corinna would want to keep any correspondence on-list. Also, in case it isn't clear, Cygwin malloc is just Doug Lea's version of malloc v2.8.3 with very few changes. cgf Since I'm currently building gcc4 to check out some autogen-vs-fixinc changes, I'll build fortran as well and take a look at the testcase too. I'd guess that's it's probably a libgfortran problem, since it affects both cygwin *and* mingw, but I'll take a look at it under a debugger and see if I can help. Thanks Dave, I think it is in libgfortran as well. I am still hunting. I believe it is specific to internal units. In other words, writing to a character string. I eliminated all other IO operations from the test case and it fails on some sort of memory allocation. Jerry -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Memory leak problem reported with gfortran
Corinna Vinschen wrote: On Feb 3 11:24, Jerry DeLisle wrote: I have confirmed this problem on Cygwin reported here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063 I am not very familiar with the windows environment. Having patched most of the gfortran I/O library in the last 2-3 years I can say that we do a lot of memory allocation for I/O. On Linux based systems we do not see any issues (checked with valgrind). This problem acts like a failure to free memory. I do not know what is meant by the term "handle" other than a pointer to an allocated block of Handles are the Windows equivalent to Posix descriptors. They are references to a lot of different OS objects, like files, sockets, semaphores, processes, threads, etc. They are *not* references to memory regions. When you reserve memory the standard way, you only get an address, not a handle. However, handles are also potentially references to shared memory objects, in Windows terminology called "file mappings"(*), and thus they are created when you call mmap() in Cygwin. mmap() OTOH is called by malloc() *iff* the malloc request is > 256K. Those of you most familiar with the Windows environment could perhaps help here.Is this a bug in Cygwin memory management? We never can be sure it's not a bug in the DLL, but if a simple loop like this would fail all the time, we would probably have more serious problems. I will be happy to provide additional information as soon as I know what is pertinent. I tested the test application with g77 and it runs fine. Memory usage, VM size, and handle count are constant in every loop. No memory leak, no handle leak. It might be a bug in the fortran lib, after all. I'm not a fortran expert so I don't know what happens under the hood of the write() call. If you can break down the test application and especially the write() call into plain C, it might be quite instructive. Corinna (*) To emulate mmap() you have to do two calls in Windows: HANDLE map_handle = CreateFileMapping (file_handle, ...); void *address = MapViewOfFile(map_handle, ); So you have a handle to the "file mapping" and an arbitrary number of addresses to "views". Corinna, The test also appears very clean on Linux. The gfortran library is implemented in C. I need to examine some dumps from the compiler and I will get back with you off list if I don't spot the problem. I am fairly certain we have an ambiguity in the gfortran library at this point. The test is not doing file I/O. We are WRITEing to a 1 byte internal string that has to be allocated in memory. Jerry -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Memory leak problem reported with gfortran
Angelo Graziosi wrote: Jerry DeLisle wrote: I have confirmed this problem on Cygwin reported here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063 I do not know if this can help, but... Building the above test with G95, it does not fail! If I have understood it, I have pressed 1 ENTER without problem! With GFortran (4.2.3, at the moment) it fails, after a few ENTER, with: --- 3 [main] test 3956 C:\cygwin\tmp\test.exe: *** fatal error - couldn't allo cate muto 'mmap_guard', Win32 error 1816 Hangup --- In some cases, the PC 'frezees'! I have continued my testing here and I am seeing this with valgrind on linux. When I was running the 1 loops I did not see these errors roll by upfront initially. ==25454== Conditional jump or move depends on uninitialised value(s) ==25454==at 0x4333F1: strlen (in /home/jerry/prs/pr35063/a.out) ==25454==by 0x45DE74: fillin_rpath (in /home/jerry/prs/pr35063/a.out) ==25454==by 0x45FC35: _dl_init_paths (in /home/jerry/prs/pr35063/a.out) ==25454==by 0x439CDE: _dl_non_dynamic_init (in /home/jerry/prs/pr35063/a.out) ==25454==by 0x43A3DA: __libc_init_first (in /home/jerry/prs/pr35063/a.out) ==25454==by 0x414CF5: (below main) (in /home/jerry/prs/pr35063/a.out) ==25454== ==25454== Conditional jump or move depends on uninitialised value(s) ==25454==at 0x4333BD: strlen (in /home/jerry/prs/pr35063/a.out) ==25454==by 0x408087: write_integer (write.c:612) ==25454==by 0x40AEDD: _gfortrani_list_formatted_write (write.c:785) ==25454==by 0x400330: MAIN__ (in /home/jerry/prs/pr35063/a.out) ==25454==by 0x40043B: main (fmain.c:21) The end of the run shows: ==25454== Use of uninitialised value of size 8 ==25454==at 0x41AB57: exit (in /home/jerry/prs/pr35063/a.out) ==25454== ==25454== ERROR SUMMARY: 12 errors from 3 contexts (suppressed: 0 from 0) ==25454== malloc/free: in use at exit: 0 bytes in 0 blocks. ==25454== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==25454== For counts of detected errors, rerun with: -v ==25454== All heap blocks were freed -- no leaks are possible. But no memory leaks. I don't know if this is related or not. I will keep digging. Jerry -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Memory leak problem reported with gfortran
Dave Korn wrote: On 03 February 2008 19:24, Jerry DeLisle wrote: I have confirmed this problem on Cygwin reported here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063 Those of you most familiar with the Windows environment could perhaps help here. Is this a bug in Cygwin memory management? Are you using cygwin as anything other than a shell to launch mingw32 compilers and the mingw32 applications they build? cheers, DaveK This is a locally built gfortran on Cygwin using the usual Cygwin bash shell. $ gfc -v Using built-in specs. Target: i686-pc-cygwin Configured with: ../gcc43/configure --prefix=/usr/local/gfortran --enable-languages=c,fortran --disable-bootstrap --enable-threads=posix --enable-sjlj-exceptions --enable-version-specific-runtime-libs --enable-nls --disable-libmudflap --disable-shared --disable-win32-registry --with-system-zlib --enable-checking=release --enable-werror --without-included-gettext --without-x --enable-libgomp Thread model: posix gcc version 4.3.0 20080128 (experimental) [trunk revision 131899] (GCC) Jerry -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Memory leak problem reported with gfortran
I have confirmed this problem on Cygwin reported here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063 I am not very familiar with the windows environment. Having patched most of the gfortran I/O library in the last 2-3 years I can say that we do a lot of memory allocation for I/O. On Linux based systems we do not see any issues (checked with valgrind). This problem acts like a failure to free memory. I do not know what is meant by the term "handle" other than a pointer to an allocated block of memory. Those of you most familiar with the Windows environment could perhaps help here. Is this a bug in Cygwin memory management? I will be happy to provide additional information as soon as I know what is pertinent. I have latest Cygwin as of about two weeks ago and I can provide a gfortran binary if needed. Regards, Jerry -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin updates
Angelo Graziosi wrote: Jerry DeLisle wrote: > Is there a way to run a script to check for updates, download them, > and install? I download the updates using a combination of a my script (getcurr.sh) and one (clean_setup.pl) found following the Cygwin lists. See the attachment in [1]. In any case, I install with setu.exe and do not know other simple methods. Cheers, Angelo. Thanks Angelo -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cygwin updates
I ssh into my remote Cygwin box. Is there a way to run a script to check for updates, download them, and install? Thanks, Jerry -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Struggling to setup sshd with Windows Vista
Brian Dessent wrote: Kevin Hilton wrote: Let me just make sure I know what you are telling me to do, since I already did this and it didnt make a difference. As an administrator, I: 1. Delete the sshd user -- Ok I manually edited the /etc/passwd file and deleted this user No, I mean delete the *user*, not a line in a passwd file. Windows has a notion of user accounts, Cygwin does not; it just mirrors the Windows database in the passwd and group file. So deleting a user means doing it in Windows, through the control panel, or with "net user". On 2k3 and greater (including Vista) ssh-host-config should have created both a sshd (for privsep) and a sshd_server user (for running the service), so you'd want to run "net user sshd /delete" and "net user sshd_server /delete". You can run "net user" to see the list of Windows user accounts. If you don't see these user accounts it means the ssh-host-config script wasn't able to create them, which is probably the underlying cause. The reason for suggesting to delete these users is that ssh-host-config won't recreate them if they already exist, so if they exist and are setup wrong, ssh-host-config can't help you. I was having trouble as well, only on an XP system. This last hint worked for me. (net user sshd /delete) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Failure in building GFortran on Cygwin
Angelo Graziosi wrote: Corinna Vinschen wrote: I've made another version of the Cygwin DLL, 1.5.25-3 With this new version of Cygwin, the problem, with which I started this thread, seems to be solved! Now the build of GFortran (20071201, trunk 130556) is completed without problems. Many thanks, Angelo. Yes, many thanks Corinna. Jerry -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Failure in building GFortran on Cygwin
Corinna Vinschen wrote:
[Forgot to CC the fortran list. Re-sending...]
On Nov 29 17:05, Jerry DeLisle wrote:
Angelo Graziosi wrote:
/tmp/gcc/libgfortran/intrinsics/system_clock.c: In function
'system_clock_4':
/tmp/gcc/libgfortran/intrinsics/system_clock.c:67: error: storage size of
'tzp' isn't known
/tmp/gcc/libgfortran/intrinsics/system_clock.c:67: warning: unused
variable 'tzp'
/tmp/gcc/libgfortran/intrinsics/system_clock.c: In function
'system_clock_8':
/tmp/gcc/libgfortran/intrinsics/system_clock.c:130: error: storage size of
'tzp' isn't known
/tmp/gcc/libgfortran/intrinsics/system_clock.c:130: warning: unused
variable 'tzp'
[...]
The Cygwin version is 1.5.25-2 (exp.).
I can confirm this. I saw it last wekend trying to do my regular cygwin
build of gfortran for the wiki. The build died and I assumed I did
something wrong and was going to try back later.
Well this is definitely a regression somewhere. Its not on the gfortran
side which has not touched that file for several months. It could be
something broke in the configure for cygwin. The error occurs in a
conditional comapile:
#if defined(HAVE_SYS_TIME_H) && defined(HAVE_GETTIMEOFDAY)
I will open a PR to track this.
A simple testcase would have been much more helpful.
Here is code with the problem: Not super simple, but I think you can follow it.
Thanks for hellp
void
system_clock_4(GFC_INTEGER_4 *count, GFC_INTEGER_4 *count_rate,
GFC_INTEGER_4 *count_max)
{
GFC_INTEGER_4 cnt;
GFC_INTEGER_4 rate;
GFC_INTEGER_4 mx;
#if defined(HAVE_SYS_TIME_H) && defined(HAVE_GETTIMEOFDAY)
struct timeval tp1;
struct timezone tzp;
if (sizeof (tp1.tv_sec) < sizeof (GFC_INTEGER_4))
internal_error (NULL, "tv_sec too small");
if (gettimeofday(&tp1, &tzp) == 0)
{
GFC_UINTEGER_4 ucnt = (GFC_UINTEGER_4) tp1.tv_sec * TCK;
ucnt += (tp1.tv_usec + 50 / TCK) / (100 / TCK);
if (ucnt > GFC_INTEGER_4_HUGE)
cnt = ucnt - GFC_INTEGER_4_HUGE - 1;
else
cnt = ucnt;
rate = TCK;
mx = GFC_INTEGER_4_HUGE;
}
else
{
if (count != NULL)
*count = - GFC_INTEGER_4_HUGE;
if (count_rate != NULL)
*count_rate = 0;
if (count_max != NULL)
*count_max = 0;
return;
}
#elif defined(HAVE_TIME_H)
GFC_UINTEGER_4 ucnt;
if (sizeof (time_t) < sizeof (GFC_INTEGER_4))
internal_error (NULL, "time_t too small");
ucnt = time (NULL);
if (ucnt > GFC_INTEGER_4_HUGE)
cnt = ucnt - GFC_INTEGER_4_HUGE - 1;
else
cnt = ucnt;
mx = GFC_INTEGER_4_HUGE;
#else
cnt = - GFC_INTEGER_4_HUGE;
mx = 0;
#endif
if (count != NULL)
*count = cnt;
if (count_rate != NULL)
*count_rate = TCK;
if (count_max != NULL)
*count_max = mx;
}
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Failure in building GFortran on Cygwin
Angelo Graziosi wrote:
For the sake of completeness I want to flag the following.
Building GFortran CVS 20071129 trunk 130516 on Cygwin it fails in this
way:
...
libtool: compile: /tmp/gcc/build/./gcc/xgcc -B/tmp/gcc/build/./gcc/
-B/usr/local/gfortran/i686-pc-cygwin/bin/
-B/usr/local/gfortran/i686-pc-cygwin/lib/ -isystem
/usr/local/gfortran/i686-pc-cygwin/include -isystem
/usr/local/gfortran/i686-pc-cygwin/sys-include -DHAVE_CONFIG_H -I.
-I/tmp/gcc/libgfortran -I. -iquote/tmp/gcc/libgfortran/io
-I/tmp/gcc/libgfortran/../gcc -I/tmp/gcc/libgfortran/../gcc/config
-I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g
-O2 -MT system_clock.lo -MD -MP -MF .deps/system_clock.Tpo -c
/tmp/gcc/libgfortran/intrinsics/system_clock.c -o system_clock.o
/tmp/gcc/libgfortran/intrinsics/system_clock.c: In function
'system_clock_4':
/tmp/gcc/libgfortran/intrinsics/system_clock.c:67: error: storage size of
'tzp' isn't known
/tmp/gcc/libgfortran/intrinsics/system_clock.c:67: warning: unused
variable 'tzp'
/tmp/gcc/libgfortran/intrinsics/system_clock.c: In function
'system_clock_8':
/tmp/gcc/libgfortran/intrinsics/system_clock.c:130: error: storage size of
'tzp' isn't known
/tmp/gcc/libgfortran/intrinsics/system_clock.c:130: warning: unused
variable 'tzp'
make[3]: *** [system_clock.lo] Error 1
make[3]: Leaving directory `/tmp/gcc/build/i686-pc-cygwin/libgfortran'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/gcc/build/i686-pc-cygwin/libgfortran'
make[1]: *** [all-target-libgfortran] Error 2
make[1]: Leaving directory `/tmp/gcc/build'
make: *** [all] Error 2
The build was configured (as always):
${gcc_dir}/configure --prefix=${prefix_dir} \
--exec-prefix=${prefix_dir} \
--sysconfdir=${prefix_dir}/etc \
--libdir=${prefix_dir}/lib \
--libexecdir=${prefix_dir}/lib \
--mandir=${prefix_dir}/share/man \
--infodir=${prefix_dir}/share/info \
--enable-languages=c,fortran \
--enable-bootstrap \
--enable-decimal-float=bid \
--enable-libgomp \
--enable-threads \
--enable-sjlj-exceptions \
--enable-version-specific-runtime-libs \
--enable-nls \
--enable-checking=release \
--disable-fixed-point \
--disable-libmudflap \
--disable-shared \
--disable-win32-registry \
--with-system-zlib \
--without-included-gettext \
--without-x
The Cygwin version is 1.5.25-2 (exp.).
I can confirm this. I saw it last wekend trying to do my regular cygwin build
of gfortran for the wiki. The build died and I assumed I did something wrong
and was going to try back later.
Well this is definitely a regression somewhere. Its not on the gfortran side
which has not touched that file for several months. It could be something broke
in the configure for cygwin. The error occurs in a conditional comapile:
#if defined(HAVE_SYS_TIME_H) && defined(HAVE_GETTIMEOFDAY)
I will open a PR to track this.
Jerry
Jerry
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
