Re: configure rxvt on cygwin 1.7.5

[philippe]

Andy Koppe a écrit :
> On 9 July 2010 00:01 lemkemch wrote:
>> If you want to continue with rxvt and want to keep it as close
>> as possible to the old behavior set
>>
>> export LANG=C.ISO-8859-1
>> export LC_TIME=C
>>
>> in .profile

this change modify only output display.

> 
> Setting LANG in .profile is too late for bash itself, because that
> will continue to operate in C.UTF-8. That will cause trouble when
> entering non-ASCII characters on the command line, for example, try
> typing an ä or â.

that's exactly what appends.
> 
> Therefore you need to set it before bash is invoked, for example in
> cygwin.bat if that's where you're invoking rxvt from.

adding

export LANG=C.ISO-8859-1
export LC_TIME=C

in Cygwin.bat has no effect.

Philippe


--
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: configure rxvt on cygwin 1.7.5

[Csaba Raduly]

On Fri, Jul 9, 2010 at 9:08 AM, philippe wrote:
> adding
>
> export LANG=C.ISO-8859-1
> export LC_TIME=C
>
> in Cygwin.bat has no effect

That's because you need to translate them from bash syntax to cmd.exe syntax:

set LANG=C.ISO-8859-1
set LC_CTIME=C

-- 
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: configure rxvt on cygwin 1.7.5

[philippe]

Csaba Raduly a écrit :
> 
> That's because you need to translate them from bash syntax to cmd.exe syntax:
> 
> set LANG=C.ISO-8859-1
> set LC_CTIME=C

OK, it was so simple :-)

Philippe.


--
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: configure rxvt on cygwin 1.7.5

[philippe]

Andy Koppe a écrit :
>>
>> For your -e option, simply run mintty with a single "-" as the only
>> option, i.e. "mintty -".  That will tell mintty to run an interactive
>> login shell for your user as specified in /etc/passwd.  

if i add in the Cygwin.bat the line

mintty -t myminty -

mintty is launched with the good configuration at startup but there is
an additional  cmd window which doesn't close after the mintty is
launched (but i can close it mnually).


> 
> Good advice. Also, it's easiest just to invoke mintty from the start
> menu shortcut in the Cygwin folder that's created when mintty is
> installed. That already has that '-' argument.

just a remark : after the standard cygwin installation I've a single
short cut to Cygwin.bat in the start menu cygwin folder nothing else ...???

Philippe.


--
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: Interesting discovery in the C library that Cygwin uses

[Matthias Andree]

Am 09.07.2010, 01:34 Uhr, schrieb Gregg Levine:

(warnings about char subscripts)


Basically the program supporter there wants the people here for Cygwin
to, ah, fix their C library. I'm not convinced that's necessary, but
which C library is used here? And what could be fixed?


The C library (newlib) is fine, it is actually helpful here by emitting  
warnings for actual program defects.


The supporter should be sold a clue, in the form of a copy of IEEE  
Standard 1003.1 or a deep link to the opengroup.org website.


The urjtag source however should be fixed. It abuses the ctype.h  
interfaces. Arguments to the tolower() and other to*() and isspace() and  
other is*() functions MUST be cast to unsigned char (unless they are  
already unsigned char). Background is that these functions need to support  
the usual 8bit character range plus the 257th "character" EOF (-1).  So  
the is*() functions will have to use a wider type than char, and now sign  
extension matters. If you don't cast the input to unsigned char, an  
argument of 0xff will alias EOF although it is not the same, and  
0x80...0xfe will lead to undefined behaviour, possibly even crashes.


Note: the warning may be specific to Cygwin, but the underlying program  
will show on more systems with input outside ASCII.  I recall that at  
least some versions of Solaris would misbehave if you passed non-ASCII  
characters (think umlauts or accented characters, or Asian/Cyrillic/other  
national scripts) to these ctype.h functions.  There are probably more...


--
Matthias Andree

--
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: configure rxvt on cygwin 1.7.5

[Andy Koppe]

On 9 July 2010 08:51, philippe wrote:
>>> For your -e option, simply run mintty with a single "-" as the only
>>> option, i.e. "mintty -".  That will tell mintty to run an interactive
>>> login shell for your user as specified in /etc/passwd.
>
> if i add in the Cygwin.bat the line
>
> mintty -t myminty -
>
> mintty is launched with the good configuration at startup but there is
> an additional  cmd window which doesn't close after the mintty is
> launched (but i can close it mnually).

If you invoke it from there, you'll need to precede it with the 'start' command:

start mintty -t myminty -

The cmd window will still flash up briefly though, which you can avoid
by invoking mintty from a shortcut.


>> Good advice. Also, it's easiest just to invoke mintty from the start
>> menu shortcut in the Cygwin folder that's created when mintty is
>> installed. That already has that '-' argument.
>
> just a remark : after the standard cygwin installation I've a single
> short cut to Cygwin.bat in the start menu cygwin folder nothing else ...???

The shortcut should have been created if you installed mintty by
selecting it in Cygwin setup.exe.

Andy

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

AW: [bulk] - Re: Coping with large iso files for network-independent Cygwin installation

[DEWI - N. Zacharias]

Moin ,

> Von: Dave Korn []
> Gesendet: Donnerstag, 8. Juli 2010 19:45
> An: cygwin@cygwin.com
> Betreff: [bulk] - Re: Coping with large iso files for network-independent 
> Cygwin
> installation
>
> On 07/07/2010 09:29, Corinna Vinschen wrote:
> > On Jul  7 08:03, Fergus wrote:
>
> >> Nevertheless, it is a tantalising problem: what's the best answer to
> >> give to a 3rd party who wants to install [1.7] on a machine without
> >> network access?
> >
> > Rsync the content of a mirror of your choice onto a stick.  Copy
> > setup.exe and setup-legacy.exe to the stick.  On the target machine,
> > start one of setup or setup-legacy, choose "Install from Local
> > Directory", enter the path to the stick, for instance "X:\", as the
> > Locale Package Directory.  Install.  Done.
>
>   Just for completeness: You can also choose "Install from Internet", and add
> your path as a "User URL" with the textbox and "Add" button at the bottom of
> the "Choose A Download Site" dialog.  The difference is that doing it this way
> will create a local package repository on the machine you're installing to,
> should you want to have one for later when you might not have the USB stick
> around.


Two Questions:

What notation one hase to use to specify the local path file:// d:/mylocalrep 
or ??

Contain this repository also the packages which are not currently installed ?

Have fun
Norbert

> cheers,
>   DaveK
>
> --
> 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


--
Dipl. Phys.
Norbert Zacharias
Wind Measurements & Power Curve Measurements
DEWI GmbH
Ebertstrasse 96
26382 Wilhelmshaven
Germany


Tel.:   +49 4421 4808 876

Fax:+49 4421 4808 843


Email:  n.zachar...@dewi.de
Home:   http://http://www.dewi.de

DEWI GmbH - Deutsches Windenergie-Institut, Wilhelmshaven
Commercial Register No.: Amtsgericht Oldenburg, HRB 130241
Managing Director: Jens Peter Molly
Chairman of the supervisory board: Ministerialrat Dr. Niels Kämpny

P Please consider the environment before printing this 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: problem installing libxml

[cygwin . 20 . maillinglist]

 Original-Nachricht 
> Datum: Thu, 08 Jul 2010 12:40:03 -0400
> Von: 
> +cygwin+maillinglist+eb14c9acbd.reply-to-list-only-lh#cygwin@spamgourmet.com
> An: cygwin@cygwin.com
> Betreff: Re: problem installing libxml

> On 7/8/2010 9:47 AM, cygwin.20.maillingl...@spamgourmet.com wrote:
> > Hi Folks,
> >
> > I have the problem to install libxml. Alter Starting setup as admin I
> proceed
> > to the selection of the download, select the mirror
> > http://cygwin.mirrors.hoobly.com. Enter libxml under Search and found
> libxml
> > in the Gnome folder.
> >
> > When I select the first libxml the setup crashes
> >
> > How can I install libxml?
> >
> > I need the libxml to compile xml2.
> 
> I already had this installed but reinstalling worked fine.  Did you use
> the latest 'setup.exe' from cygwin.com?

I checked that the setup.exe which I was running is the same which I download 
from http://www.cygwin.com/ .

Could you please tell me from which mirror you download it, so that I can try 
from that mirror.

Thanks
  Franz
-- 
IMPORTANT
I will read replies only from the mailing list. 
If you send me email directly it will be deleted.


GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01


--
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: configure rxvt on cygwin 1.7.5

[philippe]

Andy Koppe a écrit :
> 
> If you invoke it from there, you'll need to precede it with the 'start' 
> command:
> 
> start mintty -t myminty -
OK,

thank's for all,

Philippe.


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

XWin seg fault on Vista (cygwin 1.7)

[Markus Moeller]

Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.8.0.0 (1080)
Build Date: 2010-04-02

Hi,

 I used cygwin with XWin for some time now with an older cygwin release.  I 
have upadted now to version 1.7 and get the following error:




Contact: cygwin-xf...@cygwin.com
XWin was started with the following command line:

X :0 -multiwindow -clipboard

ddxProcessArgument - Initializing default screens
winInitializeDefaultScreens - primary monitor w 1440 h 900
winInitializeDefaultScreens - native DPI x 96 y 96
winInitializeDefaultScreens - Returning
[1037442.981] winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1
[1037442.981] (II) xorg.conf is not supported
[1037442.981] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for 
more information

[1037442.981] LoadPreferences: /home/markus/.XWinrc not found
[1037442.996] LoadPreferences: Loading /etc/X11/system.XWinrc
[1037442.996] LoadPreferences: Done parsing the configuration file...
[1037442.996] winGetDisplay: DISPLAY=:0.0
[1037442.996] winDetectSupportedEngines - Windows NT/2000/XP
[1037443.043] Segmentation fault at address 0x31a7fcd0
[1037443.043]
Fatal server error:
[1037443.043] Caught signal 11 (Segmentation fault). Server aborting
[1037443.043]


Any idea what I have to check ?

Thank you
Markus 




--
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: cygport patch: suppress libtool fixup step

[Charles Wilson]

Since I appear to be alone in the "where should the compiler's runtime 
DLLs go, when packaged for cygwin distribution" question, I'll bow to 
the list consensus. I still think, tho, that using


   /usr/[$target?]/sysroot/$target-shortname/{bin,lib,...}

like fedora-mingw does, as the $prefix for components compiled *using* 
the cross compiler (and maybe also as the --sysroot/--build-sysroot for 
the compiler itself?), makes sense even if we go ahead with using 
$toolexeclibdir for the compiler's language runtime DLLs.


However, a pro forma response (including some libtool notes)...

On 7/8/2010 8:59 PM, Dave Korn wrote:

On 08/07/2010 21:52, Charles Wilson wrote:


3) Now, if we want to have a *single* consolidated location for the $target
  DLLs -- so that you can actually RUN the stuff you build,


   Ah, that's your mistake, right there. It is only an accident that the
binaries we compile with this particular cross-compiler happen to be
executable on the same box that the cross-compiler runs on, but that doesn't
make it not cross-compilation (it's the same host, but not the same $host),


And it's only an accident that cygwin itself ships certain tools that 
run on that other Host, but not $host: like strace, cygcheck,...?


This Host/$host thing is an intrinsic element of our $host, and 
pretending otherwise is just willful blindness for the sake of...what? 
consistency with linux?


Let me quote cgf: "cygwin is not linux".


and I don't think we should do special anything just in order to make them
immediately or easily executable. We offer an i686-pc-cygwin environment in
which there is a cross-compiler to (one or more of) *-pc-mingw*; but that's a
different host, and if someone wants to then *run* the cross-targeted binaries
they've just compiled, they need to *install* them into a mingw installation
(which also may happen to be on the same physical machine, but could just as
well be on another).


Hm. I guess.  If you're targeting mingw* for your product, you'll 
probably have some sort of installer anyway.  I suppose you can always 
point to the various DLLs in their various toolchain locations on the 
developer's machine within your (innosetup? wise?) installer script, and 
specify exactly how they should be installed on the end user's machine.


This does, however, have a significant impact to one of our existing 
libtool patches -- the cross-compiler support I was intending to 
re-introduce upstream next week.


More below on how the consensus paradigm here "breaks" mingw libtool on 
cygwin. (Okay, it doesn't actually "break" it, but it might impact the 
end user's perception of it significantly).



There's no reason to try and arrange things that any of
the generated DLLs end up somewhere we can execute them from, I think that's a
category error.


I disagree, because it's not an "accident" that cygwin runs on win32 
(native), and mingw MEANS gcc on win32 (native).  The Host/$host are 
intimately involved (ewww...) together.



Well, yes...I agree with Doug Semler that by default, the -bindir argument
  should be $(toolexeclibdir) and not $(bindir) for cross builds.


   Yes, he's right, that's definitely the way to go.  And so any cross-compiler
we offer on cygwin should probably also leave the binaries there in the gcc
private dir, just as a convenience for those who want to *package* - not in
order to make anything directly *executable*.





I'm just arguing that for the *specific* case where $host=cygwin and
$target=mingw* (e.g. we know that the underlying platform ALSO supports
running the "target" executables and DLLs),


   I see where you're coming from, but I'm not sure how much it really buys us;


See below.


and if we simply write that off - just declare that all mingw flavours are
cross-hosts and you need to package and install stuff that you've
cross-compiled before it will necessarily work (and of course, 32-bit mingw
folks tend to prefer to have everything statically linked in monolithic
executables exactly to avoid having to distribute dlls with their apps) - I
think we can just skate round the issue and say that you can't necessarily run
a cross-compiled *-pc-*mingw* app straight out of its build dir any more than
you could a cross-compiled *-*linux* or a mips*-*-* app.



No, not out of its build dir.  Out of its "installed in the sysroot (*) 
on the $host" dir.


(*) where I use the term "sysroot" loosely

OTOH, with libtool wrappers, I do indeed mean in the build dir. See below.



   I don't suppose that the mingw cross-compilers in standard linux distros try
to install their runtimes into /usr/bin just because you might maybe have wine
available, do they?


No, but the relationship between linux and wine is more distant (and 
backwards: the cygwin $host runs within a "mingw" win32 native Host that 
is the $target; with wine, the $target itself runs as a NOT-AN-EMULATOR 
within the Host linux that is the $host.)




okay, switching away from compiler land, where

cmake and fortran

[Marco Atzeri]

Hi,
as lapack is moving to cmake as build system,
I started to playing with cmake and I suspect no one
tried before cmake and fortran together on cygwin.

The definition file
/usr/share/cmake-2.6.4/Modules/Platform/CYGWIN-g77.cmake
is clearly wrong. It tries to build libxxx.dll and so on.

Attached the one that I am currently using, copied and modified
from CYGWIN-g77.cmake that seems right.

Could the cmake maintainer give a check and eventually 
report the issue upstream ?

Regards
Marco



  

cmake_patch
Description: Binary data
--
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: gcc4: throwing exception from signal handler

[Christopher Faylor]

On Thu, Jul 08, 2010 at 01:02:28PM -0400, Don Ward wrote:
>Dave Korn wrote:
>
>> On 08/07/2010 14:01, Don Ward wrote:
>>> I would like to be able to catch certain signals (SIGSEGV and SIGSYS)
>>> and throw a C++ exception (to be caught in a try/catch construct).  As a
>>> simple example:
>>
>>> Am I misunderstanding how this should work or doing something wrong?  Or
>>> is this a problem with Cygwin or gcc?
>>
>>  Throwing exceptions from a signal handler is a can of worms that requires
>> support from both the compiler and the C runtime.
>
>Understood!
>
>>  I was working on adding
>> this support for the distro package of gcc-4.5 before I had to go AWOL a
>> couple of weeks ago; it requires building the Cygwin DLL with EH tables, 
>> and
>> adding support in the last-chance stack unwinder in libgcc that is able to
>> unwind past our sigfe/sigbe stuff.
>
>I'm glad someone is (or will be) working on it.  In the meanwhile, I can 
>make do with gcc 3.4.4.

Someone may be looking into this but if this is adding complication to the 
signal
handler it is going to take some real convincing that it should go into the DLL.

Dave, this is something that you should be talking about early rather than 
springing
it as a patch in cygwin-patches.

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: cygport cross compile(r) support [was: Re: cygport patch: suppress libtool fixup step]

[Christopher Faylor]

On Thu, Jul 08, 2010 at 10:34:09AM -0400, Charles Wilson wrote:
>On 7/7/2010 11:39 PM, Yaakov (Cygwin/X) wrote:
>> On Wed, 2010-07-07 at 22:16 -0400, Charles Wilson wrote:
>>> Hmm. That's what I *was* doing: JonY's -src provides a cygport that
>
>> I didn't mean the .cygport(5), I meant cygport(1).  The goal is to make
>> these workarounds unnecessary.
>
>Sure. There's three "status levels" of cygport support for any desired
>behavior:

I'm getting whiplash trying to read about these issues in cygwin-apps and
cygwin.  If Yaakov doesn't mind, I'd like to make discussions of cygport
on-topic in cygwin-apps.  It's sort of been that way for a while now anyway.

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: problem installing libxml

[Larry Hall (Cygwin)]

On 7/9/2010 5:27 AM, cygwin.20.maillinglist wrote:

Von: 
+cygwin+maillinglist+eb14c9acbd.reply-to-list-only-lh#cygwin@spamgourmet.com
On 7/8/2010 9:47 AM, cygwin.20.maillinglist wrote:

Hi Folks,

I have the problem to install libxml. Alter Starting setup as admin I
proceed to the selection of the download, select the mirror
http://cygwin.mirrors.hoobly.com. Enter libxml under Search and found
libxml in the Gnome folder.

When I select the first libxml the setup crashes

How can I install libxml?

I need the libxml to compile xml2.


I already had this installed but reinstalling worked fine.  Did you use
the latest 'setup.exe' from cygwin.com?


I checked that the setup.exe which I was running is the same which I download
from http://www.cygwin.com/ .

Could you please tell me from which mirror you download it, so that I can try
from that mirror.


I specified cygwin.mirrors.hoobly.com since that was the one you were
having difficulty with.

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

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: cygport patch: suppress libtool fixup step

[Christopher Faylor]

On Fri, Jul 09, 2010 at 12:48:38PM -0400, Charles Wilson wrote:
>Let me quote cgf: "cygwin is not linux".

I usually say this when making things work like linux is very hard.  I don't
see how that's the case here.

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: cygport cross compile(r) support [was: Re: cygport patch: suppress libtool fixup step]

[Charles Wilson]

On 7/9/2010 12:54 PM, Christopher Faylor wrote:

On Thu, Jul 08, 2010 at 10:34:09AM -0400, Charles Wilson wrote:

On 7/7/2010 11:39 PM, Yaakov (Cygwin/X) wrote:

On Wed, 2010-07-07 at 22:16 -0400, Charles Wilson wrote:

Hmm. That's what I *was* doing: JonY's -src provides a cygport that



I didn't mean the .cygport(5), I meant cygport(1).  The goal is to make
these workarounds unnecessary.


Sure. There's three "status levels" of cygport support for any desired
behavior:


I'm getting whiplash trying to read about these issues in cygwin-apps and
cygwin.  If Yaakov doesn't mind, I'd like to make discussions of cygport
on-topic in cygwin-apps.  It's sort of been that way for a while now anyway.


Ack.

And thank you! This whole complex of issues is a single discussion; it 
makes little sense to spread them around. I'll confine future response 
to any of these related threads to apps.


--
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: XWin seg fault on Vista (cygwin 1.7)

[Larry Hall (Cygwin)]

On 7/9/2010 8:33 AM, Markus Moeller wrote:

Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.8.0.0 (1080)
Build Date: 2010-04-02

Hi,

I used cygwin with XWin for some time now with an older cygwin release.
I have upadted now to version 1.7 and get the following error:


This is a question that's more appropriate for the cygwin-xfree list.
Please send it there and consult the problem reporting guidelines found
here:



--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

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

Reporting problem requiring rebaseall to solve it.

[Daniel Povey]

Reporting problem and solution, but I would appreciate if cygwin
experts could comment on the underlying reasons why this kind of thing
happens and why rebaseall is needed.

I have done a pretty clean install of the latest Cygwin and want to
report a problem (and solution) so people will be able to fix it
themselves.  I am installing on a domain-joined Win7 machine.  My
installation process is to run setup.exe, only choose wget as an extra
package, and then use the apt-cyg script to install extra packages, as
in:
cp apt-cyg /bin
apt-cyg install `cat packages`
where "packages" is a list of the packages I had from a previous install.
When I try to start X, it fails and I get the following errors in
/var/log/XWin.0.log (see bottom of email).l

I was able to fix this problem by doing "rebaseall" [i.e.: close all
cygwin processes, go to "cmd", cd to c:\cygwin\bin,
and type "ash rebaseall".   This gives the following errors which I am
ignoring for the time being:

C:\cygwin\bin>ash rebaseall
/usr/lib/engines/lib4758cca.so: skipped because not writable
/usr/lib/engines/libaep.so: skipped because not writable
/usr/lib/engines/libatalla.so: skipped because not writable
/usr/lib/engines/libcswift.so: skipped because not writable
/usr/lib/engines/libgmp.so: skipped because not writable
/usr/lib/engines/libchil.so: skipped because not writable
/usr/lib/engines/libnuron.so: skipped because not writable
/usr/lib/engines/libsureware.so: skipped because not writable
/usr/lib/engines/libubsec.so: skipped because not writable
/usr/lib/engines/libcapi.so: skipped because not writable

The errors in XWin.0.log are below, for search purposes.

C:\cygwin\bin>startx
'startx' is not recognized as an internal or external command,
operable program or batch file.

C:\cygwin\bin>
C:\cygwin\bin>pwd
/usr/bin

C:\cygwin\bin>cat XWin.exe^A^K


bash-3.2$ cat XWin.0.log
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.8.0.0 (1080)
Build Date: 2010-04-02

Contact: cygwin-xf...@cygwin.com
XWin was started with the following command line:

/usr/bin/X :0 -auth /home/dpovey/.serverauth.3796

ddxProcessArgument - Initializing default screens
winInitializeDefaultScreens - primary monitor w 1440 h 900
winInitializeDefaultScreens - native DPI x 96 y 96
winInitializeDefaultScreens - Returning
[ 53897.534] winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1
[ 53897.549] (II) xorg.conf is not supported
[ 53897.549] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html
for more information
[ 53897.549] LoadPreferences: /home/dpovey/.XWinrc not found
[ 53897.549] LoadPreferences: Loading /etc/X11/system.XWinrc
[ 53897.549] LoadPreferences: Done parsing the configuration file...
[ 53897.549] winGetDisplay: DISPLAY=:0.0
[ 53897.549] winDetectSupportedEngines - Windows NT/2000/XP
[ 53897.581] winDetectSupportedEngines - DirectDraw installed
[ 53897.581] winDetectSupportedEngines - DirectDraw4 installed
[ 53897.581] winDetectSupportedEngines - Returning, supported engines 0007
[ 53897.596] winSetEngine - Using Shadow DirectDraw NonLocking
[ 53897.596] winAdjustVideoModeShadowDDNL - Using Windows display
depth of 32 bits per pixel
[ 53897.705] winFinishScreenInitFB - Masks: 00ff ff00 00ff
[ 53897.705] Screen 0 added at virtual desktop coordinate (0,0).
[ 53897.705] MIT-SHM extension disabled due to lack of kernel support
[ 53897.737] XFree86-Bigfont extension local-client optimization
disabled due to lack of shared memory support in the kernel
[ 53897.768] (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so
[ 53897.768] (II) GLX: Initialized DRISWRAST GL provider for screen 0
[ 53897.783] [dix] Could not init font path element
/usr/share/fonts/TTF/, removing from list!
[ 53897.783] [dix] Could not init font path element
/usr/share/fonts/OTF/, removing from list!
[ 53897.783] [dix] Could not init font path element
/usr/share/fonts/Type1/, removing from list!
[ 53897.924] (EE) XKB: Could not invoke xkbcomp
[ 53897.924] (EE) XKB: Couldn't compile keymap
[ 53897.924] XKB: Failed to compile keymap
[ 53897.924] Keyboard initialization failed. This could be a missing
or incorrect setup of xkeyboard-config.
[ 53897.924]
Fatal server error:
[ 53897.924] Failed to activate core devices.

--
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: Tab Completion Problem

[Jacob Jacobson]

On 7/8/2010 9:08 AM, Jacob Jacobson wrote:

I recently updated my Cygwin installation and now I get,

[~$:501] cd /c/home/bash: exclude: unbound variable
[~$:501]

when I hit TAB.

I have seen Eric's announcement & followed that.

 >> A new release of bash-completion, 1.2-1, is now available for
 >> download, leaving 1.1-2 as previous.

 >> NEWS:
 >> =
 >> This is a new upstream release.

I put -
. /etc/bash_completion in my .bashrc file.

The file /etc/bash_completion exists.

Cygcheck output attached. Please help.



Worked on it some more to try & debug this. Here is what
I get after "set -x" in bash.

[home$:503] cd /c/home/ab+ local cur 'IFS=
' i j k
+ _get_comp_words_by_ref cur
+ local exclude flag i OPTIND=1
+ words=()
+ local cur cword words
+ upargs=()
+ upvars=()
+ local upargs upvars vcur vcword vprev vwords
+ getopts c:i:n:p:w: flag cur
+ [[ 1 -ge 1 ]]
+ case ${!OPTIND} in
+ vcur=cur
+ let 'OPTIND += 1'
+ [[ 1 -ge 2 ]]
+ __get_cword_at_cursor_by_ref '' words cword cur
+ words=()
+ local cword words
+ __reassemble_comp_words_by_ref '' words cword
+ local exclude i j ref
+ [[ -n '' ]]
+ eval cword=1
++ cword=1
bash: exclude: unbound variable
[home$:503]



--
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: Reporting problem requiring rebaseall to solve it.

[Larry Hall (Cygwin)]

On 7/9/2010 2:57 PM, Daniel Povey wrote:

Reporting problem and solution, but I would appreciate if cygwin
experts could comment on the underlying reasons why this kind of thing
happens and why rebaseall is needed.

I have done a pretty clean install of the latest Cygwin and want to
report a problem (and solution) so people will be able to fix it
themselves.  I am installing on a domain-joined Win7 machine.  My
installation process is to run setup.exe, only choose wget as an extra
package, and then use the apt-cyg script to install extra packages, as
in:
cp apt-cyg /bin
apt-cyg install `cat packages`
where "packages" is a list of the packages I had from a previous install.
When I try to start X, it fails and I get the following errors in
/var/log/XWin.0.log (see bottom of email).l


FWIW, you don't need to use apt-cyg to automate an install of a certain
set of packages.  Using the '-P' parameter of 'setup.exe' to list out the
packages you want to install will work.

If you're looking for a basic overview of why rebasing is necessary in
some cases, you should read /usr/share/doc/Cygwin/rebase*.README.  This
summarizes things quite well.  If you're looking for more details, the
email archives (cygwin-apps) has allot of discussion about it in the
history.  It's a ways back though. ;-)

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

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: cmake and fortran

[Yaakov (Cygwin/X)]

On Fri, 2010-07-09 at 16:50 +, Marco Atzeri wrote:
> as lapack is moving to cmake as build system,
> I started to playing with cmake and I suspect no one
> tried before cmake and fortran together on cygwin.
> 
> The definition file
> /usr/share/cmake-2.6.4/Modules/Platform/CYGWIN-g77.cmake
> is clearly wrong. It tries to build libxxx.dll and so on.
> 
> Attached the one that I am currently using, copied and modified
> from CYGWIN-g77.cmake that seems right.
> 
> Could the cmake maintainer give a check and eventually 
> report the issue upstream ?

I'm not the cmake maintainer, but could you try Ports' cmake-2.8.1-11
and see if that's any better?


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

Re: cygport cross compile(r) support [was: Re: cygport patch: suppress libtool fixup step]

[Yaakov (Cygwin/X)]

On Fri, 2010-07-09 at 12:54 -0400, Christopher Faylor wrote:
> I'm getting whiplash trying to read about these issues in cygwin-apps and
> cygwin.  If Yaakov doesn't mind, I'd like to make discussions of cygport
> on-topic in cygwin-apps.  It's sort of been that way for a while now anyway.

That's fine with me.


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

Re: tar: symlinks unpacked to empty files (tar security problem?)

[Eric Blake]

On 07/04/2010 11:17 AM, Christopher Faylor wrote:
> On Sun, Jul 04, 2010 at 04:50:41AM -0500, Yaakov (Cygwin/X) wrote:
>> With tar-1.23-1 and recent snapshot:
>>
>> echo foo > foo
>> ln -s $PWD/foo bar
>> tar cf test.tar bar foo
>> rm -f bar foo
>> tar xf test.tar
>> ls -l bar foo
>>
>> You will see that 'bar' is a 0-byte file with  permissions instead
>> of a symlink.  The symlink reference need not be absolute; it also
>> happens with relative links in different directories, but does not
>> happen if I just "ln -s foo bar".
> 
> That's because of the way that tar handles symlinks.  If you have a
> reference to an absolute path, tar makes a zero-length regular file
> placeholder.  Then when it is done extracting, tar is supposed to remove
> this file and create the real symlink.  However, the test to make sure
> that it is ok to do this was broken by a recent DLL change.  The inode
> returned the first time that the file was created was != the inode when
> the file is checked later.  So tar thought that the zero-length file was
> modified and silently decided not to create the symlink.

For the longest time, I was carrying a cygwin-specific patch that
ignored the inode check.  Thinking that it was leftovers from 1.5, I
removed that cygwin-specific patch (that is, re-enabled the inode
check), because I didn't have a test case that would trigger it.  It
looks like you have demonstrated the test case, and if cgf fixed the dll
to report the same inode in both situations, then great.  But since I'm
on vacation at the moment, with only limited email access, it will be
another week before I can even think about re-building tar to re-enable
the cygwin-specific patch.  I'll do that, unless cygwin 1.7.6 is
released first and fixes the problem in the meantime.

> I've fixed the cygwin problem - it should be in the next snapshot.  I
> think this silent behavior of tar is not too user friendly though.  It
> seems like there is a pathological situation there where you'd end
> thinking that you'd extracted a symlink without getting the symlink.  In
> fact, I think this is actually a security problem.
> 
> Eric, am I missing something about tar's behavior here?

You're probably right that this should be reported upstream as a
potential hole, where tar should not be silent about failure to restore
a file.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: tar: symlinks unpacked to empty files (tar security problem?)

[Christopher Faylor]

On Fri, Jul 09, 2010 at 06:26:18PM -0600, Eric Blake wrote:
>On 07/04/2010 11:17 AM, Christopher Faylor wrote:
>> On Sun, Jul 04, 2010 at 04:50:41AM -0500, Yaakov (Cygwin/X) wrote:
>>> With tar-1.23-1 and recent snapshot:
>>>
>>> echo foo > foo
>>> ln -s $PWD/foo bar
>>> tar cf test.tar bar foo
>>> rm -f bar foo
>>> tar xf test.tar
>>> ls -l bar foo
>>>
>>> You will see that 'bar' is a 0-byte file with  permissions instead
>>> of a symlink.  The symlink reference need not be absolute; it also
>>> happens with relative links in different directories, but does not
>>> happen if I just "ln -s foo bar".
>> 
>> That's because of the way that tar handles symlinks.  If you have a
>> reference to an absolute path, tar makes a zero-length regular file
>> placeholder.  Then when it is done extracting, tar is supposed to remove
>> this file and create the real symlink.  However, the test to make sure
>> that it is ok to do this was broken by a recent DLL change.  The inode
>> returned the first time that the file was created was != the inode when
>> the file is checked later.  So tar thought that the zero-length file was
>> modified and silently decided not to create the symlink.
>
>For the longest time, I was carrying a cygwin-specific patch that
>ignored the inode check.  Thinking that it was leftovers from 1.5, I
>removed that cygwin-specific patch (that is, re-enabled the inode
>check), because I didn't have a test case that would trigger it.  It
>looks like you have demonstrated the test case, and if cgf fixed the dll
>to report the same inode in both situations, then great.  But since I'm
>on vacation at the moment, with only limited email access, it will be
>another week before I can even think about re-building tar to re-enable
>the cygwin-specific patch.  I'll do that, unless cygwin 1.7.6 is
>released first and fixes the problem in the meantime.

AFAIK, this was a problem only in snapshots so there is no reason for a
new release.

cgf
(who's also on vacation)

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