Hi,
I'd been under the impression that I'd need to create a separate
mintty package for cygwin-1.7, but was glad to find that actually
0.3.5-1 is already there. Many packages do have 1.7-specific versions
though, so my question is, under what sorts of circumstances does that
become necessary?
On Mar 13 06:34, Andy Koppe wrote:
Hi,
I'd been under the impression that I'd need to create a separate
mintty package for cygwin-1.7, but was glad to find that actually
0.3.5-1 is already there. Many packages do have 1.7-specific versions
though, so my question is, under what sorts of
Corinna Vinschen wrote:
On Mar 13 06:34, Andy Koppe wrote:
Hi,
I'd been under the impression that I'd need to create a separate
mintty package for cygwin-1.7, but was glad to find that actually
0.3.5-1 is already there. Many packages do have 1.7-specific versions
though, so my question is,
Yaakov (Cygwin/X) wrote:
Some maintainers
That would be me.
have mentioned that they plan to ABI-number-bump their
libraries when they rebuild them with gcc-4.3. Frankly, I think this is
a bad idea, and I'll try my best to explain why. In no particular order:
Everybody is entitled to
Contrary to my earlier reply, I'm now coming round to the opposite point of
view. If it's a choice of flag day vs. version bumps and an incremental
process, I think the pain will be much less if we choose the latter option.
Charles Wilson wrote:
3) -shared-libgcc vs. -static-libgcc. I was
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Charles Wilson wrote:
True. Until all -- or almost all -- of the distro is *slowly* rebuilt
using gcc4 -shared-libgcc. The difference is, it CAN be slow, and
needn't happen all at once on some flag day.
I'm arguing that perhaps it should, just
Hello,
I was having the same problem, but using openbox. Basically, all options
except multiwindow would crash XWin.
I was ready to quit on the problem, when it started working after an upgrade
of the graphics adapter driver.
Maybe you can try it. In my case I use an ATI FireGL 5200, on an HP
CVSROOT:/cvs/src
Module name:src
Changes by: cori...@sourceware.org 2009-03-13 09:33:55
Modified files:
winsup/cygwin : ChangeLog flock.cc
Log message:
* flock.cc: Fix lockf copyright to latest version.
Patches:
CVSROOT:/cvs/src
Module name:src
Changes by: cori...@sourceware.org 2009-03-13 20:49:42
Modified files:
winsup/cygwin : ChangeLog mktemp.cc
Log message:
* mktemp.cc: Remove STABS specific link-time warning. Align copyright
text to upstream.
Patches:
On Mar 12 17:20, Yaakov S wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Corinna Vinschen wrote:
What exactly is this patch fixing? Ok, we get a new error code, but
what for? It's not generated from within Cygwin, so...?
I came across a few packages that used it. This gets
Corinna Vinschen wrote:
This is very Linux device specific and this never occurs on Cygwin.
What about just defining this error code to some arbitrary value like
#ifdef __CYGWIN__
#define ESTRPIPE
#endif
I like it. If there are any other errno constants supported by Linux
but not
On Fri, Mar 13, 2009 at 06:10:48AM -0600, Warren Young wrote:
Corinna Vinschen wrote:
This is very Linux device specific and this never occurs on Cygwin.
What about just defining this error code to some arbitrary value like
#ifdef __CYGWIN__
#define ESTRPIPE
#endif
I like it.
Christopher Faylor wrote:
Defining a unique value means that, if we do decide at some point to add
functionality which utilizes that errno the will be no need to recompile
the application.
If you think Cygwin might at some point learn to send certain errnos,
they should use low values, as the
Warren Young skrev:
Corinna Vinschen wrote:
This is very Linux device specific and this never occurs on Cygwin.
What about just defining this error code to some arbitrary
value like
#ifdef __CYGWIN__
#define ESTRPIPE
#endif
I like it. If there are any other errno
On Mar 13 10:50, Christopher Faylor wrote:
On Fri, Mar 13, 2009 at 06:10:48AM -0600, Warren Young wrote:
Corinna Vinschen wrote:
This is very Linux device specific and this never occurs on Cygwin.
What about just defining this error code to some arbitrary value like
#ifdef __CYGWIN__
Peter Rosin wrote:
Consider code like this:
switch (errno) {
case -ESTRPIPE:
capers();
break;
case -EFOOBAR:
cucumber();
break;
}
The core assumption is that neither can happen. Not now, not ever.
If that's true, the worst you can say against it is that gcc
On Fri, Mar 13, 2009 at 09:59:49PM +0100, Corinna Vinschen wrote:
On Mar 13 10:50, Christopher Faylor wrote:
On Fri, Mar 13, 2009 at 06:10:48AM -0600, Warren Young wrote:
Corinna Vinschen wrote:
This is very Linux device specific and this never occurs on Cygwin.
What about just defining
Warren Young skrev:
Peter Rosin wrote:
Consider code like this:
switch (errno) {
case -ESTRPIPE:
capers();
break;
case -EFOOBAR:
cucumber();
break;
}
The core assumption is that neither can happen. Not now, not ever.
If that's true, the worst you can
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 here? I don't know what sort of
Yaakov (Cygwin/X) wrote:
Dave Korn wrote:
Plain C applications will, by default, be linked statically against libgcc as
previously. To link against the shared libgcc DLL, '-shared-libgcc' must be
manually specified on the command-line.
1) What exactly are the pros and cons of this? IOW,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
First, I must say, many thanks for all your hard work on gcc4!
Dave Korn wrote:
No reason that I can think of in general. The only case would be when you
really need to override intra-libstdc++ calls to operators new and delete, in
which case
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 here? I
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
much of a
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 4.4
Corinna,
thanks for your feedback!
2009/3/12 Corinna Vinschen corinna-cyg...@cygwin.com:
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
--- 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 the
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
Michael Hennebry henne...@web.cs.ndsu.nodak.edu wrote:
On Thu, 12 Mar 2009, Wilfried wrote:
Michael Hennebry henne...@web.cs.ndsu.nodak.edu 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
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.
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 12 | cat
SUCCESS
ad...@ubik /tmp/fortran/hw
$ ./hw 21 | cat
ad...@ubik /tmp/fortran/hw
$
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 debugging session
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:
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 debugging may
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 prove
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:
From
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 files.
-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
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 - Visual
On Fri, 13 Mar 2009, Wilfried wrote:
Michael Hennebry henne...@web.cs.ndsu.nodak.edu wrote:
On Thu, 12 Mar 2009, Wilfried wrote:
Michael Hennebry henne...@web.cs.ndsu.nodak.edu wrote:
On Mon, 9 Mar 2009, Michael Hennebry wrote:
...
I've discovered that if I kill the demon,
I still get
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 a
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++ -g
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.
--
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
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
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
$ echo
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,
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
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
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
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 ]]
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
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
$
--- On Wed, 3/11/09, Dave Korn dave.korn.cyg...@googlemail.com 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
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:
$
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
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
Nuzhna Pomoshch writes:
--- On Wed, 3/11/09, Dave Korn x...@yyy.zzz 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
Mark Geisert wrote:
Nuzhna Pomoshch writes:
--- On Wed, 3/11/09, Dave Korn x...@yyy.zzz 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
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
60 matches
Mail list logo
