> Mark Geisert (that's me) wrote: > > I haven't yet diff'd the two cygchecks > > you sent but maybe that'll lead somewhere. > > I've now done that. The 'good' cygcheck shows many more packages installed > than > the 'bad' cygcheck. But the only package version differences I found were for > bzr, find and mercurial; the 'good' cygcheck paradoxically shows earlier > versions for those three packages. Hard to see how those package differences > could matter though. > > About the only thing I can think of, and it's a crazy idea, is that the 'good' > environment, with more packages installed, is somehow supplying something > that's > emulated badly in the 'bad' environment. Figuring out if that's the case > would > involve building your executable with every possible "verbose" switch turned > on > so you can identify exactly where every item going into the executable is > coming > from. Repeated in both 'good' and 'bad' environments. > > Or, you could take heart that you've got a good build you can work with now > and > just run with that. Maybe somebody else has another approach to try. > HTH, > > ..mark >
Yes, the 'good' installation was done Oct. 3 with many more packages than the bad one. Just a week ago I wanted to install cygwin and run my software on other machines, and then I ran into this problem. It's not a paradox that the good installation has earlier package versions since it was installed a month earlier than the bad one :) So, my problem is now to isolate what has changed since then, which is affecting the build of my fortran binary. There is one thing I remember that is different now when I install a required library (grib-api, see post http://cygwin.com/ml/cygwin/2011-10/msg00037.html) I did not experience this hang back one month ago, but I've upgraded gcc since then, and I wonder if the grib_api, and then my software, is affected by this. I will try to rebuild everything with gcc 4.3.4 too se if it helps, and report the result to the list. Cheers