Marco Atzeri wrote:
> it seems a 1.7 specific fault. On cygwin 1.5 it works; I never checked
> before :-(
Odd! It fails for me on both. (You did update gcc-4 on *both* your
installations, right?)
> is it possible that Cygwin-1.7 is fooled by the not like-C standard output
> ?
>
> "GFORTRAN_
--- Sab 14/3/09, Dave Korn ha scritto:
> Da: Dave Korn
> Oggetto: Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
> A: cygwin@cygwin.com
> Data: Sabato 14 marzo 2009, 04:04
> Angelo Graziosi wrote:
> > Still continuing to test...
> >
> > Marco Atzeri wrote:
> >> if I had ./test_
Mark Geisert wrote:
> Nuzhna Pomoshch writes:
>> --- On Wed, 3/11/09, Dave Korn wrote:
>>> It sounds very much like BLODA interference:
>> I run absolutely no anti-virus (or firewall) on that machine.
>
> Please consider reading up on BLODA; although anti-virus is the most common
> form
> of B
Nuzhna Pomoshch writes:
> --- On Wed, 3/11/09, Dave Korn wrote:
Please don't quote raw email addresses. It only feeds the spammers.
> > It sounds very much like BLODA interference:
> > your on-access anti-virus scanner may have kept an open
> > handle on it after setup.exe had closed its own.=A
Vin Shelton wrote:
> Charles Wilson wrote:
>> Just for grins, could you rebuild zsh against libncurses9 -- but this
>> time use gcc3? cygiconv-2 and cygncurses-9 use the static gcc-3.4.4
>> libgcc.a, but you are apparently using the gcc-4.3.2 shared libgcc.
>>
>> I just wonder if that presents an
Vin Shelton wrote:
> How can I ascertain what entry point is not being found?
You need depends.exe.
http://www.dependencywalker.com/
cheers,
DaveK
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation
Charles Wilson wrote:
Vin Shelton wrote:
When I build the latest zsh sources on Cygwin 1.7 using
ncurses8-5.5.3, I get a working zsh. When I build the same zsh
sources against ncurses9-5.7-13, although the build completes
successfully, the executable will not run:
$ /usr/local/zsh-2009-03-11/b
Angelo Graziosi wrote:
> Still continuing to test...
>
> Marco Atzeri wrote:
>> if I had ./test_program I see the output on the screen but
>>
>> ./test_program > test_output
>> leave test_output empty.
>
> If I build that tst case with:
>
> gfortran-4 test_program.F -o test_program
>
> then
>
--- On Wed, 3/11/09, Dave Korn wrote:
> It sounds very much like BLODA interference:
> your on-access anti-virus scanner may have kept an open
> handle on it after setup.exe had closed its own.=A0 It's
> known to occasionally happen with some AVs.
I run absolutely no anti-virus (or firewall) on
Still continuing to test...
Marco Atzeri wrote:
if I had
./test_program
I see the output on the screen but
./test_program > test_output
leave test_output empty.
If I build that tst case with:
gfortran-4 test_program.F -o test_program
then
$ ./test_program.exe
SUCCESS
$ ./test_program.ex
setup.exe kept crashing when trying to update libncurses-devel.
Worse, Event Viewer usually said that it was a different fault address
each time.
After much fixing of file ownerships, searching of mailing list
archives, use of Process Monitor, saving PM's output to disk to search
for something su
The proj package supplies a cartographic projection library and
utilities. It is based on the 'Proj.4' distribution at
http://trac.osgeo.org/proj/, not the friendly 'libproj4' fork
at http://members.verizon.net/~gerald.evenden/proj4/.
This is a routine update.
[[ compiled using gcc-3.4.4-999 ]]
GeoTIFF represents an effort by over 160 different remote sensing,
GIS, cartographic, and surveying related companies and organizations
to establish a TIFF based interchange format for georeferenced raster
imagery. This package provides a library and utilities for
manipulating images in this format
The proj package supplies a cartographic projection library and
utilities. It is based on the 'Proj.4' distribution at
http://trac.osgeo.org/proj/, not the friendly 'libproj4' fork
at http://members.verizon.net/~gerald.evenden/proj4/.
This is a routine update.
[[ compiled using gcc-3.4.4-999 ]]
GeoTIFF represents an effort by over 160 different remote sensing,
GIS, cartographic, and surveying related companies and organizations
to establish a TIFF based interchange format for georeferenced raster
imagery. This package provides a library and utilities for
manipulating images in this format
A huge number (575) of 'man' pages, that reference other man pages using a
'.so' (source include) reference, fail to work because the plain text files
have the '.gz' extension appended without actually being gzipped. Could
this be due to a mishap in or with the 'cygport' package?
Each reference a
I sense a problem with this picture.
you dont HAVE to compile Mono under Cygwin. there's no reason. a)
there's precompiled binaries for Win32 and Win64 b) with sauce you can
build with Msbuild.
--
Morgan gangwere
"Space does not reflect society, it expresses it." -- Castells, M.,
Space of Flows
Vin Shelton wrote:
> When I build the latest zsh sources on Cygwin 1.7 using
> ncurses8-5.5.3, I get a working zsh. When I build the same zsh
> sources against ncurses9-5.7-13, although the build completes
> successfully, the executable will not run:
>
> $ /usr/local/zsh-2009-03-11/bin/zsh -f
> $
Greetings -
When I build the latest zsh sources on Cygwin 1.7 using
ncurses8-5.5.3, I get a working zsh. When I build the same zsh
sources against ncurses9-5.7-13, although the build completes
successfully, the executable will not run:
$ /usr/local/zsh-2009-03-11/bin/zsh -f
$ echo $?
127
My gue
I have been using Cygwin for years, and I have it installed on two Windows XP
and a Windows Vista systems.
Today, I tried to install it on my Windows XP system at work. I downloaded
the entire release ("Download without Installing") and copied this to a CD.
I got the release from kernel.org. I h
Dave Korn wrote:
So I think you should check for a bug in the --disable-debug
configure option. ...it seems that the actual overall size of the
stripped exes should be pretty much the same betwen the two compilers
Indeed! I have flagged the thing to the Mrxvt guys.
Thanks a lot,
Angelo.
--
Un
Charles Wilson wrote:
> It looks like CC='gcc -static-libgcc' (or, in our case for now,
> -shared-libgcc and CXX='g++ -shared-libgcc -shared-libstdc++' etc) is the
> "solution".
Shouldn't need anything for CXX, as the default shared libstdc++ implies
shared libgcc:
dkad...@ubik /tmp/hw
$ g++
Yaakov (Cygwin/X) wrote:
> Dave Korn wrote:
>> Can you take this one upstream for us? LT really ought to know about these
>> two options, they're not even Cygwin-specific at all.
>
> Chuck would probably be a better candidate for that, as he works with
> them already.
No, not really. I've had
On Fri, 13 Mar 2009, Wilfried wrote:
Michael Hennebry wrote:
On Thu, 12 Mar 2009, Wilfried wrote:
Michael Hennebry wrote:
On Mon, 9 Mar 2009, Michael Hennebry wrote:
...
I've discovered that if I kill the demon,
I still get timeout from the outside,
but connection refused locally.
If y
On Thu, 12 Mar 2009, Corinna Vinschen wrote:
> It seems I introduced this problem with the new advisory file locking
> code in 1.7. I just applied a patch which is supposed to fix your
> problem. Please give it a try.
Fixed. Thanks!
--
Brian Ford
Staff Realtime Software Engineer
VITAL - Visu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dave Korn wrote:
> Can you take this one upstream for us? LT really ought to know about these
> two options, they're not even Cygwin-specific at all.
Chuck would probably be a better candidate for that, as he works with
them already.
Yaakov
---
Dave Korn wrote:
> Tim Prince wrote:
>>
>> http://sites.google.com/site/tprincesite/levine-callahan-dongarra-vectors
>
> gcc: f90_cputime.c: No such file or directory
> I notice you're compiling with -fopenmp; does removing it help any?
Sorry, all these months and no one ever missed those .c f
Angelo Graziosi wrote:
> Dave Korn wrote:
>
>> Can you show me the "objdump -h" output for both?
>
> It seems that here there is a problem. I have build with the same build
> script and without debug info, but, for what I can understand, with gcc4
> the debug info are still there. To reproduce:
Dave Korn wrote:
> Christopher Faylor wrote:
>> On Fri, Mar 13, 2009 at 09:59:44AM +0100, ludo wrote:
>>> /netrel/src/gdb-6.8-2/gdb/breakpoint.c:5082: internal-error:
>>> expand_line_sal_maybe: Assertion `found' failed.
>>> A problem internal to GDB has been detected,
>>> further debugging may pr
Christopher Faylor wrote:
> On Fri, Mar 13, 2009 at 09:59:44AM +0100, ludo wrote:
>> $ gdb ./setup.exe
>> (gdb) start
>> /netrel/src/gdb-6.8-2/gdb/breakpoint.c:5082: internal-error:
>> expand_line_sal_maybe: Assertion `found' failed.
>> A problem internal to GDB has been detected,
>> further deb
Dave Korn wrote:
Can you show me the "objdump -h" output for both?
It seems that here there is a problem. I have build with the same build
script and without debug info, but, for what I can understand, with gcc4
the debug info are still there. To reproduce:
===
On Fri, Mar 13, 2009 at 09:59:44AM +0100, ludo wrote:
> Hi,
>
> I try to debug setup.exe but gdb crashes when I "start" the program
>
> * I get source of setup from CVS (sources.redhat.com:/cvs/cygwin-apps) and
> I build it with
>./doconfigure && make && make install
>
> * I try to start a deb
Dave Korn wrote:
> Marco Atzeri wrote:
>
>> It seems a problem of output redirection with dynamic
>> fortran library
Oh, another clue: it only affects stdout, not stderr-
ad...@ubik /tmp/fortran/hw
$ ./hw 1>&2 | cat
SUCCESS
ad...@ubik /tmp/fortran/hw
$ ./hw 2>&1 | cat
ad...@ubik /tmp/fortr
Marco Atzeri wrote:
> It seems a problem of output redirection with dynamic
> fortran library
> This did not happened with static linked fortran library.
I agree. If anyone has problems with this issue when using fortran, the
workaround for now will be to use "-static" when compiling.
c
Michael Hennebry wrote:
> On Thu, 12 Mar 2009, Wilfried wrote:
>
> > Michael Hennebry wrote:
> >
> >> On Mon, 9 Mar 2009, Michael Hennebry wrote:
> >> ...
> >> I've discovered that if I kill the demon,
> >> I still get timeout from the outside,
> >> but connection refused locally.
> >
> > If yo
Hi,
I try to debug setup.exe but gdb crashes when I "start" the program
* I get source of setup from CVS (sources.redhat.com:/cvs/cygwin-apps)
and I build it with
./doconfigure && make && make install
* I try to start a debugging session :
$ gdb ./setup.exe
GNU gdb 6.8.0.20080328-cvs (cyg
--- Ven 13/3/09, Dave Korn ha scritto:
> Da: Dave Korn
> Oggetto: Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
> A:
> Data: Venerdì 13 marzo 2009, 07:41
> Tim Prince wrote:
> > This doesn't seem to be a magically fully working
> gfortran, such as we
> > had fleetingly with th
Corinna,
thanks for your feedback!
2009/3/12 Corinna Vinschen :
> On Mar 12 17:44, Robert Klemme wrote:
>> The second flock does not start the command as I expect it to be.
>>
>> I am referring to the man page of flock which says this about option -w:
>>
>> Fail (with an exit code of 1) if the l
Tim Prince wrote:
> Dave Korn wrote:
>> Tim Prince wrote:
>>> This doesn't seem to be a magically fully working gfortran, such as we
>>> had fleetingly with the 20090227 snapshot of 4.4.
>> Hi Tim, can you give me a bit of context here?
> I may not have known what to look for, Most 4.3 and
Yaakov (Cygwin/X) wrote:
>> Also, some 3PPs will get warm fuzzies from having one less DLL to
>> distribute, though it hardly makes the resulting executables any more
>> "standalone" ;-)
>
> Since when exactly do we care about 3PPs here? :-)
We don't, hence my smiley!
> Doesn't sound like
Dave Korn wrote:
> Tim Prince wrote:
>> This doesn't seem to be a magically fully working gfortran, such as we
>> had fleetingly with the 20090227 snapshot of 4.4. I'd agree it's likely
>> an "upstream" problem, even if it shows up only on cygwin.
>
> Hi Tim, can you give me a bit of context he
41 matches
Mail list logo