DuplicateHandle error

[Lange, Jan-Erik]

Hello,

I have trouble with my cygwin installation. I use the program gforth. Starting 
the tool there comes the following error:

3 [main] gforth 4824 dtable::stdio_init: couldn't make stderr distinct from 
stdout

Because of this error I cannot see the error messages, which gforth produces.

Corinna gave me already a hint for the reason of this error. But that doesnt 
help me solving the problem:
"This message occurs if the stdout and stderr handle are the
same, and a DuplicateHandle on the stderr handle failed for reason X."

Do you have an idea what I could do?

I installed the latest version of cygwin and I'm using Windows 7.

Regards,
Jan
--
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: DuplicateHandle error

[marco atzeri]

Il 6/10/2013 9:14 AM, Lange, Jan-Erik ha scritto:

Hello,

I have trouble with my cygwin installation. I use the program gforth.


there is no gforth on cygwin.
http://cygwin.com/cgi-bin2/package-grep.cgi?grep=gforth

Are you building by yourself or what ?

> Starting the tool there comes the following error:


3 [main] gforth 4824 dtable::stdio_init: couldn't make stderr distinct from 
stdout

Because of this error I cannot see the error messages, which gforth produces.

Corinna gave me already a hint for the reason of this error. But that doesnt 
help me solving the problem:
"This message occurs if the stdout and stderr handle are the
same, and a DuplicateHandle on the stderr handle failed for reason X."

Do you have an idea what I could do?

I installed the latest version of cygwin and I'm using Windows 7.

Regards,
Jan



Marco



--
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: Regression with 1.7.20-1

[Csaba Raduly]

Hi Steven,

On Mon, Jun 10, 2013 at 3:06 AM, Steven Penny  wrote:
> Since upgrading to the package "cygwin 1.7.20-1" a command such as this no
> longer works
>
>   ffmpeg -codecs | grep mov

"Does not work" is not a particularly helpful error report
(http://www.chiark.greenend.org.uk/~sgtatham/bugs.html#respect).
Please read and follow the guidelines below:

> Problem reports:   http://cygwin.com/problems.html


Csaba
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

--
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: Regression with 1.7.20-1

[Steven Penny]

On Mon, Jun 10, 2013 at 3:06 AM, Csaba Raduly wrote:
> "Does not work" is not a particularly helpful error report

Neither is adding nothing more than a "hand slap".

To add more information, running the pipe

  ffmpeg -codecs | grep mov

with 1.7.20-1 just hangs forever, even will ignore Ctrl-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: Regression with 1.7.20-1

[Corinna Vinschen]

On Jun 10 03:28, Steven Penny wrote:
> On Mon, Jun 10, 2013 at 3:06 AM, Csaba Raduly wrote:
> > "Does not work" is not a particularly helpful error report
> 
> Neither is adding nothing more than a "hand slap".
> 
> To add more information, running the pipe
> 
>   ffmpeg -codecs | grep mov
> 
> with 1.7.20-1 just hangs forever, even will ignore Ctrl-C

There's no ffmpeg in the Cygwin distro.  Is that a Cygwin or a native
tool?  I guess the latter, in which case you may want to try the
latest developer snapshot 2013-06-08 from http://cygwin.com/snapshots/


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

--
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: ctrl-c to windows program causes mintty to hang [1.7.20 / win7]

[Frank Fesevur]

2013/6/9 Andrey Repin:
> 3. Now, if you Ctrl+C, the console hangs.
> If you let it sit down and think a bit, the iterrupt will be delivered to ping
> and it get out of the lockup.
>
> Going to grab a snapshot and see if it affect anything.

I ran into the same problem today, grabbed the latest snapshot (8-Jun)
and that fixes the problem.

Regards,
Frank

--
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

[ANNOUNCEMENT] Updated: {uw-imap/uw-imap-imapd/uw-imap-util/c-client}-2007f-2: UW IMAP Toolkit

[Dr . Volker Zell]

Hi

New versions of 'uw-imap/uw-imap-imapd/uw-imap-util/c-client' have been 
uploaded to a server near you.

 o Build for cygwin 1.7.20-1 with gcc-4.5.3-3
 o Fixed header file packaging
-> http://cygwin.com/ml/cygwin/2013-06/msg00113.html
-> http://cygwin.com/ml/cygwin/2013-06/msg00114.html
 

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO



If you want to unsubscribe from the cygwin-announce mailing list, please
use the automated form at:


http://cygwin.com/lists.html#subscribe-unsubscribe

If this does not work, then look at the "List-Unsubscribe: " tag in the
email header of this message.  Send email to the address specified
there.  It will be in the format:


cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

--
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: Do the runtime support the large file 2GB with fstati64 (error: undefined reference to __fstati64 )?

[JonY]

On 6/10/2013 09:11, Lord Flaubert Steve Ataucuri Cruz wrote:
> Folks,
> 
> I did some research at mailing list, faq and I didn't seek any
> information about this error . I am trying to build an installer of
> some great tools of linux to windows, but I wanna use and Cygwin
> runtime and Mingw(please don't redirect to another list). I am going
> to explain what I did:
> 

I don't think you can use the original 3.4.x gcc to build setup anymore,
try using the i686 mingw-w64 cross compilers, they can be found in
Cygwin setup.





signature.asc
Description: OpenPGP digital signature

Re: Regression with 1.7.20-1

[Christopher Faylor]

On Mon, Jun 10, 2013 at 03:28:02AM -0500, Steven Penny wrote:
>On Mon, Jun 10, 2013 at 3:06 AM, Csaba Raduly wrote:
>> "Does not work" is not a particularly helpful error report
>
>Neither is adding nothing more than a "hand slap".

Csaba included useful information.  You snipped it from your response.

--
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: Regression with 1.7.20-1

[Steven Penny]

Corinna Vinschen wrote:

> Is that a Cygwin or a native tool? I guess the latter, in which case you may
> want to try the latest developer snapshot 2013-06-08 from
> http://cygwin.com/snapshots/

cygwin1-20130608.dll.bz2

does fix it.

--
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: Fwd: Cygwin64: mkshortcut - Segmentation fault

[Charles Wilson]

On 6/7/2013 12:18 PM, Vasiliy wrote:

I vote for this issue be double-checked:

1) there is only one (the latest one provided by setup) cygwin1.dll in my $PATH:
$ which cygwin1.dll
/usr/bin/cygwin1.dll

$ uname -a
CYGWIN_NT-6.1 Luminous 1.7.20(0.266/5/3) 2013-06-06 17:36 x86_64 Cygwin


Well, so far so good...


and rebaseall is not (has not been) designed for a 64bit installation
(both system and Cygwin are 64-bit)


...but as Corinna pointed out, both rebase.exe and rebaseall fully 
support 64bit installations.


Now, it is true that on x86_64, rebaseall still defaults to a starting 
address of 0x7000, and should probably autodetect 64ness and use 
instead the agreed-upon base address starting location (0x1,700 IIRC?)


However, it appears that rebaseall defaults to 0x7000 regardless (or 
whatever is already in the /etc/rebase.db.* file). Since the first 
version of that db file is created by setup.exe running the _autorebase 
postinstall script on initial install -- but that just invokes "dash 
/bin/rebaseall -p", this means that the base addr on x86_64 is typically 
going to be 0x7000 which is probably sub-optimal.


You might try to manually rebaseall (with a new -b base address above 
4G). When you launch rebaseall with an explicit '-b 0x' option, then 
all DLLs will be rebased to the new area, and the database recreated 
from scratch.  That might help, in your case.



2) provided in (the latest by setup) cygutils 1.4.12-2 mkshortcut.exe
was, in fact, compled with a mismatched version of cygwin1.dll


I don't understand what you mean here. The internal version number 
(1.7.20-1 or whatever) is not recorded in the .exe file format; only the 
file name "cygwin1.dll".  So there is no way you could tell whether a 
"mismatch" happened at compile time.  Further, since all newer 
cygwin1.dll's are backwards compatible with older ones, so long as your 
cygwin1.dll is the same version, or a newer version, than the one I used 
to build, it should work fine [*]


[*] provided all cygwin1.dll's we're discussing have the same bitness -- 
64bit, in this case:


$ file mkshortcut.exe
mkshortcut.exe: PE32+ executable (console) x86-64, for MS Windows


The error you see is a runtime mismatch error.  Basically, fork()/exec() 
is used by bash.exe to launch mkshortcut.exe.  It first forks() itself 
-- so you have a parent bash and a child bash -- and the memory layout 
of the child bash (stack location, DLL load addresses, version number of 
the cygwin DLL loaded in each instance, etc) must be exactly the same as 
that of the parent bash.  Cygwin's fork() jumps thru a lot of hoops to 
try and ensure that this is the case, but sometimes it fails.  Then, 
mkshortcut.exe itself is exec()ed.  Somewhere in this process, the 
address of the cygheap is checked to make sure it is the same as in the 
parent (bash), and that check is failing.


The code in mkshortcut.c itself has nothing to do with where cygwin's 
heap ends up during this fork/exec process.  Hence, this is a system 
issue...



3) cygport all from the cygutils 1.4.12-2 sources installs, indeed,
libcygicons.dll.a, as opposed to the correct spelling: libicons.dll.a

Please, indeed, take a look at the content you've just attached:

Attachment: cygutils-extra.txt
Description: Text document
...
/usr/bin/cygicons-0.dll
...
/usr/lib/libcygicons.dll.a
/usr/lib/libcygicons.la

and check the content of "libcygicons.la" (should be "libicons.la" as well)


You're assuming this is a bug.  It isn't.  Yes, typically cygwin DLLs 
follow a naming pattern like:


cygfoo-N.dll  <-> libfoo.dll.a <-> libfoo.a

so that -lfoo will link to the correct implib/static lib "just like on 
linux" regardless of the funky naming convention used on cygwin for DLLs.


However, the cygwin icon library is cygwin specific; there is no "linux 
version" that people link against, and whose name we must imitate. 
(Besides, I really don't want to be -licon, because there might be a 
REAL icon support library out there called "libicon").  So, as we're 
cygwin-specific, I made a deliberate choice that the import library for 
the DLL (and the header) would be "-lcygicon" (/usr/include/cygicon.h). 
 Now, that means "cygcygicon-0.dll" would be the DLL name if we 
followed the typical pattern -- but that looks stupid, so the DLL is 
named "cygicon-0.dll" instead.


Why are you trying to link to the cygicon dll anyway? It doesn't provide 
anything except a few icons as resource objects...frankly, I probably 
shouldn't even include the header/implib in the package at all.


--
Chuck


--
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: Fwd: Cygwin64: mkshortcut - Segmentation fault

[Corinna Vinschen]

On Jun 10 12:18, Charles Wilson wrote:
> On 6/7/2013 12:18 PM, Vasiliy wrote:
> >I vote for this issue be double-checked:
> >
> >1) there is only one (the latest one provided by setup) cygwin1.dll in my 
> >$PATH:
> >$ which cygwin1.dll
> >/usr/bin/cygwin1.dll
> >
> >$ uname -a
> >CYGWIN_NT-6.1 Luminous 1.7.20(0.266/5/3) 2013-06-06 17:36 x86_64 Cygwin
> 
> Well, so far so good...
> 
> >and rebaseall is not (has not been) designed for a 64bit installation
> >(both system and Cygwin are 64-bit)
> 
> ...but as Corinna pointed out, both rebase.exe and rebaseall fully
> support 64bit installations.
> 
> Now, it is true that on x86_64, rebaseall still defaults to a
> starting address of 0x7000, and should probably autodetect
> 64ness and use instead the agreed-upon base address starting
> location (0x1,700 IIRC?)
> 
> However, it appears that rebaseall defaults to 0x7000 regardless

No, that's not right.  rebaseall in the 64 bit distro defaults
to 0x4: where it belongs.  See rebaseall lines 91ff.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

--
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: peflags documentation anywhere?

[Charles Wilson]

Please confine questions to the cygwin mailing list.

On 6/9/2013 7:53 PM, Philip Goetz wrote:

I tried but was unable to find any documentation on peflags other than
that provided by

peflags --help

This documentation indicates that I should be able to do something like this:

$ peflags --bigaddr `which perl`

but instead of getting a zero or one back, I get this, and have no
idea how to interpret it:

/usr/bin/perl: coff(0x0326[+bigaddr]) pe(0x8000)


See below.


The documentation also indicates I should be able to do this, but I cannot:

$ peflags --bigaddr 1 `which perl`
1: skipped because nonexistent
/usr/bin/perl: coff(0x0326[+bigaddr]) pe(0x8000)


I think you need to say "--bigaddr=1" but I could be wrong there.


Neither does this work:

$ peflags -l1 `which perl`
/usr/bin/perl: skipped because could not open

I have write permission on /usr/bin/perl .


No explanation here, but your followup seems to indicate it was a cygwin 
version problem.



Can you point me to some documentation that will explain how to use
peflags to view and set this --bigaddr bit?


The existing documentation says:

"For each numerical value, if an argument is given, the specified value 
will be overwritten; if no argument is given, the numerical value will 
be displayed in decimal and hexadecimal notation."



The cryptic output "/usr/bin/perl: coff(0x0326[+bigaddr]) pe(0x8000)" 
contains the actual values of the Characteristics fields of the COFF 
File Header, and the PE OptionalHeader records in the on-disk file, 
expressed in hex notation.


*coff_characteristics = pep->ntheaderNN->FileHeader.Characteristics;
*pe_characteristics = pep->ntheaderNN->OptionalHeader.DllCharacteristics;

It's really for debugging. By setting a particular flag true then false, 
and checking the output, you can tell which bit corresponds to that flag 
AND you can verify that the on-disk file actually got changed.


I had this whole big scheme to extensibly express all the flag values in 
readable english, but it was a maintenance nightmare and cgf rightly 
nixed it.


Instead, you get english output for JUST the value(s) you query. If you 
query -d then the hex output is augmented with a string for dynamic base 
-- but nothing else. If you query -l, then the hex output is augmented 
with a string for big address -- but nothing else.  There's a "+" if the 
flag is turned "on", and a "-" if the flag is turned "off".


E.g.

$ peflags -l /usr/bin/perl
/usr/bin/perl: coff(0x0326[+bigaddr]) pe(0x8000)

Means you have bigaddr on.


$ peflags -d /usr/bin/perl
/usr/bin/perl: coff(0x0326) pe(0x8000[-dynamicbase])

Means you have dynamicbase off.

You can combine multiple queries:
$ peflags -d -l /usr/bin/perl
/usr/bin/perl: coff(0x0326[+bigaddr]) pe(0x8000[-dynamicbase])



So, what you do is grep the output for "+bigaddr" -- if that doesn't 
appear when you query -l, then bigaddr is not set.


$ peflags -l /usr/bin/perl | grep '+bigaddr' >/dev/null &&\
 echo has_bigaddr
has_bigaddr

$ peflags -d /usr/bin/perl | grep '+dynamicbase' >/dev/null &&\
 echo has_dynamicbase

$

--
Chuck


--
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: Fwd: Cygwin64: mkshortcut - Segmentation fault

[Charles Wilson]

On 6/10/2013 12:25 PM, Corinna Vinschen wrote:

On Jun 10 12:18, Charles Wilson wrote:

However, it appears that rebaseall defaults to 0x7000 regardless


No, that's not right.  rebaseall in the 64 bit distro defaults
to 0x4: where it belongs.  See rebaseall lines 91ff.


Oh, here's the problem. I assumed that the 32-bit package and the 64-bit 
package of rebase were both up-to-date. It seems the 64bit package is 
newer and those changes haven't yet prompted a 32bit update.


32bit 4.4.0-1 package:
# $Id: rebaseall.in,v 1.9 2012/06/07 18:50:33 jlt63 Exp $

Current CVS and 64bit 4.4.0.1-1 package:
# $Id: rebaseall.in,v 1.11 2013/02/18 10:04:43 yselkowitz Exp $

Sorry for the confusion.

--
Chuck


--
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

xorg-server no longer support -wgl option

[Vasiliy]

I have compiled 'gnubik' from GNU Ftp, and it fails with:

$ gnubik
(gnubik:28564): GdkGLExt-WARNING **: Window system doesn't support OpenGL.


Upon checking, I couldn't see any longer XWin's -wgl option working,
though no warnings were issued. Is that all right?:

$ uname -srvm
CYGWIN_NT-6.1 1.7.20(0.266/5/3) 2013-06-06 17:36 x86_64

user@host ~
$ XWin.exe -multiwindow -wgl
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.14.1.0
OS: CYGWIN_NT-6.1 Luminous 1.7.20(0.266/5/3) 2013-06-06 17:36 x86_64
OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601](Win64)
Package: version 1.14.1-1 built 2013-05-07

XWin was started with the following command line:

XWin -multiwindow -wgl

(II) xorg.conf is not supported
(II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information
LoadPreferences: /Users/Khalak/.XWinrc not found
LoadPreferences: Loading /etc/X11/system.XWinrc
LoadPreferences: Done parsing the configuration file...
winDetectSupportedEngines - DirectDraw installed, allowing ShadowDD
winDetectSupportedEngines - Windows NT, allowing PrimaryDD
winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL
winDetectSupportedEngines - Returning, supported engines 001f
winSetEngine - Multi Window or Rootless => ShadowGDI
winScreenInit - Using Windows display depth of 32 bits per pixel
winAllocateFBShadowGDI - Creating DIB with width: 1366 height: 768 depth: 32
winFinishScreenInitFB - Masks: 00ff ff00 00ff
winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32
winInitMultiWindowWM - Calling pthread_mutex_lock ()
winMultiWindowXMsgProc - Calling pthread_mutex_lock ()
Initializing built-in extension Generic Event Extension
Initializing built-in extension SHAPE
Initializing built-in extension MIT-SHM
Initializing built-in extension XInputExtension
Initializing built-in extension XTEST
Initializing built-in extension BIG-REQUESTS
Initializing built-in extension SYNC
Initializing built-in extension XKEYBOARD
Initializing built-in extension XC-MISC
Initializing built-in extension XINERAMA
Initializing built-in extension XFIXES
Initializing built-in extension XFree86-Bigfont
Initializing built-in extension RENDER
Initializing built-in extension RANDR
Initializing built-in extension COMPOSITE
Initializing built-in extension DAMAGE
Initializing built-in extension MIT-SCREEN-SAVER
Initializing built-in extension DOUBLE-BUFFER
Initializing built-in extension RECORD
Initializing built-in extension DPMS
Initializing built-in extension X-Resource
MIT-SHM extension disabled due to lack of kernel support
XFree86-Bigfont extension local-client optimization disabled due to
lack of shared memory support in the kernel
[dix] Could not init font path element /usr/share/fonts/TTF/, removing
from list!
[dix] Could not init font path element /usr/share/fonts/OTF/, removing
from list!
winPointerWarpCursor - Discarding first warp: 683 384
(--) 5 mouse buttons found
(--) Setting autorepeat to delay=500, rate=31
(--) Windows keyboard layout: "0409" (0409) "US", type 7
(--) Found matching XKB configuration "English (USA)"
(--) Model = "pc105" Layout = "us" Variant = "none" Options = "none"
Rules = "base" Model = "pc105" Layout = "us" Variant = "none" Options = "none"
winBlockHandler - pthread_mutex_unlock()
winInitMultiWindowWM - pthread_mutex_lock () returned.
winInitMultiWindowWM - pthread_mutex_unlock () returned.
winMultiWindowXMsgProc - pthread_mutex_lock () returned.
winInitMultiWindowWM - DISPLAY=:0.0
winMultiWindowXMsgProc - pthread_mutex_unlock () returned.
winProcEstablishConnection - winInitClipboard returned.
winMultiWindowXMsgProc - DISPLAY=:0.0
winClipboardProc - DISPLAY=:0.0
winInitMultiWindowWM - XOpenDisplay () returned and successfully
opened the display.
winMultiWindowXMsgProc - XOpenDisplay () returned and successfully
opened the display.
winClipboardProc - XOpenDisplay () returned and successfully opened the display.

--
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: SQLite temporary path creation broken in latest stable release

[Warren Young]

On 6/9/2013 19:26, Daniel Colascione wrote:

which I haven't been able to test


You should.  One of the changes is to prefer creating temporary tables 
in memory instead of on disk, which should bypass the problem.



"/var/tmp/etilqs_z28HceqmzVr3ZO1\\etilqs_rnPCuceSOgjfeTd".


This bug is already under discussion on the SQLite mailing list:

http://comments.gmane.org/gmane.comp.db.sqlite.general/81718

None of the SQLite core developers have responded to my charge that this 
looks like a bug in SQLite.  It shouldn't be generating temporary file 
names with backslashes in them for Cygwin builds, since it knows such 
paths go through the Cygwin DLL, which sometimes has trouble doing the 
right thing with backslashes.


There is a chance the bug exists in the "Unix" path as well, since 
backslashes are legal in POSIX paths but not on Cygwin, but since the 
in-memory change will avoid this, my motivation to fix this bug twice is 
low.  Once should be enough.


--
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: SQLite temporary path creation broken in latest stable release

[Daniel Colascione]

On 6/10/2013 12:21 PM, Warren Young wrote:
> On 6/9/2013 19:26, Daniel Colascione wrote:
>> which I haven't been able to test
> 
> You should.  One of the changes is to prefer creating temporary tables in 
> memory
> instead of on disk, which should bypass the problem.

This change makes me nervous. What if the temporary tables are large?

> 
>> "/var/tmp/etilqs_z28HceqmzVr3ZO1\\etilqs_rnPCuceSOgjfeTd".
> 
> This bug is already under discussion on the SQLite mailing list:
> 
> http://comments.gmane.org/gmane.comp.db.sqlite.general/81718
> 
> None of the SQLite core developers have responded to my charge that this looks
> like a bug in SQLite.  It shouldn't be generating temporary file names with
> backslashes in them for Cygwin builds, since it knows such paths go through 
> the
> Cygwin DLL, which sometimes has trouble doing the right thing with 
> backslashes.

It seems easy enough to patch out the backslash addition.

> 
> There is a chance the bug exists in the "Unix" path as well, since backslashes
> are legal in POSIX paths but not on Cygwin, but since the in-memory change 
> will
> avoid this, my motivation to fix this bug twice is low.  Once should be 
> enough.




signature.asc
Description: OpenPGP digital signature

Re: SQLite temporary path creation broken in latest stable release

[Warren Young]

On 6/10/2013 14:21, Daniel Colascione wrote:

On 6/10/2013 12:21 PM, Warren Young wrote:

On 6/9/2013 19:26, Daniel Colascione wrote:

which I haven't been able to test


You should.  One of the changes is to prefer creating temporary tables in memory
instead of on disk, which should bypass the problem.


This change makes me nervous. What if the temporary tables are large?


You tell me.  If the new version fails on your DB because of this, I'll 
back the change out.



It seems easy enough to patch out the backslash addition.


So find it and send me the patch.

There's only 140 kSLOC in SQLite.  Easy.

--
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: Cygwin64: mkshortcut - Segmentation fault

[Angelo Graziosi]

Just for the record,

Vasiliy wrote:

user@host /etc/postinstall
$ /usr/bin/mkshortcut $CYGWINFORALL -P -i /usr/bin/XWin.exe -n
"Cygwin-X/XWin Server" -a "/usr/bin/bash.exe -l -c
/usr/bin/startxwin.exe" /usr/bin/run.exe
Aborted (core dumped)


I flagged a similar problem a few months ago for Cygwin32:

http://www.cygwin.com/ml/cygwin/2013-01/msg00261.html


It still survives in 1.7.20-1...


Ciao,
 Angelo.

--
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

pty issue causes 'screen' to hang when run from mintty as detached

[Matt D.]

See here for additional information and reproducible steps in the mintty 
support ticket:

https://code.google.com/p/mintty/issues/detail?id=390

I can reproduce this using cygwin 1.7.20, 1.7.19, 1.7.18, 1.7.15, and 1.7.7.

Screen does NOT hang when is is created by calling the first command 
through cygwin started by cygwin.bat (commands typed through Windows 
terminal 'cmd.exe' instead of mintty) and then attempting to attach 
through mintty with the second command.


Workaround is to use:

'cygstart --hide screen -S name -d -m'

--
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

aprovechas las mejores ofertas

[info]

si te gusta la fortuna de san carlos.

dale me gusta a nuestro sitio en fb

https://www.facebook.com/fortunacostarica?ref=tn_tnmn

 

La Fortuna Costa Rica 

aqui estaremos publicando las mejores ofertas, tal como la que
publicamos en nuestro muro, 
oferta del Hotel Linda Vista
 
a precio super rebajado
 
gracias



Esta correspondencia no contiene fines de venta directa. Nuestro deseo es
mantenerle informado sobre los movimientos,
servicios y oportunidades que se brindan para su crecimiento profesional y
personal. Si usted est� interesado
en recibir informaci�n sobre el anuncio que observa puede comunicarse con
su proveedor.


Cumplimos con las normas mundiales del anti spam, Valoramos su desisi�n si
usted no desea permanecer en nuestra
lista de usuarios puede darse de baja 

si no desea recibir mas correos, 
http://ticosviajando.com/lista/?p=unsubscribe&uid=e830b8fc8b067543af20743080927bf2

para actualizar su correo 
http://ticosviajando.com/lista/?p=preferences&uid=e830b8fc8b067543af20743080927bf2
reenviar a un amigo 
http://ticosviajando.com/lista/?p=forward&uid=e830b8fc8b067543af20743080927bf2&mid=35


--
powered by phpList, www.phplist.com --



--
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

semget() crash

[David Stacey]

Please find attached a short test programme derived from the semaphore 
handling code in Poco. The test crashes in the call to semget(), 
reporting 'Bad system call (core dumped)'. I am using the latest 32-bit 
snapshot (2013-06-08).


The test programme runs correctly under Fedora 18 x64.

BTW, the man page for ftok(3) states that the second parameter 
('proj_id') must be non-zero. Contrary to this, Poco uses zero for 
'proj_id'. This is easy enough to patch, but does anyone know the effect 
of using zero here? If there's no good reason for it then I'll raise a 
ticket with Poco and get it changed.


Many thanks in advance for looking at this problem,

Dave.

/* Compile: gcc -o poco_ne poco_ne.c
*/
#include 
#include 
#include 
#include 
#include 
#include 
#include 

/* Error handling. */
void FatalError(const char* const pmsg)
{
	fprintf(stderr, "%s\n", pmsg);
	exit(1);
}

int main()
{
	/* Create a file. */
	const char* const pfilename = "try.txt";
	int fd = open(pfilename, O_WRONLY | O_CREAT, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
	if (fd == -1)
		FatalError("open() failed.");
	close(fd);

	/* Generate a key, using the file we just created. */
	key_t key = ftok(pfilename, 'a');
	if (key == -1)
		FatalError("ftok() failed.");

	/* Get the semaphore set identifier */
	fprintf(stderr, "Trying semget()\n");
	fprintf(stderr, "This causes 'Bad system call (core dumped)' in Cygwin.\n");
	int semid = semget(key, 1, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH | IPC_CREAT | IPC_EXCL);
	fprintf(stderr, "OK - that worked. semget() returned %i\n", semid);
	return 0;
}

--
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: semget() crash

[Christopher Faylor]

On Mon, Jun 10, 2013 at 10:23:59PM +0100, David Stacey wrote:
>Please find attached a short test programme derived from the semaphore 
>handling code in Poco. The test crashes in the call to semget(), 
>reporting 'Bad system call (core dumped)'. I am using the latest 32-bit 
>snapshot (2013-06-08).

That sounds a lot like you aren't running cygserver.  You need to
run cygserver if you use semget().

cgf

--
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: semget() crash

[David Stacey]

On 10/06/2013 22:34, Christopher Faylor wrote:

On Mon, Jun 10, 2013 at 10:23:59PM +0100, David Stacey wrote:

>Please find attached a short test programme derived from the semaphore
>handling code in Poco. The test crashes in the call to semget(),
>reporting 'Bad system call (core dumped)'. I am using the latest 32-bit
>snapshot (2013-06-08).

That sounds a lot like you aren't running cygserver.  You need to
run cygserver if you use semget().


Many thanks for your speedy reply. Yes, running cygserver fixed the problem.
The Poco 'Foundation' test suite now runs to completion - even if not 
all of the tests pass!


Thanks again,

Dave.



--
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

[ANNOUNCEMENT] Updated: ocaml-4.00.1-1

[Damien Doligez]

The OCaml packages have been updated to the upstream release 4.00.1.

This is a major release with lots of changes. See
  http://caml.inria.fr/ocaml/release.en.html

for more details about the changes in this release.

DESCRIPTION:


OCaml is a fast modern type-inferring functional programming language
descended from the ML (Meta Language) family, featuring objects, modules,
and a high-performance native-code compiler. The OCaml compiler is
developed by a worldwide distributed team coordinated by the Gallium
project-team at Inria Paris-Rocquencourt.

DOWNLOAD:
=
Note that downloads from sources.redhat.com (aka cygwin.com) aren't
allowed due to bandwidth limitations.  This means that you will need to
find a mirror which has this update, please choose the one nearest to
you: 
http://cygwin.com/mirrors.html


QUESTIONS:
==
If you want to make a point or ask a question the Cygwin mailing list is
the appropriate place.

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO:
=
To unsubscribe to the cygwin-announce mailing list, look at the
"List-Unsubscribe: " tag in the email header of this message.  Send
email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-YOU=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:


http://sources.redhat.com/lists.html#unsubscribe-simple


Please read *all* of the information on unsubscribing that is available
starting at this URL.

-- Damien Doligez

--
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

[ANNOUNCEMENT] Updated: vim-7.3.1152-1

[Yaakov (Cygwin/X)]

The following packages have been updated for the Cygwin distribution:

*** vim-7.3.1152-1
*** vim-common-7.3.1152-1
*** vim-minimal-7.3.1152-1
*** xxd-7.3.1152-1
*** gvim-7.3.1152-1

Vim is an advanced text editor that seeks to provide the power of the
de-facto Unix editor 'Vi', with a more complete feature set and a choice
of terminal and GTK+ interfaces.

This is an update to last week's upstream patchset, with the following 
packaging changes:


* The 'vi' binary now uses ~/.virc and /etc/virc instead of vimrc to 
avoid errors with configuration options not supported by 'vi'.


* gvim on x86_64 uses the GTK+ interface.

--

Yaakov
Cygwin/X


CYGWIN-ANNOUNCE UNSUBSCRIBE INFO


If you want to unsubscribe from the cygwin-announce mailing list, please
use the automated form at:

http://cygwin.com/lists.html#subscribe-unsubscribe

If this does not work, then look at the "List-Unsubscribe: " tag in the
email header of this message.  Send email to the address specified
there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

--
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: xorg-server no longer support -wgl option

[Yaakov (Cygwin/X)]

On 2013-06-10 12:33, Vasiliy wrote:

Upon checking, I couldn't see any longer XWin's -wgl option working,
though no warnings were issued. Is that all right?:

$ uname -srvm
CYGWIN_NT-6.1 1.7.20(0.266/5/3) 2013-06-06 17:36 x86_64

user@host ~
$ XWin.exe -multiwindow -wgl
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.14.1.0
OS: CYGWIN_NT-6.1 Luminous 1.7.20(0.266/5/3) 2013-06-06 17:36 x86_64
OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601](Win64)
Package: version 1.14.1-1 built 2013-05-07


The 64-bit version of xorg-server was built without GLX support due to 
some outstanding bugs (and missing dependencies that may fix them).  If 
you need OpenGL, you will need to use the 32-bit version of the server 
for now; note that you can use the 32-bit X server with 64-bit programs.



Yaakov


--
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

Using 'test' fails when referencing home '~' from bash loop

[Matt D.]

The following never exits the loop:

until test -f "~/file.txt"; do sleep 1 && echo sleep; done; echo done

The following does:

until test -f "/cygdrive/d/cygwin-home/file.txt"; do sleep 1 && echo 
sleep; done; echo done


HOME is set and confirmed:
echo $HOME
/cygdrive/d/cygwin-home

--
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 and symlink are incompatibility on 64-bit windows

[Lu Sheng]

Hi

I'm running windows 8 64 -bit, and I installed cygwin 1.7 for I want
to install lxml module of python.
the command as:

pip install lxml

during the running it need to run

E:\cygwin\bin\gcc.exe -mcygwin -mdll -O -Wall -Ic:\users\it-04\appdata\local\tem
p\pip-build-IT-04\lxml\src\lxml\includes -IC:\Python27\include -IC:\Python27\PC
-c src\lxml\lxml.etree.c -o build\temp.win-amd64-2.7\Release\src\lxml\lxml.etree
.o

when this command run, I will received the error message:

Unsupported 16-Bit Application

The program or feature "*\gcc.exe" cannot start or run due to
incompatibity with 64-bit versions
 of Windows. Please contact the software vendor to ask if a 64-bit
Windows compatible version is available.

I to change the name of gcc-4.exe to gcc.exe and It give me
Incomprehensible error message as below:

In file included from C:\Python27\include/Python.h:86:0,

 from src\lxml\lxml.etree.c:16:

C:\Python27\include/intobject.h:46:35: error: expected ΓÇÿ=ΓÇÖ, ΓÇÿ,ΓÇÖ, ΓÇÿ;ΓÇÖ
, ΓÇÿasmΓÇÖ or ΓÇÿ__attribute__ΓÇÖ before ΓÇÿPyInt_AsUnsignedLongLongMaskΓÇÖ

In file included from C:\Python27\include/Python.h:88:0,

 from src\lxml\lxml.etree.c:16:

C:\Python27\include/longobject.h:50:1: warning: parameter names (without types)
in function declaration

C:\Python27\include/longobject.h:52:26: error: expected ΓÇÿ=ΓÇÖ, ΓÇÿ,ΓÇÖ, ΓÇÿ;ΓÇ
Ö, ΓÇÿasmΓÇÖ or ΓÇÿ__attribute__ΓÇÖ before ΓÇÿPyLong_AsLongLongΓÇÖ

C:\Python27\include/longobject.h:53:35: error: expected ΓÇÿ=ΓÇÖ, ΓÇÿ,ΓÇÖ, ΓÇÿ;ΓÇ
Ö, ΓÇÿasmΓÇÖ or ΓÇÿ__attribute__ΓÇÖ before ΓÇÿPyLong_AsUnsignedLongLongΓÇÖ

C:\Python27\include/longobject.h:54:35: error: expected ΓÇÿ=ΓÇÖ, ΓÇÿ,ΓÇÖ, ΓÇÿ;ΓÇ
Ö, ΓÇÿasmΓÇÖ or ΓÇÿ__attribute__ΓÇÖ before ΓÇÿPyLong_AsUnsignedLongLongMaskΓÇÖ

C:\Python27\include/longobject.h:55:26: error: expected ΓÇÿ=ΓÇÖ, ΓÇÿ,ΓÇÖ, ΓÇÿ;ΓÇ
Ö, ΓÇÿasmΓÇÖ or ΓÇÿ__attribute__ΓÇÖ before ΓÇÿPyLong_AsLongLongAndOverflowΓÇÖ

In file included from src\lxml\lxml.etree.c:314:0:

Regards
ShengLu

--
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 and symlink are incompatibility on 64-bit windows

[Lu Sheng]

Hi

I'm running windows 8 64 -bit, and I installed cygwin 1.7 for I want
to install lxml module of python.
the command as:

pip install lxml

during the running it need to run

E:\cygwin\bin\gcc.exe -mcygwin -mdll -O -Wall -Ic:\users\it-04\appdata\local\tem
p\pip-build-IT-04\lxml\src\lxml\includes -IC:\Python27\include -IC:\Python27\PC
-c src\lxml\lxml.etree.c -o build\temp.win-amd64-2.7\Release\src\lxml\lxml.etree
.o

when this command run, I will received the error message:

Unsupported 16-Bit Application

The program or feature "*\gcc.exe" cannot start or run due to
incompatibity with 64-bit versions
 of Windows. Please contact the software vendor to ask if a 64-bit
Windows compatible version is available.

I to change the name of gcc-4.exe to gcc.exe and It give me
Incomprehensible error message as below:

In file included from C:\Python27\include/Python.h:86:0,

 from src\lxml\lxml.etree.c:16:

C:\Python27\include/intobject.h:46:35: error: expected ΓÇÿ=ΓÇÖ, ΓÇÿ,ΓÇÖ, ΓÇÿ;ΓÇÖ
, ΓÇÿasmΓÇÖ or ΓÇÿ__attribute__ΓÇÖ before ΓÇÿPyInt_AsUnsignedLongLongMaskΓÇÖ

In file included from C:\Python27\include/Python.h:88:0,

 from src\lxml\lxml.etree.c:16:

C:\Python27\include/longobject.h:50:1: warning: parameter names (without types)
in function declaration

C:\Python27\include/longobject.h:52:26: error: expected ΓÇÿ=ΓÇÖ, ΓÇÿ,ΓÇÖ, ΓÇÿ;ΓÇ
Ö, ΓÇÿasmΓÇÖ or ΓÇÿ__attribute__ΓÇÖ before ΓÇÿPyLong_AsLongLongΓÇÖ

C:\Python27\include/longobject.h:53:35: error: expected ΓÇÿ=ΓÇÖ, ΓÇÿ,ΓÇÖ, ΓÇÿ;ΓÇ
Ö, ΓÇÿasmΓÇÖ or ΓÇÿ__attribute__ΓÇÖ before ΓÇÿPyLong_AsUnsignedLongLongΓÇÖ

C:\Python27\include/longobject.h:54:35: error: expected ΓÇÿ=ΓÇÖ, ΓÇÿ,ΓÇÖ, ΓÇÿ;ΓÇ
Ö, ΓÇÿasmΓÇÖ or ΓÇÿ__attribute__ΓÇÖ before ΓÇÿPyLong_AsUnsignedLongLongMaskΓÇÖ

C:\Python27\include/longobject.h:55:26: error: expected ΓÇÿ=ΓÇÖ, ΓÇÿ,ΓÇÖ, ΓÇÿ;ΓÇ
Ö, ΓÇÿasmΓÇÖ or ΓÇÿ__attribute__ΓÇÖ before ΓÇÿPyLong_AsLongLongAndOverflowΓÇÖ

In file included from src\lxml\lxml.etree.c:314:0:

Regards
ShengLu

--
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: pty issue causes 'screen' to hang when run from mintty as detached

[Andrew Schulman]

> See here for additional information and reproducible steps in the mintty 
> support ticket:
> https://code.google.com/p/mintty/issues/detail?id=390
> 
> I can reproduce this using cygwin 1.7.20, 1.7.19, 1.7.18, 1.7.15, and 1.7.7.
> 
> Screen does NOT hang when is is created by calling the first command 
> through cygwin started by cygwin.bat (commands typed through Windows 
> terminal 'cmd.exe' instead of mintty) and then attempting to attach 
> through mintty with the second command.
> 
> Workaround is to use:
> 
> 'cygstart --hide screen -S name -d -m'

I get a little different result:

$ screen -S scrn -d -m
$ screen -S name -x
Remove dead screens with 'screen -wipe'.
$

and then I have to run 'reset' to get input echoing back.

I've never observed this behavior before, because I always start screen as
'screen -AURD', which works fine.

Do we have any idea whether the problem is with mintty or with screen?  Either
way, I'm afraid I'm not likely to be much help, except that an update of screen
might fix the problem.  The version of screen in Cygwin (4.0.3) hasn't been
updated in several years, because there's a big Cygwin-specific patch that will
have to be either merged into recent screen code, or be determined to be no
longer needed.

Andrew


--
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: Using 'test' fails when referencing home '~' from bash loop

[Steven Penny]

From: "Matt D."
> The following never exits the loop:
> until test -f "~/file.txt"; do sleep 1 && echo sleep; done; echo done

This is not an error, or even Cygwin related. With Bash you must now quote "~"
if you want it to expand.

Do this

  [ -f ~/file.txt ]

or this

  [ -f ~'/file.txt' ]

or this

  [ -f "$HOME/file.txt" ]

--
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 and symlink are incompatibility on 64-bit windows

[Linda Walsh]

Lu Sheng wrote:


E:\cygwin\bin\gcc.exe -mcygwin -mdll -O -Wall -Ic:\users\it-04\appdata\local\tem
p\pip-build-IT-04\lxml\src\lxml\includes -IC:\Python27\include -IC:\Python27\PC
-c src\lxml\lxml.etree.c -o build\temp.win-amd64-2.7\Release\src\lxml\lxml.etree
.o

when this command run, I will received the error message:

Unsupported 16-Bit Application

I to change the name of gcc-4.exe to gcc.exe and It give me
Incomprehensible error message as below...


How did you change the name?
Why are you using E:\ in cygwin?

cygwin paths don't have back slash in them.

If you are using the cygwin gcc you need to run from a compatible shell
and give it compatible pathnames since a unix/posix compatible gcc
wouldn't know what to do with all those backslashes...

Are you sure you want to compile or run lxml from cygwin?   It doesn't
sound like you are using the cygwin environment, but are using the windows
environment??



--
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: Using 'test' fails when referencing home '~' from bash loop

[Linda Walsh]

Steven Penny wrote:

From: "Matt D."

The following never exits the loop:
until test -f "~/file.txt"; do sleep 1 && echo sleep; done; echo done


This is not an error, or even Cygwin related. With Bash you must now quote "~"
if you want it to expand.

Do this 
  [ -f ~/file.txt ]

or this
  [ -f ~'/file.txt' ]
or this
  [ -f "$HOME/file.txt" ]

---
She can use the format she is using ... just need to stress _not_ to use
the quotes...

the quotes don't let "~" expansion take place.

so:
 until test -f ~/file.txt ; do sleep 1 && echo sleep; done; echo done


works just fine...


--
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 and symlink are incompatibility on 64-bit windows

[Lu Sheng]

How did you change the name?
I change the name in windows 8.

Why are you using E:\ in cygwin?
I am not running in cygwin. it is running cmd in window 8 as I want
install a plugin for python in windows.

How can I set the virtualenv module of python to make the pip command
run as in cygwin environment shell.


Are you sure you want to compile or run lxml from cygwin?
no I want run lxml in windows, but the lxml only have linux library, I
tried windows library, but the liblxml could not compile correctly in
Visual studio

It doesn't
sound like you are using the cygwin environment, but are using the windows
environment??

Yes I using windows enviroment, but can you tell how to set the
virtualenv module to make the python and python command pip run as in
windows since I need use gcc to compile the source code of lxml.

--
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: pty issue causes 'screen' to hang when run from mintty as detached

[Andrew Schulman]

> $ screen -S name -d -m
> $ screen -S name -x
> Remove dead screens with 'screen -wipe'.
> $

Sorry, typed by hand, corrected above.


--
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 and symlink are incompatibility on 64-bit windows

[Christopher Faylor]

On Tue, Jun 11, 2013 at 10:34:38AM +1000, Lu Sheng wrote:
>Hi
>
>I'm running windows 8 64 -bit, and I installed cygwin 1.7 for I want
>to install lxml module of python.
>the command as:
>
>pip install lxml
>
>during the running it need to run
>
>E:\cygwin\bin\gcc.exe -mcygwin -mdll -O -Wall 
>-Ic:\users\it-04\appdata\local\tem
>p\pip-build-IT-04\lxml\src\lxml\includes -IC:\Python27\include -IC:\Python27\PC
>-c src\lxml\lxml.etree.c -o 
>build\temp.win-amd64-2.7\Release\src\lxml\lxml.etree
>.o
>
>when this command run, I will received the error message:
>
>Unsupported 16-Bit Application
>
>The program or feature "*\gcc.exe" cannot start or run due to
>incompatibity with 64-bit versions
> of Windows. Please contact the software vendor to ask if a 64-bit
>Windows compatible version is available.
>
>I to change the name of gcc-4.exe to gcc.exe and It give me
>Incomprehensible error message as below:
>
>In file included from C:\Python27\include/Python.h:86:0,
>
> from src\lxml\lxml.etree.c:16:
>
>C:\Python27\include/intobject.h:46:35: error: expected ??=??, 
>??,??, ??;??
>, ??asm?? or ??__attribute__?? before 
>??PyInt_AsUnsignedLongLongMask??

It looks like you're mixing pure-Windows tools with Cygwin tools.  Pure
Windows tools do not understand Cygwin symlinks.

cgf

--
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

make hangs when compiling twf-0.4

[Matt D.]

Attempting to compile twf:

http://gtk-apps.org/content/show.php/?content=83361

Configures fine. Then on make it hangs on what appears to be the linking 
stage:


/bin/sh ../libtool --tag=CC --mode=link gcc -rdynamic -g -O2-o 
twf.exe  main.o themes.o -lglade-2.0 -lgtk-x11-2.0 -lxml2 -lgdk-x11-2.0 
-latk-1.0 -lpangocairo-1.0 -lXinerama -lXi -lXrandr -lXcursor 
-lXcomposite -lXdamage -lgdk_pixbuf-2.0 -lpangoft2-1.0 -lgio-2.0 
-lXfixes -lcairo -lpixman-1 -lxcb-shm -lxcb-render -lXrender -lXext 
-lX11 -lxcb -lXau -lXdmcp -lpng15 -lharfbuzz -lpango-1.0 -lm 
-lfontconfig -lexpat -lfreetype -lz -lbz2 -lgmodule-2.0 -lgobject-2.0 
-lffi -lglib-2.0 -lintl -liconv -lpcre   -lintl


Any suggestions?

--
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: Python core dump depending on module import order with latest upgrade

[Larry Hall (Cygwin)]

On 6/9/2013 12:35 PM, GrahamC wrote:

Since the latest upgrade the following python program causes an "Aborted (core 
dumped)" error:

#!/usr/bin/python
import ctypes
import zlib
a = 1

If the order of imports is reversed (zlib then ctypes) no core dump error 
occurs.

python2.7.exe.stackdump contains nothing of use:
Stack trace:
Frame Function  Args

Versions are:

uname -srm
CYGWIN_NT-6.2 1.7.20(0.266/5/3) i686

python
Python 2.7.3 (default, Dec 18 2012, 13:50:09)


I get the same result with Cygwin 1.7.17 and Python 2.6.8.  I'm sure that
this information isn't real insightful but it does suggest that whatever
the problem is, it isn't real new.

--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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 and symlink are incompatibility on 64-bit windows

[Lu Sheng]

how can I use cygwin tools, if I want to compile the object file in
cygwin and invoke it in windows python?

--
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 and symlink are incompatibility on 64-bit windows

[Linda Walsh]

Lu Sheng wrote:

how can I use cygwin tools, if I want to compile the object file in
cygwin and invoke it in windows python?


If you compile under cygwin, you are designing it to run under posix (linux
like environment) -- not under windows.

If you want it to run under window you need to use windows
tools.

It might compile under the mingw tools -- which are gnu tools adapted to 
windows.

But they don't support a linux-like environment -- so if the program you want 
to run
uses posix/linux features it won't work unless you rewrite the portions
that use linux to do some equivalent thing in windows (i.e. it's not a trivial 
task).


Looking at the lxml website -- there is no windows port or support.

If you want to run it you need to run it on a posix-compatible or linux
compatible platform.

Windows isn't either.

It might run under cygwin -- as it is a posix compatible platform -- you might
ask someone on whatever mailing lists the lxml people hve.

There is a python that runs under cygwin as well.  I.e. if your concern was
to run it on python that ran on your windows 'box', then you can run the cygwin
version of python on your windows box -- but if you need to run the windows
version of python, you  have a long road ahead of you to get this workign.




--
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