On 4/13/2012 2:38 PM, Pavel Holejsovsky wrote:
gnome 3.2 versions of cygwin packages mentioned in subject suffer from
gobject-introspection bug described in
https://bugzilla.gnome.org/show_bug.cgi?id=672133
The patches fixing the problem were pushed into gnome git repositories,
unfortunately
Hello,
gnome 3.2 versions of cygwin packages mentioned in subject suffer from
gobject-introspection bug described in
https://bugzilla.gnome.org/show_bug.cgi?id=672133
The patches fixing the problem were pushed into gnome git repositories,
unfortunately, they did not make it into packages for
On 3/14/2012 8:11 AM, David Lindstrom wrote:
Hi everyone.
As some other people have reported, there seems to be some problem with
pipes in 1.7.11 which appears to have been introduced in 1.7.10. I can
confirm that 1.7.9 and 1.7.7 works as expected, but I don't have a 1.7.10
installation so I can
On 7/2/2010 12:01 PM, Marco Atzeri wrote:
--- Ven 2/7/10, Pavel Holejsovsky ha scritto:
Hi,
I think that following problem shows problematic behavior
in cygwin 1.7.5, at least incompatible with linux:
#include
#include
int main() {
int sock, option, optlen =
sizeof(int
Pavel Holejsovsky wrote:
One incompatibility of 4.1.5 is that sed no longer works correctly with
CRLF-style files on binary mounts. For example, 's/^$//' script no
longer filters out empty lines if they are CRLF terminated, but works OK
for LF terminated lines. However, I'm n
Corinna Vinschen wrote:
On Feb 24 04:01, Charles Wilson wrote:
Yaakov S (Cygwin Ports) wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
After a recent update to my Cygwin installation, suddenly
configure-generated libtool scripts give me this error when compiling
and linking C++ code:
lib
I've similar experience, but I believe even stranger one. After
installing 1.3.19, I saw the message about shared version mismatch, but
the numbers were different, unfortunately I didn't write them down:-(. I
made sure that I have really only one cygwin1.dll in the system. I also
used sysintern
+0100, Pavel Holejsovsky wrote:
[EMAIL PROTECTED] wrote:
Christopher Faylor wrote:
On Thu, Dec 12, 2002 at 07:32:16AM -0500, Norman Vine wrote:
Any 'tips' as to how to best debug this appreciated
- Attach to the hung process with gdb and see where it is hung.
- Provide cygch
[EMAIL PROTECTED] wrote:
Christopher Faylor wrote:
On Thu, Dec 12, 2002 at 07:32:16AM -0500, Norman Vine wrote:
Any 'tips' as to how to best debug this appreciated
- Attach to the hung process with gdb and see where it is hung.
- Provide cygcheck output.
- Run under strace and see if you can
I have similar experience. Examining the processes when the ./configure
hangs reveals that hanging leaf seems to be always 'sed', running as a
part of config.status script creating Makefiles etc.
I'm running XPPro, the same results were achieved when running configure
inside xterm or inside FSF
Hello,
I'm experiencing yet another kind of hangs of emacs (running in X
window). This happens during emacs startup, but only if I resize its
window with mouse while emacs is processing startup files. Then it never
finishes its startup and eats 100% of CPU (quite similar symptoms of
previous b
Claudius,
I think that your problem is that you are linking C++ dll with gcc
driver. Try to use g++ also for linking, and it should work OK. Or add
-lstdc++ switch ad the end of your link line (but using g++ for linking
C++ modules is generally preferred).
Pavel
[EMAIL PROTECTED] wrote:
Now,
Matthew,
1. you can try ld's option --kill-at. The link cmdline would look like this:
gcc -Wl,--kill-at -Wl,--out-implib,libfoo.import.a -mno-cygwin -shared
-o foo.dll foo.o
2. you can create .def file foo.def containing list of exported symbols
without @NN suffix (one symbol per line). Then a
Cygwin normally does not produce core dumps, but only simple textual
stack backtraces (try to look at gtl.exe.stackdump using your text
editor). However, you can have full core dumps using dumper utility; see
http://cygwin.com/cygwin-ug-net/using-utils.html#DUMPER for details.
Pavel
[EMAIL PR
14 matches
Mail list logo
