Relative vs. Absolute path problem

[Stephen Henry]

Hi,

I have a really strange problem with my Cygwin installation. It
concerns a filename parameter given to a application launched from the
bash command prompt. The problem is as follows:

I have an application that takes a filename parameter. The application
uses the 'fopen' command to open the filename and process the file
(very simple really). The problem is that when I type the filename as
an absolute path, the file cannot be read, but when it is typed as a
relative path, it works fine. For example,

This works perfectly (from a directory in my home directory):
$ ./x264.exe -o out.h264 ../../../testseq/yuv420/COASTGUARD-YUV420-CIF 352x288

Whilst this does not:
./x264.exe -o out.264 /testseq/yuv420/COASTGUARD-YUV420-CIF 352x288


The obvious problem would be that the two paths are not equal, but I
can assure you that this is not the case -they both point to the same
file. The only difference is that one path is relative and the other
is absolute. The permissions are set so all users can read the file.

I'm not exactly new to Cygwin/UNIX, but this problem has me completely
stumped. Any ideas?

Thanks for your help,

Stephen

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: sockets pbs..

[Corinna Vinschen]

On Jan 30 17:04, jano trouba wrote:
> 
> 
> Hello everybody...
> 
> I uploaded last (as of yesterday) version of cygwin..
> 
> Then I tried compiling some of my libraries...
> 
> Here is the result on one dealing with sockets :
> 
> cc -Wall  -D_POSIX_SOURCE -D__rtems__ -mno-cygwin -mwindows  -I../include/  
^^^
> [...]
> So did I miss a flag in order to compile, or a bad location, or is it a bug 
> ??

No, you used a flag too many.  The Cygwin header files and Cygwin
capabilities don't make any sense when trying to build a native Windows
application.


Corinna

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

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: sockets pbs..

[jano trouba]

> cc -Wall  -D_POSIX_SOURCE -D__rtems__ -mno-cygwin -mwindows  
-I../include/

^^^
> [...]
> So did I miss a flag in order to compile, or a bad location, or is it a 
bug

> ??

No, you used a flag too many.  The Cygwin header files and Cygwin
capabilities don't make any sense when trying to build a native Windows
application.



OK so how do I do if I want at the same time to call

   timerclear()

  ??

by looking into the sys/time.h, this definition is wrapped around

#if defined (__rtems__) || defined (__CYGWIN__)

.

_
Windows Live Messenger sur i-mode™ : dialoguez avec vos amis depuis votre 
mobile comme sur PC ! http://mobile.live.fr/messenger/bouygues/



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Perl bug?

[Corinna Vinschen]

On Jan 28 11:57, Yitzchak Scott-Thoennes wrote:
> Corinna Vinschen wrote:
> > Thanks for the info.  It's interesting to know.  What I still don't get,
> > however, is the fact that the same statement does not waste memory on
> > the x86 Linux Perl 5.8.5, but does on the x86 Cygwin Perl 5.8.7 and the
> > x86_64 Linux 5.8.8.  So it has been introduced only in later versions?
> > And why is it defended?  It doesn't seem to make sense, rather on the
> > contrary.
> 
> This behaviour hasn't changed that I know of.  I verified that a 5.8.5
> cygwin perl behaves the same way.  Could you confirm your x86 Linux
> Perl 5.8.5 results again, and send me (privately if you wish) the
> output of: perl -MConfig=config_sh -we'print config_sh' from that
> perl?

I just ran the testcase under strace on the Linux box again and to my
surprise it behaved identical to the Cygwin and the 64 bit Linux
version, as you say.  What have I done wrong in my first tests?  Was I
hallucinating, caffein-induced maybe?


Corinna

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

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[ANNOUNCEMENT] Updated: cygwin-1.5.24-2

[Corinna Vinschen]

I've made a new version of the Cygwin DLL and associated utilities
available for download.

The 1.5.24-2 release fixes only one bug introduced in 1.5.24-1.
-1 was non-functional on XP 64 bit and 2003 Server 64 bit editions.
This should be rectified now.


To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

If you have questions or comments, please send them to the Cygwin
mailing list.  See http://cygwin.com/lists.html for details.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from 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:

[EMAIL PROTECTED]

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.

Corinna Vinschen
Red Hat

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: sockets pbs..

[jano trouba]

And also I do not understand :

> cc -Wall  -D_POSIX_SOURCE -D__rtems__ -mno-cygwin -mwindows  
-I../include/

   ^^^
> [...]
> So did I miss a flag in order to compile, or a bad location, or is it a 
bug

> ??

No, you used a flag too many.  The Cygwin header files and Cygwin
capabilities don't make any sense when trying to build a native Windows
application.



the -mno-cygwin flag means NOT to use cygwin-sepcific things, no ?

So how come by including sys/socket.h do I find myself including 
cygwin/socket.h ?


_
Découvrez le Blog heroic Fantaisy d'Eragon! 
http://eragon-heroic-fantasy.spaces.live.com/



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Newly-installed bash 3.2.9-10 (cygwin 1.5.24-1) exits when I try to execute a program

[Corinna Vinschen]

On Jan 30 06:12, Eric Blake wrote:
> This sounds like a problem in cygwin 1.5.24 with forking in general on
> xp64 [...]

Yes, my fault.  I just uploaded a fixed 1.5.24-2 Cygwin release.


Corinna

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

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Support planned for vista symbolic links?

[Corinna Vinschen]

On Jan 28 13:38, Shankar Unni wrote:
> This article from Mark "Sysinternals" Russinovitch discusses the new 
> "real" symbolic link feature in Vista ("real" in that it's classic 
> Unix-style, where the symlink is interpreted on the local OS, even for 
> links in mounted shares, and can refer to either a file or a directory):
> 
> http://www.microsoft.com/technet/technetmag/issues/2007/02/VistaKernel/default.aspx#S4
> 
> The only catch he mentions is that you need a special privilege to 
> create these symlinks, and that privilege is only granted to 
> administrators by default. (Usual windows reason: to "protect" users 
> from tools that are not symbolic-link-aware)
> 
> Anyway: is any support planned in cygwin and/or coreutils for this 
> feature?  (specifically, supporting symlink(), S_ISLNK support in stat, 
> etc.)

See the snapshots.  The next major Cygwin release will be able to read
native NTFS symlinks and treats them as symlinks.  However, it's not
planned to utilize native NTFS symlinks when creating symlinks in
Cygwin.  This has two reasons.

One is the above mentioned non-sensical restriction that only users with
a special privilege may create native symlinks.

The other one is that native symlinks on remote Vista shares are not
implemented transparently to non-Vista client machines trying to access
a Vista share.  An XP client can not access the target file of the
symlink by opening it.

Frustrating, isn't it?


Corinna

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

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: sockets pbs..

[Corinna Vinschen]

On Jan 31 10:52, jano trouba wrote:
> 
> And also I do not understand :
> 
> >> cc -Wall  -D_POSIX_SOURCE -D__rtems__ -mno-cygwin -mwindows  
> >-I../include/
> >   ^^^
> >> [...]
> >> So did I miss a flag in order to compile, or a bad location, or is it a 
> >bug
> >> ??
> >
> >No, you used a flag too many.  The Cygwin header files and Cygwin
> >capabilities don't make any sense when trying to build a native Windows
> >application.
> >
> 
> the -mno-cygwin flag means NOT to use cygwin-sepcific things, no ?
> 
> So how come by including sys/socket.h do I find myself including 
> cygwin/socket.h ?

sys/socket.h is also a Cygwin thingy.  Only the include files under
/usr/include/w32api and /usr/include/mingw are useful for non-cygwin
apps.  If you want to use the POSIX headers, build a Cygwin app.


Corinna

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

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: sockets pbs..

[jano trouba]

sys/socket.h is also a Cygwin thingy.  Only the include files under
/usr/include/w32api and /usr/include/mingw are useful for non-cygwin
apps.  If you want to use the POSIX headers, build a Cygwin app.


OK

Let's say I do not want the POSIX flag. And I want to use only w32api and 
mingw..


so  what should be my flags ?


> >> cc -Wall  -D_POSIX_SOURCE -D__rtems__ -mno-cygwin -mwindows


cc -Wall -march=athlon-xp -mno-cygwin -mwindows???

But the /usr/include directory is the default, isn't it ?
All the files in that directory are common, aren't they ?
Or shoudl I re-define the default as being /usr/include/mingw ?

_
Gagnez des pc Windows Vista avec Live.com http://www.image-addict.fr/


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: sockets pbs..

[Christopher Faylor]

On Wed, Jan 31, 2007 at 12:51:27PM +, jano trouba wrote:
>>sys/socket.h is also a Cygwin thingy.  Only the include files under
>>/usr/include/w32api and /usr/include/mingw are useful for non-cygwin
>>apps.  If you want to use the POSIX headers, build a Cygwin app.
>
>OK
>
>Let's say I do not want the POSIX flag. And I want to use only w32api and 
>mingw..

Then you probably shouldn't be using Cygwin and probably should be checking
out the MinGW project at www.mingw.org .

Asking the cygwin mailing list for advice in how not to use Cygwin probably
isn't the most profitable of exercises.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: cygwin follow up

[Jason Tishler]

John,

Please see the following:

http://cygwin.com/acronyms/#PPIOSPE

On Wed, Jan 31, 2007 at 12:54:51AM +0100, John F Burkhart wrote:
> I apologize to hijack your email, but I've found this post:
> http://www.thescripts.com/forum/thread32391.html
> 
> and I am having an identical problem.
> 
> I'm a newbie. I've installed cygwin (without python), and then installed 
> enthought - because I'm hoping to use the scypy tools, etc.
> Anyway, I'm running the latest cygwin on an xp pro machine. I use the 
> .bat file (pasted below) to launch cygwin and an xterm. Notice i put the 
> SET CYGWIN=notty line in there, but it hasn't done anything to improve 
> the situation. Any thoughts would be greatly appreciated.
> 
> Thank you,
> john
> 
> 
> =  BEGINFILE =
> 
> @echo off
> SET DISPLAY=127.0.0.1:0.0
> 
> 
> REM
> REM The path in the CYGWIN_ROOT environment variable assignment assume
> REM that Cygwin is installed in a directory called 'cygwin' in the root
> REM directory of the current drive.  You will only need to modify
> REM CYGWIN_ROOT if you have installed Cygwin in another directory.  For
> REM example, if you installed Cygwin in \foo\bar\baz\cygwin, you will need
> REM to change \cygwin to \foo\bar\baz\cygwin.
> REM
> REM This batch file will almost always be run from the same drive (and
> REM directory) as the drive that contains Cygwin/X, therefore you will
> REM not need to add a drive letter to CYGWIN_ROOT.  For example, you do
> REM not need to change \cygwin to c:\cygwin if you are running this
> REM batch file from the C drive.
> REM
> 
> SET CYGWIN_ROOT=\cygwin
> SET RUN=%CYGWIN_ROOT%\bin\run -p /usr/X11R6/bin
> SET CYGWIN=notty
> 
> SET PATH=.;%CYGWIN_ROOT%\bin;%CYGWIN_ROOT%\usr\X11R6\bin;%PATH%
> 
> SET XAPPLRESDIR=/usr/X11R6/lib/X11/app-defaults
> SET XCMSDB=/usr/X11R6/lib/X11/Xcms.txt
> SET XKEYSYMDB=/usr/X11R6/lib/X11/XKeysymDB
> SET XNLSPATH=/usr/X11R6/lib/X11/locale
> 
> 
> REM
> REM Cleanup after last run.
> REM
> 
> if not exist %CYGWIN_ROOT%\tmp\.X11-unix\X0 goto CLEANUP-FINISH
> attrib -s %CYGWIN_ROOT%\tmp\.X11-unix\X0
> del %CYGWIN_ROOT%\tmp\.X11-unix\X0
> 
> :CLEANUP-FINISH
> if exist %CYGWIN_ROOT%\tmp\.X11-unix rmdir %CYGWIN_ROOT%\tmp\.X11-unix
> 
> 
> REM
> REM The error "Fatal server error: could not open default font 'fixed'" is
> REM caused by using a DOS mode mount for the mount that the Cygwin/X
> REM fonts are accessed through.  See the Cygwin/X FAQ for more
> REM information:
> REM http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-error-font-eof
> REM
> 
> if "%OS%" == "Windows_NT" goto OS_NT
> 
> REM Windows 95/98/Me
> echo startxwin.bat - Starting on Windows 95/98/Me
> 
> goto STARTUP
> 
> :OS_NT
> 
> REM Windows NT/2000/XP/2003
> echo startxwin.bat - Starting on Windows NT/2000/XP/2003
> 
> :STARTUP
> 
> REM Brief descriptions of XWin-specific options:
> REM
> REM -screen scr_num [width height]
> REM  Enable screen scr_num and optionally specify a width and
> REM  height for that screen.
> REM  Most importantly, any parameters specified before the first -screen
> REM  parameter apply to all screens.  Any options after the first 
> -screen
> REM  parameter apply only to the screen that precedes the parameter.
> REM  Example:
> REM  XWin -fullscreen -screen 0 -screen 1 -depth 8 -screen 2
> REM  All screens will be fullscreen, but screen 2 will be depth 8, while
> REM  screens 0 and 1 will be the default depth (whatever depth Windows
> REM  is currently running at).
> REM -multiwindow
> REM  Start an integrated Windows-based window manager.  Not to be used
> REM  with -rootless nor -fullscreen.
> REM -rootless
> REM  Use a transparent root window with an external window manager
> REM  (such as twm).  Not to be used with -multiwindow nor
> REM  with -fullscreen.
> REM -fullscreen
> REM  Use a window as large as possible on the primary monitor.
> REM -multiplemonitors
> REM  Create a root window that covers all monitors on a
> REM  system with multiple monitors.
> REM -clipboard
> REM  Enable the integrated version of xwinclip.  Do not use in
> REM  conjunction with the xwinclip program.
> REM -depth bits_per_pixel
> REM  Specify the screen depth to run at (in bits per pixel) using a
> REM  DirectDraw-based engine in conjunction with the -fullscreen
> REM  option, ignored if the -fullscreen option is not specified.
> REM  By default, you will be using a DirectDraw based engine on any
> REM  system that supports it.
> REM -unixkill
> REM  Trap Ctrl+Alt+Backspace as a server shutdown key combination.
> REM -nounixkill
> REM  Disable Ctrl+Alt+Backspace as a server shutdown key combination 
> (default).
> REM  Example:
> REM  XWin -unixkill -screen 0 -screen 1 -screen 2 -nounixkill
> REM  Screens 0 and 1 will allow Ctrl+Alt+Backspace, but screen 2 
> will not.
> REM -winkill
> REM  Trap Alt+F4 as a server shutdown key

Re: Relative vs. Absolute path problem

[Patrick Herbst]

from your home directory ../../../ = one level up from the cygwin root.

for example... if home is c:\cygwin\home\user then that relative path
would put you at c:\

the root (/) for cygwin is actually the cygwin directory (c:\cygwin)

if you're trying to get just on your c:\ you have to specify it as /cygdrive/c/


I have an application that takes a filename parameter. The application
uses the 'fopen' command to open the filename and process the file
(very simple really). The problem is that when I type the filename as
an absolute path, the file cannot be read, but when it is typed as a
relative path, it works fine. For example,


This works perfectly (from a directory in my home directory):
$ ./x264.exe -o out.h264 ../../../testseq/yuv420/COASTGUARD-YUV420-CIF 352x288


Whilst this does not:
./x264.exe -o out.264 /testseq/yuv420/COASTGUARD-YUV420-CIF 352x288

The obvious problem would be that the two paths are not equal, but I
can assure you that this is not the case -they both point to the same
file. The only difference is that one path is relative and the other
is absolute. The permissions are set so all users can read the file.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Relative vs. Absolute path problem

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Stephen Henry on 1/31/2007 2:50 AM:
> 
> This works perfectly (from a directory in my home directory):
> $ ./x264.exe -o out.h264 ../../../testseq/yuv420/COASTGUARD-YUV420-CIF
> 352x288
> 
> Whilst this does not:
> ./x264.exe -o out.264 /testseq/yuv420/COASTGUARD-YUV420-CIF 352x288

Have you tried 'stat ../../../testseq/yuv420/COASTGUARD-YUV420-CIF
/testseq/yuv420/COASTGUARD-YUV420-CIF' to prove to yourself that they are
the same file?  If that also sees the difference, then you can resort to
strace to see what is actually being attempted in the two cases; if it
does not see any difference, then I would suspect a bug in x264.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFwJUl84KuGfSFAYARAszxAKDW/+Z4iYIYA2kOHfHQTdOQ7aDpjwCfcX68
EHAP8Ayr2S2THOMmMcJNVmY=
=1kYt
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Relative vs. Absolute path problem

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Patrick Herbst on 1/31/2007 6:07 AM:
> from your home directory ../../../ = one level up from the cygwin root.

One level up from cygwin root is still cygwin root.  /.. == / as required
by POSIX.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFwJXs84KuGfSFAYARAmNuAKDIz4ZdjBVoY2FHnd3feGnQfEL3IgCffzuE
fSzs/Bxb2ntq1vhKnJNy4PY=
=4Rkq
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Eliminating -mno-cygwin from gcc?

[Christopher Faylor]

When I was maintaining cygwin's gcc, I often thought about eliminating
-mno-cygwin and just providing a pure mingw cross compiler in the
distribution.  I really don't know why it wasn't done that way to begin
with.  I have vague recollections of arguing for this when -mno-cygwin
was first introduced by Geoff Noer but apparently I wasn't very
persuasive.

I know that this will probably be another "Death of Cygwin predicted"
experience but I really can't see any benefit in the current
arrangement.  The code which handles -mno-cygwin in gcc (which, for the
most part, I wrote) is ugly and non-foolproof and binutils support is
not great.

How about if we eliminate -mno-cygwin from future releases and either
provide our own mingw cross-tools or wrap the offerings from mingw.org?
This would mean that instead of saying 'gcc -mno-cygwin', you'd say:
'i686-mingw-gcc' which would, I know, make a few computers spontaneously
self-destruct however, I really don't think that the -mno-cygwin belongs
in gcc.  No other port of gcc has anything like this.

If we REALLY wanted to preserve -mno-cygwin, we could do so as a shell
script wrapper for gcc but, personally, I think I'd rather just tell
people to use the cross-compiler.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Eliminating -mno-cygwin from gcc?

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Christopher Faylor on 1/31/2007 6:13 AM:
> 
> How about if we eliminate -mno-cygwin from future releases and either
> provide our own mingw cross-tools or wrap the offerings from mingw.org?
> This would mean that instead of saying 'gcc -mno-cygwin', you'd say:
> 'i686-mingw-gcc' which would, I know, make a few computers spontaneously
> self-destruct however, I really don't think that the -mno-cygwin belongs
> in gcc.  No other port of gcc has anything like this.

Fine by me, especially since when TRYING to cross compile, autoconf issues
a nasty warning:

$ ../configure --host=i686-pc-mingw32 --build=i686-pc-cygwin \
  CC='gcc -mno-cygwin' host_alias=i686-pc-mingw32
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for i686-pc-mingw32-strip... no
checking for strip... strip
configure: WARNING: In the future, Autoconf will not detect cross-tools
whose name does not start with the host triplet.  If you think this
configuration is useful to you, please write to [EMAIL PROTECTED]
checking build system type... i686-pc-cygwin
checking host system type... i686-pc-mingw32
...

I would much rather call the cross-compiler i686-mingw-gcc than the
current name of 'gcc -mno-cygwin'.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFwJce84KuGfSFAYARAgPzAJ9N36/FVbtZOde+/og9osY1r2FejACdER87
Wm9030d7lt4uZwNLwmd/Ze0=
=Nl80
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Eliminating -mno-cygwin from gcc?

[Samuel Thibault]

Eric Blake, le Wed 31 Jan 2007 06:18:22 -0700, a écrit :
> I would much rather call the cross-compiler i686-mingw-gcc than the
> current name of 'gcc -mno-cygwin'.

Same for me.

samuel

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Eliminating -mno-cygwin from gcc?

[Christopher Faylor]

On Wed, Jan 31, 2007 at 02:27:00PM +0100, Samuel Thibault wrote:
>Eric Blake, le Wed 31 Jan 2007 06:18:22 -0700, a ?crit :
>> I would much rather call the cross-compiler i686-mingw-gcc than the
>> current name of 'gcc -mno-cygwin'.
>
>Same for me.

Thinking about this some more, it seems like we'd need a real
cygwin-based mingw cross compiler rather than a wrapped mingw compiler
since otherwise there would be path and signal issues.

And, as long as we're talking about cross-compilers, a cygwin -> linux
cross compiler would probably be nice, too.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Eliminating -mno-cygwin from gcc?

[Corinna Vinschen]

On Jan 31 08:31, Christopher Faylor wrote:
> On Wed, Jan 31, 2007 at 02:27:00PM +0100, Samuel Thibault wrote:
> >Eric Blake, le Wed 31 Jan 2007 06:18:22 -0700, a ?crit :
> >> I would much rather call the cross-compiler i686-mingw-gcc than the
> >> current name of 'gcc -mno-cygwin'.
> >
> >Same for me.
> 
> Thinking about this some more, it seems like we'd need a real
> cygwin-based mingw cross compiler rather than a wrapped mingw compiler
> since otherwise there would be path and signal issues.

While I agree with the general idea, I have to add the obligatory hint
that there are many projects out there which build environment requires
`gcc -mno-cygwin' to work.  All of them will break with at least 50% of
the lost user base asking on the Cygwin list for help.

So I'm wondering if we are not better off with sticking to the
`gcc -mno-cygwin' interface, regardless how this is implemented under
the hood.

> And, as long as we're talking about cross-compilers, a cygwin -> linux
> cross compiler would probably be nice, too.

Sorry, but we don't support Linux on this mailing list. ;)


Corinna

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

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: hang when using pthread and fork in 1.5.23-1 and snapshot 20070118, and now 1.5.24-1.

[Brian Ford]

On Fri, 26 Jan 2007, Peter Rehley wrote:

> Hello,
>
> I tried the latest release of cygwin1.dll (1.5.24-1) and it still is
> hanging in the same way.  I've tried to debug further with gdb, but
> so far I haven't got any useful information out of gdb.
>
> I'll keep trying to get some debug information, but if any one else
> can reproduce the problem I would be most appreciative.

I can reproduce a problem.  Your descriptions of it are a bit hard to
follow, so I'm not sure if it is your problem or not.  Unfortunately, I
don't have time to debug it right now.  I do have a few comments, though.

Why are you creating a thread just to fork/exec another process?

Pedantically, I believe you are supposed to call _exit, not exit, if fork
fails as stated here in the Solaris man page for fork:

 An applications should call _exit() rather than exit(3C)  if
 it  cannot execve(), since exit() will flush and close stan-
 dard I/O channels and thereby corrupt the  parent  process's
 standard I/O data structures. Using exit(3C) will flush buf-
 fered data twice. See exit(2).

I don't know, however, if this is really true in Cygwin, but it might
explain some misdiagnosed hangs on your part.

Also, the execve call appears to be suspect.  Again, the Solaris man page
for execve states:

 The value in
 argv[0] should point to a filename that is  associated  with
 the process being started by one of the exec functions.
[snip]
 As indicated, argc is at least one and the
 first member of the array points to a string containing  the
 name of the file.

Attached is a modified test case that fixes a few of these issues, but
still hangs (or stutters; it does appear to proceed after long periods of
time).

-- 
Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew.../* main.cc

 *

 */



#include 

#include 

#include 

#include 

#include 



void usage()

  {

  printf("Usage:\n");

  printf("-p   - use program instead of /bin/ls \n");

  exit(1);

  }



void * forkit2me(void *data)

  {



  pid_t pid;



  printf("forking\n");

  if ((pid = fork()) < 0 )

{

printf("Unable to fork\n");

_exit(1);

}

  else if (pid == 0 )

{

printf ("child: %s\n", (char *)data);



execle((char *)data,(char *)data, NULL,NULL);



perror("exec failed");

_exit(1);

}

  else

{

printf ("parent\n");

}

  printf ("done here\n");



  return data;

  }



int main(int argc, char * argv[])

  {

  int quit=0;



  static char * prog2run = "/bin/ls";

  if (argc > 0)

{

for (int i=1; i < argc; i++)

  {

  if ( argv[i][0]== '-' )

{

switch (argv[i][1])

  {

  case 'p':

if ( i+1 < argc )

  {

  prog2run=argv[i+1];

  i++;

  }

break;

  default:

usage();

  }

}

  }

}



  fcntl( fileno( stdout ), F_SETFD, 1 );

  fcntl( fileno( stderr ), F_SETFD, 1 );



  int rc;

  pthread_attr_t ta;

  pthread_t threadId;

  rc=pthread_attr_init(&ta);

  if (rc)

{

printf("pthread_attr_init failed: rc (%d)\n",rc);

return 1;

}



  rc=pthread_attr_setdetachstate(&ta,PTHREAD_CREATE_DETACHED);

  if (rc)

{

printf("pthread_attr_setdetachstate failed: rc (%d)\n",rc);

return 1;

}



  while (!quit)

{

printf("here we go\n");

 

#ifdef PRFAIL

printf("creating thread\n");

#endif

rc=pthread_create(&threadId, &ta, forkit2me, prog2run);

if (rc)

  {

  printf("pthread_create failed: rc (%d)\n",rc);

  break;

  }

#ifdef PRFAIL

printf("created\n");

#endif

}



  return 0;

  }



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Eliminating -mno-cygwin from gcc?

[Dave Korn]

On 31 January 2007 13:49, Corinna Vinschen wrote:

[yep, ntsec, haven't forgotten. sorry for slowness!]

> On Jan 31 08:31, Christopher Faylor wrote:
>> On Wed, Jan 31, 2007 at 02:27:00PM +0100, Samuel Thibault wrote:
>>> Eric Blake, le Wed 31 Jan 2007 06:18:22 -0700, a ?crit :
 I would much rather call the cross-compiler i686-mingw-gcc than the
 current name of 'gcc -mno-cygwin'.
>>> 
>>> Same for me.
>> 
>> Thinking about this some more, it seems like we'd need a real
>> cygwin-based mingw cross compiler rather than a wrapped mingw compiler
>> since otherwise there would be path and signal issues.
> 
> While I agree with the general idea, I have to add the obligatory hint
> that there are many projects out there which build environment requires
> `gcc -mno-cygwin' to work.  All of them will break with at least 50% of
> the lost user base asking on the Cygwin list for help.
> 
> So I'm wondering if we are not better off with sticking to the
> `gcc -mno-cygwin' interface, regardless how this is implemented under
> the hood.


  My preference would be to keep it and fix the one-or-two minor bugs in the
way it sets up the include/lib search paths.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[Fwd: CYGWIN "notty" (enthought solution?)]

[John F Burkhart]

Hello all. I've found this post:

http://www.thescripts.com/forum/thread32391.html
and I am having an identical problem.

I'm a newbie. I've installed cygwin (without python), and then installed 
enthought - because I'm hoping to use the scypy tools, etc.
Anyway, I'm running the latest cygwin on an xp pro machine. I use the 
.bat file (pasted below) to launch cygwin and an xterm. Notice i put the 
SET CYGWIN=notty line in there, but it hasn't done anything to improve 
the situation. Could someone perhaps explicitly sate how to set 
Cygwin=notty?

Any thoughts would be greatly appreciated.

Thank you,
john

=  BEGINFILE =

@echo off
SET DISPLAY=127.0.0.1:0.0

REM
REM The path in the CYGWIN_ROOT environment variable assignment assume
REM that Cygwin is installed in a directory called 'cygwin' in the root
REM directory of the current drive.  You will only need to modify
REM CYGWIN_ROOT if you have installed Cygwin in another directory.  For
REM example, if you installed Cygwin in \foo\bar\baz\cygwin, you will need
REM to change \cygwin to \foo\bar\baz\cygwin.
REM
REM This batch file will almost always be run from the same drive (and
REM directory) as the drive that contains Cygwin/X, therefore you will
REM not need to add a drive letter to CYGWIN_ROOT.  For example, you do
REM not need to change \cygwin to c:\cygwin if you are running this
REM batch file from the C drive.
REM

SET CYGWIN_ROOT=\cygwin
SET RUN=%CYGWIN_ROOT%\bin\run -p /usr/X11R6/bin
SET CYGWIN=notty

SET PATH=.;%CYGWIN_ROOT%\bin;%CYGWIN_ROOT%\usr\X11R6\bin;%PATH%

SET XAPPLRESDIR=/usr/X11R6/lib/X11/app-defaults
SET XCMSDB=/usr/X11R6/lib/X11/Xcms.txt
SET XKEYSYMDB=/usr/X11R6/lib/X11/XKeysymDB
SET XNLSPATH=/usr/X11R6/lib/X11/locale

REM
REM Cleanup after last run.
REM

if not exist %CYGWIN_ROOT%\tmp\.X11-unix\X0 goto CLEANUP-FINISH
attrib -s %CYGWIN_ROOT%\tmp\.X11-unix\X0
del %CYGWIN_ROOT%\tmp\.X11-unix\X0

:CLEANUP-FINISH
if exist %CYGWIN_ROOT%\tmp\.X11-unix rmdir %CYGWIN_ROOT%\tmp\.X11-unix

REM
REM The error "Fatal server error: could not open default font 'fixed'" is
REM caused by using a DOS mode mount for the mount that the Cygwin/X
REM fonts are accessed through.  See the Cygwin/X FAQ for more
REM information:
REM http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-error-font-eof
REM

if "%OS%" == "Windows_NT" goto OS_NT

REM Windows 95/98/Me
echo startxwin.bat - Starting on Windows 95/98/Me

goto STARTUP

:OS_NT

REM Windows NT/2000/XP/2003
echo startxwin.bat - Starting on Windows NT/2000/XP/2003

:STARTUP

REM Brief descriptions of XWin-specific options:
REM
REM -screen scr_num [width height]
REM  Enable screen scr_num and optionally specify a width and
REM  height for that screen.
REM  Most importantly, any parameters specified before the first -screen
REM  parameter apply to all screens.  Any options after the first 
-screen

REM  parameter apply only to the screen that precedes the parameter.
REM  Example:
REM  XWin -fullscreen -screen 0 -screen 1 -depth 8 -screen 2
REM  All screens will be fullscreen, but screen 2 will be depth 8, while
REM  screens 0 and 1 will be the default depth (whatever depth Windows
REM  is currently running at).

REM -multiwindow
REM  Start an integrated Windows-based window manager.  Not to be 

used

REM  with -rootless nor -fullscreen.
REM -rootless
REM  Use a transparent root window with an external window manager
REM  (such as twm).  Not to be used with -multiwindow nor
REM  with -fullscreen.
REM -fullscreen
REM  Use a window as large as possible on the primary monitor.
REM -multiplemonitors
REM  Create a root window that covers all monitors on a
REM  system with multiple monitors.
REM -clipboard
REM  Enable the integrated version of xwinclip.  Do not use in
REM  conjunction with the xwinclip program.
REM -depth bits_per_pixel
REM  Specify the screen depth to run at (in bits per pixel) using a
REM  DirectDraw-based engine in conjunction with the -fullscreen
REM  option, ignored if the -fullscreen option is not specified.
REM  By default, you will be using a DirectDraw based engine on any
REM  system that supports it.
REM -unixkill
REM  Trap Ctrl+Alt+Backspace as a server shutdown key combination.
REM -nounixkill
REM  Disable Ctrl+Alt+Backspace as a server shutdown key 

combination (default).

REM  Example:
REM  XWin -unixkill -screen 0 -screen 1 -screen 2 -nounixkill
REM  Screens 0 and 1 will allow Ctrl+Alt+Backspace, but screen 2 

will not.

REM -winkill
REM  Trap Alt+F4 as a server shutdown key combination (default).
REM -nowinkill
REM  Disable Alt+F4 as a server shutdown key combination.
REM -scrollbars
REM  Enable resizing of the server display window.  Do not use in 

conjunction

REM  with -multiwindow nor with -rootless.
REM -nodecoration
REM  Draw the server root window without a title bar or border.
REM  Do not use

Re: hang when using pthread and fork in 1.5.23-1 and snapshot 20070118.

[Al Slater]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Peter Rehley wrote:
> Hello,
> 
> One of the applications I've been working with has hanging issues.  It
> will sometimes work properly, and sometimes it will hang and never
> continue through the rest of the program.

I have not done any pthread programming under cygwin, but I have done a
fair bit under Solaris.

In my experience threads and fork are not good bedfellows, you need to
excercise care in order to avoid deadlock.

- From the solaris fork() man page :

  fork() Safety
 If a multithreaded application calls fork() or fork1(),  and
 the  child  does  more  than  simply call one of the exec(2)
 functions, there is a possibility of deadlock  occurring  in
 the  child. The application should use pthread_atfork(3C) to
 ensure safety with respect to this deadlock. Should there be
 any outstanding mutexes throughout the process, the applica-
 tion should call pthread_atfork() to wait  for  and  acquire
 those  mutexes prior to calling fork() or fork1(). See  "MT-
 Level of Libraries" on the attributes(5) manual page.

Using stdio in the child after fork in a multithreaded apps has caused
me pain on many occasions, also std::string in c++.

A recommended way to deal with this that I have seen on the web is to
spawn a process before any threads to handle the forks, and use pipes to
communicate between the threads and the forking process.

- --
Al Slater

Technical Director
Stanton Consultancy Ltd

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFwLEPz4fTOFL/EDYRAmIEAJ43G/LidV+qDdG9Yr2CdxJ2B2L/lwCfTHfI
D1/DfKCQpuda8Kw2OTii51k=
=OaGK
-END PGP SIGNATURE-


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Eliminating -mno-cygwin from gcc?

[Christopher Faylor]

On Wed, Jan 31, 2007 at 02:48:42PM +0100, Corinna Vinschen wrote:
>On Jan 31 08:31, Christopher Faylor wrote:
>> On Wed, Jan 31, 2007 at 02:27:00PM +0100, Samuel Thibault wrote:
>> >Eric Blake, le Wed 31 Jan 2007 06:18:22 -0700, a ?crit :
>> >> I would much rather call the cross-compiler i686-mingw-gcc than the
>> >> current name of 'gcc -mno-cygwin'.
>> >
>> >Same for me.
>> 
>> Thinking about this some more, it seems like we'd need a real
>> cygwin-based mingw cross compiler rather than a wrapped mingw compiler
>> since otherwise there would be path and signal issues.
>
>While I agree with the general idea, I have to add the obligatory hint
>that there are many projects out there which build environment requires
>`gcc -mno-cygwin' to work.  All of them will break with at least 50% of
>the lost user base asking on the Cygwin list for help.

Yes.  I think I made this point, although in a facetious manner.

The problem with "-mno-cygwin" is that its presence opens us up to all
sorts of confusion, as witnessed in the recent thread.  If the option is
there then surely we must have to support it right?  Why can't I pull in
cygwin headers?  That's what I want!

Anyway, we've decided to drop windows 98 support in Cygwin 1.7.0.  I
don't see this as much different.  We'll surely hear wails about no
support for Windows 9x/Me, too, but we've made the decision that support
for Windows 98 is not worth the effort.

Removing -mno-cygwin means that we'd be trading "How come I can't use
sys/socket.h when I type -mno-cygwin?" questions for "Why does gcc say
cc1: invalid option `no-cygwin'?"  If we did provide some sort of optional
shell script wrapper to be used with the mingw cross-compiler that should
satisfy people who really have to upgrade their C compilers.

What this may imply is that we need some sort of early warning system in
setup.exe.  If we had some way of saying "Warning: the following changes
have been made which could affect you.  Are you sure?" then maybe we
could eliminate a lot of people who are upset about make, bash, gcc, cygwin...

>> And, as long as we're talking about cross-compilers, a cygwin -> linux
>> cross compiler would probably be nice, too.
>
>Sorry, but we don't support Linux on this mailing list. ;)

Yes we do.  I just changed the cygwin web page.  :-)

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Eliminating -mno-cygwin from gcc?

[Christopher Faylor]

On Wed, Jan 31, 2007 at 02:52:42PM -, Dave Korn wrote:
>On 31 January 2007 13:49, Corinna Vinschen wrote:
>
>[yep, ntsec, haven't forgotten. sorry for slowness!]
>
>> On Jan 31 08:31, Christopher Faylor wrote:
>>> On Wed, Jan 31, 2007 at 02:27:00PM +0100, Samuel Thibault wrote:
 Eric Blake, le Wed 31 Jan 2007 06:18:22 -0700, a ?crit :
> I would much rather call the cross-compiler i686-mingw-gcc than the
> current name of 'gcc -mno-cygwin'.
 
 Same for me.
>>> 
>>> Thinking about this some more, it seems like we'd need a real
>>> cygwin-based mingw cross compiler rather than a wrapped mingw compiler
>>> since otherwise there would be path and signal issues.
>> 
>> While I agree with the general idea, I have to add the obligatory hint
>> that there are many projects out there which build environment requires
>> `gcc -mno-cygwin' to work.  All of them will break with at least 50% of
>> the lost user base asking on the Cygwin list for help.
>> 
>> So I'm wondering if we are not better off with sticking to the
>> `gcc -mno-cygwin' interface, regardless how this is implemented under
>> the hood.
>
>  My preference would be to keep it and fix the one-or-two minor bugs in the
>way it sets up the include/lib search paths.

I don't think they are really minor bugs but whatever bugs are there have
been around for many years now.  They would all magically go away if we
just split the package in two.

I feel pretty strongly about this.  I really don't think this option should
exist.  It's unlike every other gcc port on the planet.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Eliminating -mno-cygwin from gcc?

[Matt Wozniski]

On 1/31/07, Christopher Faylor wrote:

I feel pretty strongly about this.  I really don't think this option should
exist.  It's unlike every other gcc port on the planet.

cgf


Before simply ripping out support for it, how about just adding a
message to gcc so that when passed "-mnocygwin" on the commandline, it
warns that it's deprecated and will be removed in the near future,
before processing?  Or, better yet, for perhaps one major version,
have gcc warn that "-mnocygwin" is deprecated, and then just call
"execle" to run i686-mingw-gcc with the other arguments?  (Assuming
that the arguments would be compatible).  If cygwin's gcc has been
this nonstandard for so many years, what's another change to slowly
phase out this 'feature'?  While I agree that it wasn't a good feature
to add in the first place, I think that removing it without at least a
deprecation warning for a version or two will flood the mailing list
with traffic by people who didn't realize that something they used was
being phased out until they upgraded and things just "broke".

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Eliminating -mno-cygwin from gcc?

[Brian Ford]

On Wed, 31 Jan 2007, Christopher Faylor wrote:

> If we REALLY wanted to preserve -mno-cygwin, we could do so as a shell
> script wrapper for gcc but, personally, I think I'd rather just tell
> people to use the cross-compiler.

Why not just alias -mno-cygwin to -b i686-mingw?

-- 
Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Eliminating -mno-cygwin from gcc?

[Dave Korn]

On 31 January 2007 16:19, Brian Ford wrote:

> On Wed, 31 Jan 2007, Christopher Faylor wrote:
> 
>> If we REALLY wanted to preserve -mno-cygwin, we could do so as a shell
>> script wrapper for gcc but, personally, I think I'd rather just tell
>> people to use the cross-compiler.
> 
> Why not just alias -mno-cygwin to -b i686-mingw?


  Because it always works better to invoke the real driver than to try and
play -B/-V games  :)


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Eliminating -mno-cygwin from gcc?

[Brian Dessent]

Matt Wozniski wrote:

> phase out this 'feature'?  While I agree that it wasn't a good feature
> to add in the first place, I think that removing it without at least a
> deprecation warning for a version or two will flood the mailing list
> with traffic by people who didn't realize that something they used was
> being phased out until they upgraded and things just "broke".

The reason for removing it is because it causes a lot of confusion.  We
get endless messages to the cygwin list by people that misunderstand
what -mno-cygwin does.  They think it is some kind of magic pixie dust
that can make .exes that do no depend on cygwin1.dll while still using
POSIX features like sockets.  They may have no idea what MinGW even is,
and so when we tell them they are in fact using it and should ask on the
MinGW list, they get confused.  And the MinGW list is very reticent to
help when you mention that you're using Cygwin with gcc -mno-cygwin.  It
kind of puts you in a no-mans land.

I totally support the notion to remove this flag, provided that we also
include a genuine MinGW cross compiler in the distro.  And we can even
provide a wrapper script if necessary to map -mno-cygwin onto the
cross-gcc.

I tend to think though that perhaps this should be part of the 4.x
porting process, and that we should not even consider bothering to make
this change to the existing versions.  Since 4.x has a lot of changes
anyway, it would be the most appropriate time to introduce such a
change.

I suspect that when we do roll out 4.x it will have to be named in a way
that accomodates installing it in parallel to 3.4 (like we had with 2.95
and 3.3 for a while), since there are still lots of packages that choke
when compiled with 4.x.  This means there will be an additional safety
valve for the complainers in that they can just continue using 3.4 with
its existing support for -mno-cygwin.

Brian

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Eliminating -mno-cygwin from gcc?

[Matthew Woehlke]

Matt Wozniski wrote:

Before simply ripping out support for it, how about just adding a
message to gcc so that when passed "-mnocygwin" on the command line, it
warns that it's deprecated and will be removed in the near future,
before processing?


...and add a REALLY BIG MESSAGE that, if something breaks, the person to 
complain to is the package maintainer and not the Cygwin ML. :-)


Given that most idi^H^H^Haverage users don't know how to read, it 
probably won't help, but it gives us a Really Big Stick to smack them 
upside the head with if (when) they come whining here anyway.


--
Matthew
OFFICER throws a tear gas grenade at you. You start to feel nauseous. 
You need fresh air quickly.

> OPEN WINDOWS
Sorry, I have a philosophical objection to Microsoft products.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Eliminating -mno-cygwin from gcc?

[Christopher Faylor]

On Wed, Jan 31, 2007 at 10:29:01AM -0600, Matthew Woehlke wrote:
>Matt Wozniski wrote:
>>Before simply ripping out support for it, how about just adding a
>>message to gcc so that when passed "-mnocygwin" on the command line, it
>>warns that it's deprecated and will be removed in the near future,
>>before processing?
>
>...and add a REALLY BIG MESSAGE that, if something breaks, the person to 
>complain to is the package maintainer and not the Cygwin ML. :-)

No, if something breaks then the user has to fix it.

I don't mind adding a deprecated feature but I think some kind of
optional wrapper script eliminates the need.

And, I really think that we should consider adding some kind of way
to warn people about these issues in setup.exe.  I've always thought that
it should be somehow possible for packages to open dialog boxes.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Eliminating -mno-cygwin from gcc?

[Brian Ford]

On Wed, 31 Jan 2007, Dave Korn wrote:
> On 31 January 2007 16:19, Brian Ford wrote:
> > On Wed, 31 Jan 2007, Christopher Faylor wrote:
> >> If we REALLY wanted to preserve -mno-cygwin, we could do so as a shell
> >> script wrapper for gcc but, personally, I think I'd rather just tell
> >> people to use the cross-compiler.
> >
> > Why not just alias -mno-cygwin to -b i686-mingw?
>
>   Because it always works better to invoke the real driver than to try and
> play -B/-V games  :)

-V definately, but -b would seem much safer, no?

-- 
Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Eliminating -mno-cygwin from gcc?

[Matthew Woehlke]

Christopher Faylor wrote:

On Wed, Jan 31, 2007 at 10:29:01AM -0600, Matthew Woehlke wrote:

Matt Wozniski wrote:

Before simply ripping out support for it, how about just adding a
message to gcc so that when passed "-mnocygwin" on the command line, it
warns that it's deprecated and will be removed in the near future,
before processing?
...and add a REALLY BIG MESSAGE that, if something breaks, the person to 
complain to is the package maintainer and not the Cygwin ML. :-)


No, if something breaks then the user has to fix it.


I was responding to Corinna's comment "there are many projects out there 
which build environment requires `gcc -mno-cygwin' to work". Maybe these 
are all 'in-house' things? What I meant was to complain to the person 
who decided to use -mno-cygwin and not to us. :-)


Sorry if that wasn't clear.

--
Matthew
OFFICER throws a tear gas grenade at you. You start to feel nauseous. 
You need fresh air quickly.

> OPEN WINDOWS
Sorry, I have a philosophical objection to Microsoft products.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Perl bug?

[Yitzchak Scott-Thoennes]

> On Jan 28 11:57, Yitzchak Scott-Thoennes wrote:
>> Corinna Vinschen wrote:
>> > Thanks for the info.  It's interesting to know.  What I still don't
>> get,
>> > however, is the fact that the same statement does not waste memory on
>> > the x86 Linux Perl 5.8.5, but does on the x86 Cygwin Perl 5.8.7 and
>> the
>> > x86_64 Linux 5.8.8.  So it has been introduced only in later versions?
>> > And why is it defended?  It doesn't seem to make sense, rather on the
>> > contrary.
>>
>> This behaviour hasn't changed that I know of.  I verified that a 5.8.5
>> cygwin perl behaves the same way.  Could you confirm your x86 Linux
>> Perl 5.8.5 results again, and send me (privately if you wish) the
>> output of: perl -MConfig=config_sh -we'print config_sh' from that
>> perl?
>
> I just ran the testcase under strace on the Linux box again and to my
> surprise it behaved identical to the Cygwin and the 64 bit Linux
> version, as you say.  What have I done wrong in my first tests?  Was I
> hallucinating, caffein-induced maybe?

Perhaps your command history could tell you?

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Eliminating -mno-cygwin from gcc?

[Williams, Gerald S \(Jerry\)]

Christopher Faylor wrote:
> When I was maintaining cygwin's gcc, I often thought about eliminating
> -mno-cygwin and just providing a pure mingw cross compiler in the
> distribution.

I completely agree. Anybody depending on -mno-cygwin can create
their own shell wrapper. I personally don't care so much about a
deprecation period, as long as it explodes noisily and points me
in the right direction three years from now when I try to run an
old build script that happens to use it.

Big projects really shouldn't be using -mno-cygwin, anyway--the
preferred way to do it is to install MinGW compilers and either
use MSYS or change your Cygwin path to put MinGW's tools first.

How complete of a cross chain were you thinking about supporting?
I only installed the compilers and my MinGW bin contains over 60
unique executables--that could mean a fair number of i686-mingw-*
programs created (consider GNAT for example).

gsw

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Eliminating -mno-cygwin from gcc?

[Christopher Faylor]

On Wed, Jan 31, 2007 at 12:46:28PM -0500, Williams, Gerald S (Jerry) wrote:
>Christopher Faylor wrote:
>> When I was maintaining cygwin's gcc, I often thought about eliminating
>> -mno-cygwin and just providing a pure mingw cross compiler in the
>> distribution.
>
>I completely agree. Anybody depending on -mno-cygwin can create
>their own shell wrapper. I personally don't care so much about a
>deprecation period, as long as it explodes noisily and points me
>in the right direction three years from now when I try to run an
>old build script that happens to use it.
>
>Big projects really shouldn't be using -mno-cygwin, anyway--the
>preferred way to do it is to install MinGW compilers and either
>use MSYS or change your Cygwin path to put MinGW's tools first.
>
>How complete of a cross chain were you thinking about supporting?  I
>only installed the compilers and my MinGW bin contains over 60 unique
>executables--that could mean a fair number of i686-mingw-* programs
>created (consider GNAT for example).

I just thought that something which provides similar functionality to
what is available now would be required.  That means MinGW versions of
gcc and binutils.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Can't run man page.

[Kataria, Sunil]

When I run a man page, it reported 

Error executing formatting or display command.

System command (cd "/usr/share/man" && (echo ".ll 15.1i"; echo ".nr LL
15.1i"; echo ".pl 1100i"; /usr/bin/gunzip -c
'/usr/share/man/man1/cat.1.gz'; echo ".\\\""; echo ".pl \n(nlu+10") |
/usr/bin/tbl | /usr/bin/nroff -c -mandoc 2>/dev/null | /usr/bin/less
-isrR) exited with status 13568.

No manual entry for cat 

Could someone please help?

 

Thanks.

Sunil


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Eliminating -mno-cygwin from gcc?

[Chris Sutcliffe]

I just thought that something which provides similar functionality to
what is available now would be required.  That means MinGW versions of
gcc and binutils.


As long as I'm able to compile w32api and mingw-runtime for MinGW from
within Cygwin, I'll be a happy camper.

Chris

--
Chris Sutcliffe
http://ir0nh34d.googlepages.com
http://ir0nh34d.blogspot.com
http://emergedesktop.org

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Can't run man page.

[Larry Hall (Cygwin)]

Kataria, Sunil wrote:

When I run a man page, it reported 

Error executing formatting or display command.

System command (cd "/usr/share/man" && (echo ".ll 15.1i"; echo ".nr LL
15.1i"; echo ".pl 1100i"; /usr/bin/gunzip -c
'/usr/share/man/man1/cat.1.gz'; echo ".\\\""; echo ".pl \n(nlu+10") |
/usr/bin/tbl | /usr/bin/nroff -c -mandoc 2>/dev/null | /usr/bin/less
-isrR) exited with status 13568.

No manual entry for cat 


Could someone please help?


Possibly.  But please don't commandeer another thread for your own purposes.
If you want to start a new topic, send a new email message to the list.
Replying to another message and changing the subject attaches your message
to that thread rather than making it's own.  If you want help, please send
a *new* email message to the list with your request.  I recommend reading
and following the problem reporting guidelines as well.  They are 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?

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Eliminating -mno-cygwin from gcc?

[Eric Lilja]

Chris Sutcliffe wrote:

I just thought that something which provides similar functionality to
what is available now would be required.  That means MinGW versions of
gcc and binutils.


As long as I'm able to compile w32api and mingw-runtime for MinGW from
within Cygwin, I'll be a happy camper.

Chris



I agree with Chris. If removing -mno-cygwin solves a few problem I'm for 
it as long as I am to do what Chris mentions without having to install 
anything other than what's accessible from the cygwin setup. Changing 
some Makefiles is not an issue for me and if it solves some problems 
it's a good thing.


- Eric


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Can't run a man page.

[Kataria, Sunil]

Hi 

When I run a man page, it reported 

Error executing formatting or display command.
System command (cd "/usr/share/man" && (echo ".ll 15.1i"; echo ".nr LL
15.1i"; echo ".pl 1100i"; /usr/bin/gunzip -c
'/usr/share/man/man1/cat.1.gz'; echo ".\\\""; echo ".pl \n(nlu+10") |
/usr/bin/tbl | /usr/bin/nroff -c -mandoc 2>/dev/null | /usr/bin/less
-isrR) exited with status 13568.
No manual entry for cat 

Could someone please help?

Thanks.
Sunil


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: hang when using pthread and fork in 1.5.23-1 and snapshot 20070118, and now 1.5.24-1.

[Peter Rehley]

On Jan 31, 2007, at 6:46 AM, Brian Ford wrote:


On Fri, 26 Jan 2007, Peter Rehley wrote:


Hello,

I tried the latest release of cygwin1.dll (1.5.24-1) and it still is
hanging in the same way.  I've tried to debug further with gdb, but
so far I haven't got any useful information out of gdb.

I'll keep trying to get some debug information, but if any one else
can reproduce the problem I would be most appreciative.


I can reproduce a problem.  Your descriptions of it are a bit hard to
follow, so I'm not sure if it is your problem or not.   
Unfortunately, I
don't have time to debug it right now.  I do have a few comments,  
though.
hmmm, rereading those descriptions I see what you mean.  I'll try to  
clarify.
1) happens when the pthread_create fails.  Resources used up  
basically.  It's a normal error condition.


2) happens when the fork doesn't return.  The last message that is  
seen is "forking".  No messages following it are seen, and no  
messages from the main program are seen.


3) happens when the fork returns but has failed.  The last message  
that is seen is "done here" after the "Unable to fork".


   I've tracked what happens after the "done here" message and the  
thread is exiting.  So that would seem the hang is in the main program.




Why are you creating a thread just to fork/exec another process?
Our main application handles requests from a named socket.  Some of  
the requests call shell scripts.  Most of these shell scripts can  
send more requests to the application (I didn't write this, I just  
have to maintain it ).  So for those requests that call shell scripts  
the application has to create a thread and within the thread fork and  
then exec.


Pedantically, I believe you are supposed to call _exit, not exit,  
if fork

fails as stated here in the Solaris man page for fork:

 An applications should call _exit() rather than exit(3C)  if
 it  cannot execve(), since exit() will flush and close stan-
 dard I/O channels and thereby corrupt the  parent  process's
 standard I/O data structures. Using exit(3C) will flush buf-
 fered data twice. See exit(2).


This is good to know because the same application also runs on  
solaris.  Although, it seems to run fine there.


I don't know, however, if this is really true in Cygwin, but it might
explain some misdiagnosed hangs on your part.

Also, the execve call appears to be suspect.  Again, the Solaris  
man page

for execve states:

 The value in
 argv[0] should point to a filename that is  associated  with
 the process being started by one of the exec functions.
[snip]
 As indicated, argc is at least one and the
 first member of the array points to a string containing  the
 name of the file.

Attached is a modified test case that fixes a few of these issues, but
still hangs (or stutters; it does appear to proceed after long  
periods of

time).
I've modified my test case to make sure that execve has valid  
arguments, but I still get the hang.  FWIW, execve is being used  
because of the shell scripts being called.


Peter

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Eliminating -mno-cygwin from gcc?

[Igor Peshansky]

On Wed, 31 Jan 2007, Christopher Faylor wrote:

> On Wed, Jan 31, 2007 at 10:29:01AM -0600, Matthew Woehlke wrote:
> >Matt Wozniski wrote:
> >>Before simply ripping out support for it, how about just adding a
> >>message to gcc so that when passed "-mnocygwin" on the command line, it
> >>warns that it's deprecated and will be removed in the near future,
> >>before processing?
> >
> >...and add a REALLY BIG MESSAGE that, if something breaks, the person to
> >complain to is the package maintainer and not the Cygwin ML. :-)
>
> No, if something breaks then the user has to fix it.
>
> I don't mind adding a deprecated feature but I think some kind of
> optional wrapper script eliminates the need.

I agree, except that some people invoke Cygwin's gcc from non-Cygwin
programs, which would present a problem if it were a shell script.
Perhaps we should add some option preprocessing to the gcc executable
itself (which would exec the cross-gcc if -mno-cygwin is present)?

> And, I really think that we should consider adding some kind of way
> to warn people about these issues in setup.exe.  I've always thought that
> it should be somehow possible for packages to open dialog boxes.

FWIW, I've been toying with the idea of setup keeping an open pipe that
postinstall scripts could write to, so that any messages coming via that
pipe are displayed as dialog boxes...  It probably won't help in this
particular case, since you'd want to see this information *before*
installing the package.

Another thing that I was thinking of doing was some way of displaying the
release notes (or at least the announcement message) for the selected
package.  However, that will require either reworking the chooser or
adding the popup menu functionality to it, as well as some system on
sourceware to keep track of the announcement messages (also proposed but
never implemented).  Anyone want to take a shot at the popup menu
implementation in the chooser?

The followups to the last couple of paragraphs probably belong on
cygwin-apps...
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Freedom is just another word for "nothing left to lose"...  -- Janis Joplin

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Support planned for vista symbolic links?

[Shankar Unni]

Corinna Vinschen wrote:


[..] The next major Cygwin release will be able to read
native NTFS symlinks and treats them as symlinks.  However, it's not
planned to utilize native NTFS symlinks when creating symlinks in Cygwin.


Actually, that sounds perfect. The main thing is to recognize them as 
symlinks. Thanks!



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Eliminating -mno-cygwin from gcc?

[Charles Wilson]

[I haven't read the whole thread yet, so I reserve the right to revise 
and extend.  Also, to say something somebody else already did, or 
otherwise generally make an idiot of myself]


Christopher Faylor wrote:

How about if we eliminate -mno-cygwin from future releases and either
provide our own mingw cross-tools or wrap the offerings from mingw.org?
This would mean that instead of saying 'gcc -mno-cygwin', you'd say:
'i686-mingw-gcc' which would, I know, make a few computers spontaneously
self-destruct however, I really don't think that the -mno-cygwin belongs
in gcc.  No other port of gcc has anything like this.


I agree in principle -- and would prefer a cygwin-hosted cross-compiler, 
rather than using the mingw offerings, for two reasons which I will get 
to later.


But first, the most important question: what is Dave Korn's opinion?  As 
the current GCC maintainer for cygwin, a change like this would fall 
most heavily on him [*] The number of packages Dave releases wouldn't 
change, but there will be inevitable ripples that he'd have to deal with.


[*] And on the maintainers of the binutils package (cgf? Corinna?), the 
mingw-runtime package, the w32api package, and the 
mingw-zlib,mingw-bzip2 packages. (The last two are mine, and are 
no-brainers. But the other three will also get some ripple from this 
proposal)


My reasons for preferring a cygwinH-mingwT cross compiler:

[1] the mingw offerings are not always in sync with cygwin version-wise. 
 Presently they are on:

Current=3.4.2,
Prev=3.2.3, 3.3.1, 2.95.3
Candidate=3.4.5
Proposed=3.4.5+DW2
and not all have the same set of frontends. Which one would we provide 
(and note that 3.4.4 -- our current cygwin gcc version -- is not one of 
the choices)?


[2] The MinGW gcc does not understand unix paths, only dos paths. This 
will lead to unexpected un-cygwin-ness when using the compiler, 
expecially when running configure scripts, etc.


MinGW works around this with their MSYS fork of cygwin, which 
auto-converts stuff on the command line to/from dos format when the 
target program is non-MSYS-linked (but then there are those corner 
cases: Win32-style options (/Fo:bob), cmdline args with embedded paths 
(-I/usr/mingw), etc.


I don't think we want to imitate that in cygwin.  But it's still better 
if we can pass unix-style paths to the "-mno-cygwin" compiler.  This 
argues for a cygwin-hosted true cross compiler, rather than using the 
native-win32-hosted version from MinGW.


But let me re-iterate: the opinion of Dave and those other maintainers 
are the controlling one, IMO. (Oh, and does Dave build existing gcc 
releases natively, or on linux?  If the latter, then the mingw compiler 
will be a three-way: linuxB-cygwinH-mingwT...)


--
Chuck

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Can't run a man page.

[Kataria, Sunil]

I found that less was not working...and got it fixed (copied "less" from
old binaries)

However still not been able to see the man pages.

When I run the man page it shows some empty lines and that's it.

Does someone know about this issue and the fix?

Regards,
Sunil



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Kataria, Sunil
Sent: Thursday, 1 February 2007 8:04 AM
To: cygwin@cygwin.com
Subject: Can't run a man page.

Hi 

When I run a man page, it reported 

Error executing formatting or display command.
System command (cd "/usr/share/man" && (echo ".ll 15.1i"; echo ".nr LL
15.1i"; echo ".pl 1100i"; /usr/bin/gunzip -c
'/usr/share/man/man1/cat.1.gz'; echo ".\\\""; echo ".pl \n(nlu+10") |
/usr/bin/tbl | /usr/bin/nroff -c -mandoc 2>/dev/null | /usr/bin/less
-isrR) exited with status 13568.
No manual entry for cat 

Could someone please help?

Thanks.
Sunil


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Can't run a man page.

[Larry Hall (Cygwin)]

Kataria, Sunil wrote:

I found that less was not working...and got it fixed (copied "less" from
old binaries)

However still not been able to see the man pages.

When I run the man page it shows some empty lines and that's it.

Does someone know about this issue and the fix?

Regards,
Sunil



-Original Message-
From: Kataria, Sunil
Sent: Thursday, 1 February 2007 8:04 AM
To: cygwin  cygwin  com

  



Subject: Can't run a man page.

Hi 


When I run a man page, it reported 

Error executing formatting or display command.
System command (cd "/usr/share/man" && (echo ".ll 15.1i"; echo ".nr LL
15.1i"; echo ".pl 1100i"; /usr/bin/gunzip -c
'/usr/share/man/man1/cat.1.gz'; echo ".\\\""; echo ".pl \n(nlu+10") |
/usr/bin/tbl | /usr/bin/nroff -c -mandoc 2>/dev/null | /usr/bin/less
-isrR) exited with status 13568.
No manual entry for cat 


Could someone please help?


WAG:
?

There are some other hits the in the archives that would constitute other
WAGs.

Don't want a WAG?  Then let's start 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?

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Eliminating -mno-cygwin from gcc?

[Danny Smith]

cgf wrote
> 
> How about if we eliminate -mno-cygwin from future releases and either
> provide our own mingw cross-tools or wrap the offerings from 
> mingw.org?


I would miss -mno-cygwin.  Gcc -mno-cygwin suppports symlinks, mingw
doesn't.

--host=i686-pc-cygwin --target=i686-pc-cygwin would be a lovely
replacement,
 so I wouldn't miss it for long. 

Danny


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

bad md5 of setup.exe on mirrors.kernel.org

[Alexander Sotirov]

The MD5 hash of setup.exe on mirrors.kernel.org does not match the hash on
ftp.cygwin.com.

$ wget ftp://ftp.cygwin.com/pub/cygwin/setup.exe
$ md5sum.exe setup.exe
b31ddcef84f25919a5d3184167b4a90d *setup.exe

$ wget http://mirrors.kernel.org/sourceware/cygwin/setup.exe
$ md5sum.exe setup.exe
fbc848393ed05ef4f51a253f75bcafeb *setup.exe

The MD5 hash in md5.sum on both servers is the same.

$ grep setup.exe md5.sum
b31ddcef84f25919a5d3184167b4a90d  setup.exe

There is only byte that's different between the two binaries, and it's at offset
0x1F4 in the file:

from ftp.cygwin.com:
01F0   32 2E 30 33  00 55 50 58  21 0D 09 08  07 CF A8 F5  2.03.UPX!...

from mirrors.kernel.org:
01F0   32 2E 30 32  00 55 50 58  21 0D 09 08  07 CF A8 F5  2.02.UPX!...

This looks like a version string of the UPX packer used to produce the 
executable.

It looks like this is a result of some kind of error and not a malicious
tampering, but it's worrisome that the mirrors have gotten out of sync and
nobody noticed.

By the way, MD5 is broken, you should switch to SHA1 or GPG signatures.
http://www.mathstat.dal.ca/~selinger/md5collision/

Alex

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/