Re: vim-minimal annoyance

[Csaba Raduly]

On Tue, Jun 18, 2013 at 2:54 AM, Shaun Fielder  wrote:
>> As Larry stated, the latest release of vim-minimal uses virc instead of
> vimrc (as done on Fedora), so this should no longer be an issue.
>
> Sure, now if I upgrade an existing installation and then type 'vi' - I won't
> see any errors. Great.
> However, I'll be left wondering why it isn't working like I'd normally
> expect. This is more subtle and arguably worse.
>
> If I have the full-featured vim installed, then I expect vi ==
> full_featured_vim. This is how it has always been.
>
> I guess I'll just have to resign myself to creating an alias (vi=vim) on
> every install...

Maybe there should be a "vi-as-vim" package which contains nothing but
the vi->vim symlink.

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

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

Re: git svn fork() problems on cygwin 1.7.20

[Mikko Rapeli]

(sorry, not subscribed so reply might be a bit off)

I found only one cygwin1.dll on the system. Did a rebaseall but problem stays.
Problem reproduces also when PATH=/bin so I guess this is
something else. bash, git etc binaries work well and only git svn
has this issue.

Cygwin Configuration Diagnostics
Current System Time: Tue Jun 18 08:56:16 2013

Windows 7 Enterprise Ver 6.1 Build 7601 Service Pack 1

Running under WOW64 on AMD64

Path:   C:\Apps\cygwin\bin
C:\Apps\cygwin\sbin
C:\Apps\cygwin\bin
C:\Apps\cygwin\usr\sbin
C:\Testwell\CTC
C:\Apps\ARM\bin\win_32-pentium
C:\Oracle\Client64\bin
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0
C:\Program Files (x86)\Microsoft Application Virtualization Client
C:\Apps\cygwin\bin
C:\Apps\ARM\RVD\Core\4.1.1\25\win_32-pentium\bin
C:\Apps\ARM\Utilities\FLEXlm\10.8.5.0\1\win_32-pentium
C:\Apps\ARM\RVCT\Programs\4.1\561\win_32-pentium
C:\Apps\ARM\RVI\Tools\4.1\32\programs\win_32-pentium
C:\Program Files\TortoiseSVN\bin
C:\Program Files (x86)\Subversion\bin
C:\Apps\apache-ant\bin
C:\Apps\Python27
C:\Program Files (x86)\CMake 2.8\bin

Output from C:\Apps\cygwin\bin\id.exe
UID: 805092(user2) GID: 10513(Domain Users)
10513(Domain Users)  0(root)  544(Administrators)
545(Users)

SysDir: C:\Windows\system32
WinDir: C:\Windows

PWD = '/cygdrive/c/Development/jenkins-slave/workspace/git_test/tools'
HOME = '/home/user2'

HOMEPATH = '\'
APPDATA = 'C:\Users\user2\AppData\Roaming'
ProgramW6432 = 'C:\Program Files'
ARMCC41LIB = 'C:\Apps\ARM\RVCT\Data\4.1\561\lib'
ARM_ENABLED_PRODUCTS = 
'C:\Apps\ARM|RVDS/Contents/4.1/158:platform=win_32-pentium,encryption=none,extras_dir=professional\,regime=rel,capability=professional'
ARMCC41BIN = 'C:\Apps\ARM\RVCT\Programs\4.1\561\win_32-pentium'
TERM = 'cygwin'
PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 26 Stepping 5, GenuineIntel'
WINDIR = 'C:\Windows'
PUBLIC = 'C:\Users\Public'
ISSM_ARM_CORTEXDLL = 'C:\Apps\ARM\ISSModel\Cortex\4.0\18\win_32-pentium'
USERDOMAIN = 'local'
CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\ProgramData'
windows_tracing_flags = '3'
ARMCONF = 
'C:\Apps\ARM\RDI\armperip\1.3\50;C:\Apps\ARM\RVARMulator\ARMulator\1.4.1\313\win_32-pentium;C:\Apps\ARM\RVARMulator\MPCore\ARMulator\1.4.1\20\rvds30\win_32-pentium;C:\Apps\ARM\RVARMulator\v6ARMulator\1.4.1\285\win_32-pentium'
windows_tracing_logfile = 'C:\BVTBin\Tests\installpackage\csilogfile.log'
VBOX_INSTALL_PATH = 'C:\Program Files\Oracle\VirtualBox\'
TEMP = '/cygdrive/c/Users/user2/AppData/Local/Temp'
OSVersion = 'Windows 7 Enterprise (x64)'
COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files'
RVDEBUG_SDK = 'C:\Apps\ARM\RVD\Core\4.1.1\25\win_32-pentium\sdk'
MasterImageVer = 'x64-5.12'
USERNAME = 'user2'
ARMLMD_LICENSE_FILE = 'licenses.local'
PROCESSOR_LEVEL = '6'
ProgramFiles(x86) = 'C:\Program Files (x86)'
PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
RVD_FLASH_BASE = 'C:\Apps\ARM\RVD\Flash\4.0\18\all\flash'
PROCESSOR_ARCHITEW6432 = 'AMD64'
HLPPATH = 'C:\Apps\ARM\Documentation\RVD\4.1\11\onlinehelp'
USERPROFILE = 'C:\Users\user2'
ARMCC41INC = 'C:\Apps\ARM\RVCT\Data\4.1\561\include\windows'
SLAVENAME = 'windows'
LOGONSERVER = '\\LOCAL'
CTCHOME = 'C:\Testwell\CTC'
CommonProgramW6432 = 'C:\Program Files\Common Files'
PROCESSOR_ARCHITECTURE = 'x86'
LOCALAPPDATA = 'C:\Users\user2\AppData\Local'
!C: = 'C:\Development\jenkins-slave\workspace\git_test\tools'
ProgramData = 'C:\ProgramData'
SHLVL = '1'
USERDNSDOMAIN = 'FOO.BAR.CORP'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC'
ARMDLL = 
'C:\Apps\ARM\RVARMulator\ARMulator\1.4.1\313\win_32-pentium;C:\Apps\ARM\RDI\rdimsvr\1.3.1\129\win_32-pentium;C:\Apps\ARM\RVARMulator\MPCore\ARMulator\1.4.1\20\rvds30\win_32-pentium;C:\Apps\ARM\RVARMulator\v6ARMulator\1.4.1\285\win_32-pentium'
HOMEDRIVE = 'U:'
PROMPT = '$P$G'
COMSPEC = 'C:\Windows\system32\cmd.exe'
BR-UPS_is-active-since = '17.06.2013 08:22:08'
TMP = '/cygdrive/c/Users/user2/AppData/Local/Temp'
SYSTEMROOT = 'C:\Windows'
PROCESSOR_REVISION = '1a05'
VS100COMNTOOLS = 'C:\Program Files (x86)\Microsoft Visual Studio 
10.0\Common7\Tools\'
ARM_PROFILER_RTSM_PATH = 
'C:\Apps\ARM\RVDS\Models\5.2\16\lib\Win32_VC2005\Release'
RVDEBUG_INSTALL = 'C:\Apps\ARM\RVD\Core\4.1.1\25\win_32-pentium'
RVDEBUG_HLPPATH = 'C:\Apps\ARM\Documentation\RVD\4.1\11\onlinehelp'
PROGRAMFILES = 'C:\Program Files (x86)'
ARMROOT = 'C:\Apps\ARM'
NUMBER_OF_PROCESSORS = '4'
ARM_RTSM_PATH = 'C:\Apps\ARM\RVDS\Models\5.2\16\lib\Win32_VC2005\Release'
FM_TRACE_PLUGINS = 
'C:\Apps\ARM\RVDS\ProfilerPlugIn\2.1\3\plugins\Win32_VC2005\FMProfilerPlugin.dll'
SESSIONNAME = 'Console'
COMPUTERNAME = 'WINDOWS'
ARM_RVI_TOOLS = 'C:\Apps\ARM\RVI\Tools\4

Re: What is a good profiling tool ? - problem with gprof

[Corinna Vinschen]

On Jun 17 12:52, Larry Hall (Cygwin) wrote:
> On 6/17/2013 12:19 PM, J.B.W.Webber wrote:
> >Hi, I am trying to find in which function call the most time is being spent.
> >
> >I am using gcc and trying to compile and link with -g and -pg.
> >i.e. for a trivial test :
> >
> >$ cat helloworld.c
> >/* Hello World program */
> >#include
> >main()
> >{
> > printf("Hello World\n");
> >}
> >
> >$ gcc -g -pg -c helloworld.c
> >$ gcc -pg helloworld.o
> >helloworld.o: In function `main':
> >helloworld.c:6: undefined reference to `_mcount'
> >collect2: ld returned 1 exit status
> >
> >Any ideas ? Am I missing a .h call ? Or do I need to link to something ?
> 
> Worked for me.  Perhaps your Strawberry gcc installation is interfering.

I don't know how you succeeed to build that, Larry.  I could easily
reproduce the problem.  It was a build problem in Cygwin.  I fixed that
now and at the same time made the 64 bit profiling workable, curtesy the
Mingw-w64 project, which already did the required work.  The original
profiling code was created within the Cygwin project ages ago, so I
could included the latest Mingw-w64 profiling code (almost) verbatim
into Cygwin and now it seems to work fine again for 32 and 64 bit.

I'm just about to create a 2013-06-18 32 bit snapshot on
http://cygwin.com/snapshots/ and a 64 bit test release 1.7.12-5,
which both should be ready in an hour.


HTH,
Corinna

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

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

Re: Cross-compiling Linux kernel

[Corinna Vinschen]

On Jun 18 10:56, Fedin Pavel wrote:
> [...]
>  P.S. I have got even more crazy idea, perhaps deserving a separate topic...
> BSD systems have Linux binary compatibility layer. Could we have one ?
> Technically this depends on ability to construct process image manually in
> Windows (*). Is it possible (using NT API of course) ? And, of course,
> someone needs lots of spare time to code this. :) OTOH, CoLinux already does
> this (yep, they are not 64-bit for now...), so perhaps there's no need to
> duplicate the job done.

Not in the Cygwin DLL.  As an extra DLL layer I don't have a problem
with that.

>  P.P.S. Perhaps the answer to (*) is NO, otherwise we would have fast
> fork()...

That's not quite correct.  The problem is not utilizing the native NT
functions to create a process image, the problem is that the Win32
libraries like advapi32, msvcrt, etc, which are directly or indirectly
loaded into a Cygwin process, are not capable to deal with a process
clone situation.  They were never designed this way and there's not much
chance they will ever get a revamp, just to allow Cygwin to create a
fast fork.


Corinna

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

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

Re: UNC and POSIX paths

[Corinna Vinschen]

On Jun 17 22:47, g...@malth.us wrote:
> On Mon, 17 Jun 2013, at 21:42, Christopher Faylor thusly quipped:
> 
> > On Mon, Jun 17, 2013 at 07:18:12PM -0700, g...@malth.us wrote:
> >> BTW, along the same lines, I stated previously it would break
> >> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=m4/doub
> >> le-sl ash-root.m4.  Turns out I was wrong, the m4 has a hard-coded list
> >> of platforms.  So, I have to say, I can't think of one technical or
> >> merit-based reason this shouldn't be done, aside from the fact that
> >> it's annoying to hear it endlessly brought up on the mailing list (a
> >> problem which an implementation would, in fact, solve, not exacerbate).
> > 
> > I can't quite follow the logic here but if you're saying that if we no
> longer
> > treated // as /, people who want to use //usr/local/bin would not
> complain,
> > you're right.  That doesn't mean that a whole new class of complainer
> would not
> > show up, however.
> > 
> > I can say with absolute certainty that there is one person who would
> complain.
> 
> I was imagining a less intrusive hypothetical approach.
> 
> For example, perhaps a CYGWIN=nounc flag that would simply turn the feature
> off, or a way to deactivate in fstab -- in short, anything reversible, and,
> by default, preserving the existing behavior.  Prune-grafting "//" to "/smb"
> might have been a good idea had it been done at cygwin's inception, but I
> think it's probably too late now.

A mount table approach along the lines of the cygdrive prefix handling
might not be such a bad thing, after all.  Something along these lines

  none /mnt cygdrive binary,posix=0,user 0 0
  none /unc uncdrive binary,posix=0 0 0

This would also fix the somewhat special feature that unc paths get the
same default flag treatment as cygdrive paths.


Corinna

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

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

[ANNOUNCEMENT] Updated: hexedit-1.2.13-1

[Chris Sutcliffe]

A new release of hexedit, 1.2.13-1, is now available.

hexedit  shows a file both in ASCII and in hexadecimal. The file can be a
device as the file is read a piece at a time. You can modify the file and
search through it.

For a list of changes see below.

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 at: cygwincygwin.com .

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

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

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

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

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

february 2013:
- fix displaying sector number when above 2^31
- fix potential file descriptor leak (thanks to Rich Burridge)
- add DESTDIR support to the makefiles
- preprocessor flags should use CPPFLAGS, not CFLAGS
- fix a small issue in mymemmem/mymemrmem when HAVE_MEMMEM/HAVE_MEMRMEM is not
defined


--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

--
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: What is a good profiling tool ? - problem with gprof

[Corinna Vinschen]

On Jun 18 12:11, Corinna Vinschen wrote:
> On Jun 17 12:52, Larry Hall (Cygwin) wrote:
> > On 6/17/2013 12:19 PM, J.B.W.Webber wrote:
> > >Hi, I am trying to find in which function call the most time is being 
> > >spent.
> > >
> > >I am using gcc and trying to compile and link with -g and -pg.
> > >i.e. for a trivial test :
> > >
> > >$ cat helloworld.c
> > >/* Hello World program */
> > >#include
> > >main()
> > >{
> > > printf("Hello World\n");
> > >}
> > >
> > >$ gcc -g -pg -c helloworld.c
> > >$ gcc -pg helloworld.o
> > >helloworld.o: In function `main':
> > >helloworld.c:6: undefined reference to `_mcount'
> > >collect2: ld returned 1 exit status
> > >
> > >Any ideas ? Am I missing a .h call ? Or do I need to link to something ?
> > 
> > Worked for me.  Perhaps your Strawberry gcc installation is interfering.
> 
> I don't know how you succeeed to build that, Larry.  I could easily
> reproduce the problem.  It was a build problem in Cygwin.  I fixed that
> now and at the same time made the 64 bit profiling workable, curtesy the
> Mingw-w64 project, which already did the required work.  The original
> profiling code was created within the Cygwin project ages ago, so I
> could included the latest Mingw-w64 profiling code (almost) verbatim
> into Cygwin and now it seems to work fine again for 32 and 64 bit.
> 
> I'm just about to create a 2013-06-18 32 bit snapshot on
> http://cygwin.com/snapshots/ and a 64 bit test release 1.7.12-5,
> which both should be ready in an hour.

Uploaded.  Please note that it's *not* enough to install the snapshot
Cygwin DLL.  The important items here are gcrt0.o and libgmon.a.


Corinna

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

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

RE: Cross-compiling Linux kernel

[Fedin Pavel]

 Hello!

> >  P.P.S. Perhaps the answer to (*) is NO, otherwise we would have fast
> > fork()...
> 
> That's not quite correct.  The problem is not utilizing the native NT
> functions to create a process image,

 Wow, interesting...
 I wonder if i could get a ELF with some plain hardcoded Windows syscall (an 
equivalent of OutputDebugString("Hello ELF world!");) running, just as a proof 
of concept.
 However, perhaps fully functional 32->64 bit bridges in /lib32 (or /bin32 ?) 
would be more useful for start. There is some prebuilt Cygwin software around, 
which is of course 32 bit and closed source (Perforce client is an example).

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia



--
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: vim-minimal annoyance

[Frank Fesevur]

2013/6/18 Csaba Raduly:
>> If I have the full-featured vim installed, then I expect vi ==
>> full_featured_vim. This is how it has always been.
>>
>> I guess I'll just have to resign myself to creating an alias (vi=vim) on
>> every install...
>
> Maybe there should be a "vi-as-vim" package which contains nothing but
> the vi->vim symlink.

IMHO the real solution would be using alternatives again. I still
don't get why Yaakov stopped using it when it was really needed.

Regards,
Frank

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

RE: Cross-compiling Linux kernel

[Fedin Pavel]

 Hello!

 While waiting for the Big Thing to finish compiling, another crazy idea 
visited my damaged brain. ;-) I wonder if it has some practical value...

> That's not quite correct.  The problem is not utilizing the native NT
> functions to create a process image, the problem is that the Win32
> libraries like advapi32, msvcrt, etc, which are directly or indirectly
> loaded into a Cygwin process, are not capable to deal with a process
> clone situation.

 So, in another words, we can clone everything except several known libraries. 
What if we use this fact ?
 Since we can create process image manually, what if we clone everything except 
these libraries ? Then we do a thing similar to what we do now, we start the 
program from the beginning but tell it to follow "short path", attach missing 
libraries and jump to our fork().
 Potential advantages:
 1. clone'able DLLs (i assume that all Cygwin DLLs are cloneable) are 
guaranteed to get the same addresses.
 2. (1) creates smaller number of variants for Windows native libraries, so we 
have smaller chances to get different addresses for them.

 Even more, what stops us from completely manual process image layout ? This 
way we could guarantee the same addresses for all libraries.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia



--
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: Cross-compiling Linux kernel

[Corinna Vinschen]

On Jun 18 16:06, Fedin Pavel wrote:
>  Hello!
> 
>  While waiting for the Big Thing to finish compiling, another crazy idea 
> visited my damaged brain. ;-) I wonder if it has some practical value...
> 
> > That's not quite correct.  The problem is not utilizing the native NT
> > functions to create a process image, the problem is that the Win32
> > libraries like advapi32, msvcrt, etc, which are directly or indirectly
> > loaded into a Cygwin process, are not capable to deal with a process
> > clone situation.
> 
>  So, in another words, we can clone everything except several known
>  libraries. What if we use this fact ?
>  Since we can create process image manually, what if we clone
>  everything except these libraries ? Then we do a thing similar to

How would you do that?  Either you use the native call to clone the
processes address space or you don't.  If you clone, you get the
entire address space layout, including all DLL images and heaps
reserved by OS DLLs.  These memory regions have to be free'd to be
able to reload the OS DLLs.  How do you know which memory region
has been reserved by which OS DLL?  Good luck implementing ;)

Btw., for reference:
http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/afdf1b68-1f3e-47f5-94cf-51e397afe073

>  what we do now, we start the program from the beginning but tell it
>  to follow "short path", attach missing libraries and jump to our
>  fork().
>  Potential advantages:
>  1. clone'able DLLs (i assume that all Cygwin DLLs are cloneable) are
>  guaranteed to get the same addresses.
>  2. (1) creates smaller number of variants for Windows native
>  libraries, so we have smaller chances to get different addresses for
>  them.
> 
>  Even more, what stops us from completely manual process image layout
>  ? This way we could guarantee the same addresses for all libraries.

If you can get this working...


Corinna

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

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

Updating Git

[Adam Dinwoodie]

Would it be possible for the Git maintainer to update Git to a more recent
version than 1.7.9, which was released almost 18 months ago?  Git is now on
v1.8.3.1.

Alternatively, I'd be willing to take over the maintainership, although there
may be initial teething difficulties as I've only just managed to get Git
building on my machine, still see it failing some test cases, and have not
maintained a Cygwin package previously.

-- 
Adam Dinwoodie

Messages posted to this list are made in a personal capacity.

--
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: What is a good profiling tool ? - problem with gprof

[J . B . W . Webber]

-Original Message-
Subject: Re: What is a good profiling tool ? - problem with gprof

On Jun 18 12:11, Corinna Vinschen wrote:
> On Jun 17 12:52, Larry Hall (Cygwin) wrote:
> > On 6/17/2013 12:19 PM, J.B.W.Webber wrote:
> > >Hi, I am trying to find in which function call the most time is being 
> > >spent.
> > >
> > >I am using gcc and trying to compile and link with -g and -pg.
> > >i.e. for a trivial test :
> > >
> > >$ cat helloworld.c
> > >/* Hello World program */
> > >#include
> > >main()
> > >{
> > > printf("Hello World\n");
> > >}
> > >
> > >$ gcc -g -pg -c helloworld.c
> > >$ gcc -pg helloworld.o
> > >helloworld.o: In function `main':
> > >helloworld.c:6: undefined reference to `_mcount'
> > >collect2: ld returned 1 exit status
> > >
> > >Any ideas ? Am I missing a .h call ? Or do I need to link to something ?
> > 
> > Worked for me.  Perhaps your Strawberry gcc installation is interfering.
> 
> I don't know how you succeeed to build that, Larry.  I could easily 
> reproduce the problem.  It was a build problem in Cygwin.  I fixed 
> that now and at the same time made the 64 bit profiling workable, 
> curtesy the
> Mingw-w64 project, which already did the required work.  The original 
> profiling code was created within the Cygwin project ages ago, so I 
> could included the latest Mingw-w64 profiling code (almost) verbatim 
> into Cygwin and now it seems to work fine again for 32 and 64 bit.
> 
> I'm just about to create a 2013-06-18 32 bit snapshot on 
> http://cygwin.com/snapshots/ and a 64 bit test release 1.7.12-5, which 
> both should be ready in an hour.

Uploaded.  Please note that it's *not* enough to install the snapshot Cygwin 
DLL.  The important items here are gcrt0.o and libgmon.a.


Corinna

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

_

Really thanks to all. That now works.

Sorry for the slow reply, I did the install with the snapshot as suggested 
- no difference, at first, but I had been given the clues I needed.

I used find to track all libgmon.a  on my laptop :

C:/Altera/12.0sp2/quartus/bin/cygwin/lib/libgmon.a
C:/Altera/12.0sp2/quartus/bin/cygwin/lib/mingw/libgmon.a
C:/Altera/12.0sp2/quartus/bin/cygwin/usr/i686-pc-mingw32/lib/libgmon.a
C:/Applications/Strawberry/c/x86_64-w64-mingw32/lib/libgmon.a
C:/cygwin/lib/libgmon.a
C:/cygwin/usr/i686-pc-mingw32/sys-root/mingw/lib/libgmon.a
C:/cygwin/usr/lib/libgmon.a

I blocked access to the Altera and Strawberry Cygwins, which made no 
difference, (no, XMOS does not use Cygwin)
But the answer was the version C:/cygwin/lib/libgmon.a
I copied the new gcrt0.o and libgmon.a into C:/cygwin/lib/
and all now works fine. I have the answer I needed.

I do thank you all,
Cheers,
Beau 
 
 

Error: console device allocation failure - too many consoles in use, max consoles is 32

[Comerma Pare, Antoni]

Hi,

We are experiencing an strange problem using cygwin in Windows 2008R2. =
We are unable to open more than 32 bash windows.

When we try, we receive the following message

C:\cygwin>Cygwin.bat

0 [main] bash 8968 C:\cygwin\bin\bash.exe: *** fatal error - = console
device allocation failure - too many consoles in use, max = consoles is
32=20

This doesn't happen to other systems also using W2008R2, which are using
= older versions of cygwin (1.7.15) but I cannot find the difference.
The = troubling ones are using

C:\cygwin\bin>uname -a

CYGWIN_NT-6.1-WOW64 SYSTEM_NAME 1.7.17(0.262/5/3) 2012-10-19 14:39 i686
= Cygwin=20 =20 I've looked around using google, but the only reference
to this message = appears in the cygwin source code.

Can someone give me clue?

Thanks,

Toni

Toni Comerma

SECA Infraestructures

--
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: UNC and POSIX paths

[Christopher Faylor]

On Tue, Jun 18, 2013 at 12:26:32PM +0200, Corinna Vinschen wrote:
>On Jun 17 22:47, g...@malth.us wrote:
>> On Mon, 17 Jun 2013, at 21:42, Christopher Faylor thusly quipped:
>> 
>> > On Mon, Jun 17, 2013 at 07:18:12PM -0700, g...@malth.us wrote:
>> >> BTW, along the same lines, I stated previously it would break
>> >> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=m4/doub
>> >> le-sl ash-root.m4.  Turns out I was wrong, the m4 has a hard-coded list
>> >> of platforms.  So, I have to say, I can't think of one technical or
>> >> merit-based reason this shouldn't be done, aside from the fact that
>> >> it's annoying to hear it endlessly brought up on the mailing list (a
>> >> problem which an implementation would, in fact, solve, not exacerbate).
>> > 
>> > I can't quite follow the logic here but if you're saying that if we no
>> longer
>> > treated // as /, people who want to use //usr/local/bin would not
>> complain,
>> > you're right.  That doesn't mean that a whole new class of complainer
>> would not
>> > show up, however.
>> > 
>> > I can say with absolute certainty that there is one person who would
>> complain.
>> 
>> I was imagining a less intrusive hypothetical approach.
>> 
>> For example, perhaps a CYGWIN=nounc flag that would simply turn the feature
>> off, or a way to deactivate in fstab -- in short, anything reversible, and,
>> by default, preserving the existing behavior.  Prune-grafting "//" to "/smb"
>> might have been a good idea had it been done at cygwin's inception, but I
>> think it's probably too late now.
>
>A mount table approach along the lines of the cygdrive prefix handling
>might not be such a bad thing, after all.  Something along these lines
>
>  none /mnt cygdrive binary,posix=0,user 0 0
>  none /unc uncdrive binary,posix=0 0 0
>
>This would also fix the somewhat special feature that unc paths get the
>same default flag treatment as cygdrive paths.

That's what I was proposing earlier in the thread.  It's a SHTDI
proposal, of course.

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: Cross-compiling Linux kernel

[Christopher Faylor]

On Tue, Jun 18, 2013 at 12:17:06PM +0200, Corinna Vinschen wrote:
>On Jun 18 10:56, Fedin Pavel wrote:
>> [...]
>>  P.S. I have got even more crazy idea, perhaps deserving a separate topic...
>> BSD systems have Linux binary compatibility layer. Could we have one ?
>> Technically this depends on ability to construct process image manually in
>> Windows (*). Is it possible (using NT API of course) ? And, of course,
>> someone needs lots of spare time to code this. :) OTOH, CoLinux already does
>> this (yep, they are not 64-bit for now...), so perhaps there's no need to
>> duplicate the job done.
>
>Not in the Cygwin DLL.  As an extra DLL layer I don't have a problem
>with that.

There was a project out there many years ago which did this.  You could
run simple linux binaries on Windows.  I offered to host the development
on sourceware.org (aka cygwin.com) but, IIRC, the developer never
responded.

I don't remember what the name of the project was and I'm sure that it
won't work with more modern versions of Windows but it is a cool idea.

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: UNC and POSIX paths

[Christopher Faylor]

On Tue, Jun 18, 2013 at 10:30:09AM -0400, Christopher Faylor wrote:
>On Tue, Jun 18, 2013 at 12:26:32PM +0200, Corinna Vinschen wrote:
>>On Jun 17 22:47, g...@malth.us wrote:
>>> On Mon, 17 Jun 2013, at 21:42, Christopher Faylor thusly quipped:
>>> 
>>> > On Mon, Jun 17, 2013 at 07:18:12PM -0700, g...@malth.us wrote:
>>> >> BTW, along the same lines, I stated previously it would break
>>> >> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=m4/doub
>>> >> le-sl ash-root.m4.  Turns out I was wrong, the m4 has a hard-coded list
>>> >> of platforms.  So, I have to say, I can't think of one technical or
>>> >> merit-based reason this shouldn't be done, aside from the fact that
>>> >> it's annoying to hear it endlessly brought up on the mailing list (a
>>> >> problem which an implementation would, in fact, solve, not exacerbate).
>>> > 
>>> > I can't quite follow the logic here but if you're saying that if we no
>>> longer
>>> > treated // as /, people who want to use //usr/local/bin would not
>>> complain,
>>> > you're right.  That doesn't mean that a whole new class of complainer
>>> would not
>>> > show up, however.
>>> > 
>>> > I can say with absolute certainty that there is one person who would
>>> complain.
>>> 
>>> I was imagining a less intrusive hypothetical approach.
>>> 
>>> For example, perhaps a CYGWIN=nounc flag that would simply turn the feature
>>> off, or a way to deactivate in fstab -- in short, anything reversible, and,
>>> by default, preserving the existing behavior.  Prune-grafting "//" to "/smb"
>>> might have been a good idea had it been done at cygwin's inception, but I
>>> think it's probably too late now.
>>
>>A mount table approach along the lines of the cygdrive prefix handling
>>might not be such a bad thing, after all.  Something along these lines
>>
>>  none /mnt cygdrive binary,posix=0,user 0 0
>>  none /unc uncdrive binary,posix=0 0 0
>>
>>This would also fix the somewhat special feature that unc paths get the
>>same default flag treatment as cygdrive paths.
>
>That's what I was proposing earlier in the thread.  It's a SHTDI
>proposal, of course.

And, it nontrivially complicates path handling since we'd have to make
decisions about whether to honor // or not.

If we do consider this, I think we should take a step back and think
about revamping path handling to allow hooks for things like /dev,
/proc, /cygdrive rather than having to special case them.

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: Cross-compiling Linux kernel

[Christopher Faylor]

On Tue, Jun 18, 2013 at 10:33:08AM -0400, Christopher Faylor wrote:
>On Tue, Jun 18, 2013 at 12:17:06PM +0200, Corinna Vinschen wrote:
>>On Jun 18 10:56, Fedin Pavel wrote:
>>> [...]
>>>  P.S. I have got even more crazy idea, perhaps deserving a separate topic...
>>> BSD systems have Linux binary compatibility layer. Could we have one ?
>>> Technically this depends on ability to construct process image manually in
>>> Windows (*). Is it possible (using NT API of course) ? And, of course,
>>> someone needs lots of spare time to code this. :) OTOH, CoLinux already does
>>> this (yep, they are not 64-bit for now...), so perhaps there's no need to
>>> duplicate the job done.
>>
>>Not in the Cygwin DLL.  As an extra DLL layer I don't have a problem
>>with that.
>
>There was a project out there many years ago which did this.  You could
>run simple linux binaries on Windows.  I offered to host the development
>on sourceware.org (aka cygwin.com) but, IIRC, the developer never
>responded.
>
>I don't remember what the name of the project was and I'm sure that it
>won't work with more modern versions of Windows but it is a cool idea.

Here's one project: http://lbw.sourceforge.net/ but I don't remember if
this is the one I was thinking about or not.

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: UNC and POSIX paths

[Earnie Boyd]

On Tue, Jun 18, 2013 at 10:36 AM, Christopher Faylor wrote:
>
> And, it nontrivially complicates path handling since we'd have to make
> decisions about whether to honor // or not.
>

I'd suggest using /// for UNC, dropping exactly one / if FILEPATH[0]
and FILEPATH[1] is equal to /.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
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: UNC and POSIX paths

[Corinna Vinschen]

On Jun 18 11:05, Earnie Boyd wrote:
> On Tue, Jun 18, 2013 at 10:36 AM, Christopher Faylor wrote:
> >
> > And, it nontrivially complicates path handling since we'd have to make
> > decisions about whether to honor // or not.
> >
> 
> I'd suggest using /// for UNC, dropping exactly one / if FILEPATH[0]
> and FILEPATH[1] is equal to /.

That's not POSIX compatible.  See the URL I posted earlier in this thread.


Corinna

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

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

Re: What is a good profiling tool ? - problem with gprof

[Ariel Burbaickij]

 Uhm, may I ask for some pointers to Altera/Stawberry cygwins -- what is it?

On Tue, Jun 18, 2013 at 4:06 PM, J.B.W.Webber  wrote:
>
>
> -Original Message-
> Subject: Re: What is a good profiling tool ? - problem with gprof
>
> On Jun 18 12:11, Corinna Vinschen wrote:
>> On Jun 17 12:52, Larry Hall (Cygwin) wrote:
>> > On 6/17/2013 12:19 PM, J.B.W.Webber wrote:
>> > >Hi, I am trying to find in which function call the most time is being 
>> > >spent.
>> > >
>> > >I am using gcc and trying to compile and link with -g and -pg.
>> > >i.e. for a trivial test :
>> > >
>> > >$ cat helloworld.c
>> > >/* Hello World program */
>> > >#include
>> > >main()
>> > >{
>> > > printf("Hello World\n");
>> > >}
>> > >
>> > >$ gcc -g -pg -c helloworld.c
>> > >$ gcc -pg helloworld.o
>> > >helloworld.o: In function `main':
>> > >helloworld.c:6: undefined reference to `_mcount'
>> > >collect2: ld returned 1 exit status
>> > >
>> > >Any ideas ? Am I missing a .h call ? Or do I need to link to something ?
>> >
>> > Worked for me.  Perhaps your Strawberry gcc installation is interfering.
>>
>> I don't know how you succeeed to build that, Larry.  I could easily
>> reproduce the problem.  It was a build problem in Cygwin.  I fixed
>> that now and at the same time made the 64 bit profiling workable,
>> curtesy the
>> Mingw-w64 project, which already did the required work.  The original
>> profiling code was created within the Cygwin project ages ago, so I
>> could included the latest Mingw-w64 profiling code (almost) verbatim
>> into Cygwin and now it seems to work fine again for 32 and 64 bit.
>>
>> I'm just about to create a 2013-06-18 32 bit snapshot on
>> http://cygwin.com/snapshots/ and a 64 bit test release 1.7.12-5, which
>> both should be ready in an hour.
>
> Uploaded.  Please note that it's *not* enough to install the snapshot Cygwin 
> DLL.  The important items here are gcrt0.o and libgmon.a.
>
>
> Corinna
>
> --
> Corinna Vinschen  Please, send mails regarding Cygwin to
> Cygwin Maintainer cygwin AT cygwin DOT com
> Red Hat
>
> _
>
> Really thanks to all. That now works.
>
> Sorry for the slow reply, I did the install with the snapshot as suggested
> - no difference, at first, but I had been given the clues I needed.
>
> I used find to track all libgmon.a  on my laptop :
>
> C:/Altera/12.0sp2/quartus/bin/cygwin/lib/libgmon.a
> C:/Altera/12.0sp2/quartus/bin/cygwin/lib/mingw/libgmon.a
> C:/Altera/12.0sp2/quartus/bin/cygwin/usr/i686-pc-mingw32/lib/libgmon.a
> C:/Applications/Strawberry/c/x86_64-w64-mingw32/lib/libgmon.a
> C:/cygwin/lib/libgmon.a
> C:/cygwin/usr/i686-pc-mingw32/sys-root/mingw/lib/libgmon.a
> C:/cygwin/usr/lib/libgmon.a
>
> I blocked access to the Altera and Strawberry Cygwins, which made no 
> difference, (no, XMOS does not use Cygwin)
> But the answer was the version C:/cygwin/lib/libgmon.a
> I copied the new gcrt0.o and libgmon.a into C:/cygwin/lib/
> and all now works fine. I have the answer I needed.
>
> I do thank you all,
> Cheers,
> Beau
>
>

--
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: What is a good profiling tool ? - problem with gprof

[Dan Kegel]

Ariel Burbaickij wrote:
>  Uhm, may I ask for some pointers to Altera/Stawberry cygwins -- what is it?

Does it have something to do with http://en.wikipedia.org/wiki/Strawberry_Perl ?

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

X11 forwarding request failed on channel 0

[Andrew DeFaria]

Lately I noticed the following error when attempting to ssh from my 
Ubuntu (13.04) systems to my Cygwin system with X11 Forwarding turned on:


X11 forwarding request failed on channel 0

Any idea of how I can fix this?

Not sure if this is a Cygwin issue (but it does involve ssh) or a 
Cygwin/X issue.

--
Andrew DeFaria 
If you knees bent the other way, what would chairs look like?


--
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: What is a good profiling tool ? - problem with gprof

[J . B . W . Webber]

-Original Message-
Subject: Re: What is a good profiling tool ? - problem with gprof

Ariel Burbaickij wrote:
>  Uhm, may I ask for some pointers to Altera/Stawberry cygwins -- what is it?

Does it have something to do with http://en.wikipedia.org/wiki/Strawberry_Perl ?


Hi Ariel,
Altera produce Field Programmable Gate Array chips (FPGAs), and their NIOS II 
software for programming them is essentially a port of Unix type software to 
the Windows PC, by including its own Cygwin installation.

And yes, it is indeed  Strawberry_Perl, which is also based on Cygwin.
Cheers,
Beau

On Tue, Jun 18, 2013 at 4:06 PM, J.B.W.Webber  wrote:
>
>
> -Original Message-
> Subject: Re: What is a good profiling tool ? - problem with gprof
>
> On Jun 18 12:11, Corinna Vinschen wrote:
>> On Jun 17 12:52, Larry Hall (Cygwin) wrote:
>> > On 6/17/2013 12:19 PM, J.B.W.Webber wrote:
>> > >Hi, I am trying to find in which function call the most time is being 
>> > >spent.
>> > >
>> > >I am using gcc and trying to compile and link with -g and -pg.
>> > >i.e. for a trivial test :
>> > >
>> > >$ cat helloworld.c
>> > >/* Hello World program */
>> > >#include
>> > >main()
>> > >{
>> > > printf("Hello World\n");
>> > >}
>> > >
>> > >$ gcc -g -pg -c helloworld.c
>> > >$ gcc -pg helloworld.o
>> > >helloworld.o: In function `main':
>> > >helloworld.c:6: undefined reference to `_mcount'
>> > >collect2: ld returned 1 exit status
>> > >
>> > >Any ideas ? Am I missing a .h call ? Or do I need to link to something ?
>> >
>> > Worked for me.  Perhaps your Strawberry gcc installation is interfering.
>>
>> I don't know how you succeeed to build that, Larry.  I could easily 
>> reproduce the problem.  It was a build problem in Cygwin.  I fixed 
>> that now and at the same time made the 64 bit profiling workable, 
>> curtesy the
>> Mingw-w64 project, which already did the required work.  The original 
>> profiling code was created within the Cygwin project ages ago, so I 
>> could included the latest Mingw-w64 profiling code (almost) verbatim 
>> into Cygwin and now it seems to work fine again for 32 and 64 bit.
>>
>> I'm just about to create a 2013-06-18 32 bit snapshot on 
>> http://cygwin.com/snapshots/ and a 64 bit test release 1.7.12-5, 
>> which both should be ready in an hour.
>
> Uploaded.  Please note that it's *not* enough to install the snapshot Cygwin 
> DLL.  The important items here are gcrt0.o and libgmon.a.
>
>
> Corinna
>
> --
> Corinna Vinschen  Please, send mails regarding Cygwin to
> Cygwin Maintainer cygwin AT cygwin DOT com
> Red Hat
>
> _
>
> Really thanks to all. That now works.
>
> Sorry for the slow reply, I did the install with the snapshot as 
> suggested
> - no difference, at first, but I had been given the clues I needed.
>
> I used find to track all libgmon.a  on my laptop :
>
> C:/Altera/12.0sp2/quartus/bin/cygwin/lib/libgmon.a
> C:/Altera/12.0sp2/quartus/bin/cygwin/lib/mingw/libgmon.a
> C:/Altera/12.0sp2/quartus/bin/cygwin/usr/i686-pc-mingw32/lib/libgmon.a
> C:/Applications/Strawberry/c/x86_64-w64-mingw32/lib/libgmon.a
> C:/cygwin/lib/libgmon.a
> C:/cygwin/usr/i686-pc-mingw32/sys-root/mingw/lib/libgmon.a
> C:/cygwin/usr/lib/libgmon.a
>
> I blocked access to the Altera and Strawberry Cygwins, which made no 
> difference, (no, XMOS does not use Cygwin) But the answer was the 
> version C:/cygwin/lib/libgmon.a I copied the new gcrt0.o and libgmon.a 
> into C:/cygwin/lib/ and all now works fine. I have the answer I needed.
>
> I do thank you all,
> Cheers,
> Beau
>
>

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


--
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: subversion 1.7.10-1 failure: CRYPTO_memcmp entry point not found in cygcrypto-1.0.0.dll

[David Rothenberger]

On 6/18/2013 3:25 AM, Pascal Dupuis wrote:
> I produced a complete cygcheck output, the entry about cygcrypto-1.0.0.dll is
>  1516k 2012/09/01 C:\cygwin\bin\cygcrypto-1.0.0.dll - os=4.0 img=1.0 sys=4.0
>   "cygcrypto-1.0.0.dll" v0.0 ts=2012-09-01 11:06

That DLL is out-of-date. Here's what I get on my system:

  373k 2013/02/08 C:\cygwin\bin\cygcurl-4.dll - os=4.0 img=1.0 sys=4.0
  "cygcurl-4.dll" v0.0 ts=2013-02-08 01:42

Try re-installing the libopenssl100 package.

-- 
David Rothenberger    daver...@acm.org

Volunteer Cygwin Subversion maintainer.


--
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: subversion 1.7.10-1 failure: CRYPTO_memcmp entry point not found in cygcrypto-1.0.0.dll

[Pascal Dupuis]

OK, found the culprit. It seems some update process went wrong, and
there were a few files under /usr/bin with name like f.i.
libz.dll.new.

I made a script to rename file.dll.new into file.dll ... and found
myself into more troubles, because sometimes the file.dll was newer
than the file.dll.new ! Is it possible to either check each installed
file, either re-install all packages, to ensure every file is at the
right version ?

Regards

Pascal

--
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: What is a good profiling tool ? - problem with gprof

[Corinna Vinschen]

On Jun 18 16:28, J.B.W.Webber wrote:
> -Original Message-
> Subject: Re: What is a good profiling tool ? - problem with gprof
> 
> Ariel Burbaickij wrote:
> >  Uhm, may I ask for some pointers to Altera/Stawberry cygwins -- what is it?
> 
> Does it have something to do with 
> http://en.wikipedia.org/wiki/Strawberry_Perl ?
> 
> 
> Hi Ariel,
> Altera produce Field Programmable Gate Array chips (FPGAs), and their NIOS II 
> software for programming them is essentially a port of Unix type software to 
> the Windows PC, by including its own Cygwin installation.
> 
> And yes, it is indeed  Strawberry_Perl, which is also based on Cygwin.

I don't see any cygwin1.dll in the Strawberry Perl packages.


Corinna

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

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

RE: What is a good profiling tool ? - problem with gprof

[J . B . W . Webber]

-Original Message-
Subject: Re: What is a good profiling tool ? - problem with gprof

On Jun 18 16:28, J.B.W.Webber wrote:
> -Original Message-
> Subject: Re: What is a good profiling tool ? - problem with gprof
> 
> Ariel Burbaickij wrote:
> >  Uhm, may I ask for some pointers to Altera/Stawberry cygwins -- what is it?
> 
> Does it have something to do with 
> http://en.wikipedia.org/wiki/Strawberry_Perl ?
> 
> 
> Hi Ariel,
> Altera produce Field Programmable Gate Array chips (FPGAs), and their NIOS II 
> software for programming them is essentially a port of Unix type software to 
> the Windows PC, by including its own Cygwin installation.
> 
> And yes, it is indeed  Strawberry_Perl, which is also based on Cygwin.

I don't see any cygwin1.dll in the Strawberry Perl packages.


Corinna

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

--
Ah, I think you are right (it is a recent install, but I have not used it much) 
: 
I searched on libgmon.a
And found :
C:/Applications/Strawberry/c/x86_64-w64-mingw32/lib/libgmon.a
Which suggests it is mingw32 based - this sounds right.

Searching on cygwin I just find :
C:/Applications/Strawberry/perl/lib/ExtUtils/CBuilder/Platform/cygwin.pm
C:/Applications/Strawberry/perl/lib/Module/Build/Platform/cygwin.pm
C:/Applications/Strawberry/perl/lib/pods/perlcygwin.pod

Cheers,
   Beau

Re: Cross-compiling Linux kernel

[René Berber]

On 6/18/2013 9:37 AM, Christopher Faylor wrote:


There was a project out there many years ago which did this.  You could
run simple linux binaries on Windows.  I offered to host the development
on sourceware.org (aka cygwin.com) but, IIRC, the developer never
responded.

I don't remember what the name of the project was and I'm sure that it
won't work with more modern versions of Windows but it is a cool idea.


Here's one project: http://lbw.sourceforge.net/ but I don't remember if
this is the one I was thinking about or not.


Here's another: http://atratus.org/

Quoting their page "Atratus is a Windows program that can run unmodified 
Linux binaries."  ... "Atratus can load ELF format executables created 
with gcc under Linux run them on a Windows system without a CPU emulator 
or virtual machine".


Haven't used it, but it does sound interesting, and its currently being 
developed (version 0.10).

--
René Berber

--
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: Cross-compiling Linux kernel

[Christopher Faylor]

On Tue, Jun 18, 2013 at 01:07:56PM -0500, Ren? Berber wrote:
>On 6/18/2013 9:37 AM, Christopher Faylor wrote:
>
>>> There was a project out there many years ago which did this.  You could
>>> run simple linux binaries on Windows.  I offered to host the development
>>> on sourceware.org (aka cygwin.com) but, IIRC, the developer never
>>> responded.
>>>
>>> I don't remember what the name of the project was and I'm sure that it
>>> won't work with more modern versions of Windows but it is a cool idea.
>>
>> Here's one project: http://lbw.sourceforge.net/ but I don't remember if
>> this is the one I was thinking about or not.
>
>Here's another: http://atratus.org/
>
>Quoting their page "Atratus is a Windows program that can run unmodified 
>Linux binaries."  ... "Atratus can load ELF format executables created 
>with gcc under Linux run them on a Windows system without a CPU emulator 
>or virtual machine".
>
>Haven't used it, but it does sound interesting, and its currently being 
>developed (version 0.10).

Interesting.  That website mentions LINE which, I think is the project I
was struggling to recall.

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

Adding MSYS functionality to Cygwin

[Алексей Павлов]

Hi everybody!

I want to add MSYS functionality to Cygwin.
More than 10 years ago Cygwin 1.3 had forked to MSYS. But now this
MSYS is very old and don't has any support for it.
Primary goal of MSYS is to provide environment with GNU utilities for
building application using native Mingw compilers. The main
differences from original Cygwin is working with native Win32
applications.
So I create new MSYS based on last Cygwin and it works good I think.
But I think that the right way is to implement MSYS functionality in
Cygwin sources directly because in this case we don't need to do many
copies of different Cygwin dll with other names. And we always has
latest work from Cygwin guys.

I can write next tasks that need to be in MSYS mode:

1. The correct definition of executables belonging to Cygwin DLL.
2. Translating paths in arguments and environment variables to Windows
form for pure Win32 applications.
3. In MSYS mode Cygwin need to be very portable: do not use registry
to store any info, do not use /etc/passwd and /etc/group, all mount
points need to be with noacl option to avoid problems with permission
denied.
4. Ability to change OSNAME that controlled by uname function in Cygwin DLL.
5. Use shorted mount point options in /etc/fstab - only win32_path and
posix_path.
6. SYMLINKS. Now Cygwin can work with native symlinks but it cannot be
used in all situations. From the other side - Win32 applications
doesn't understand Cygwin symlinks. As fallback option we need to
create copies of files and directories instead symlinks.

I want to hear your opinions about how it can be implemented in Cygwin codebase.

Regards,
Alexey.

--
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: Adding MSYS functionality to Cygwin

[Christopher Faylor]

On Tue, Jun 18, 2013 at 10:40:36PM +0400, ??? ?? wrote:
>Hi everybody!
>
>I want to add MSYS functionality to Cygwin.
>More than 10 years ago Cygwin 1.3 had forked to MSYS. But now this
>MSYS is very old and don't has any support for it.
>Primary goal of MSYS is to provide environment with GNU utilities for
>building application using native Mingw compilers. The main
>differences from original Cygwin is working with native Win32
>applications.
>So I create new MSYS based on last Cygwin and it works good I think.
>But I think that the right way is to implement MSYS functionality in
>Cygwin sources directly because in this case we don't need to do many
>copies of different Cygwin dll with other names. And we always has
>latest work from Cygwin guys.
>
>I can write next tasks that need to be in MSYS mode:
>
>1. The correct definition of executables belonging to Cygwin DLL.
>2. Translating paths in arguments and environment variables to Windows
>form for pure Win32 applications.
>3. In MSYS mode Cygwin need to be very portable: do not use registry
>to store any info, do not use /etc/passwd and /etc/group, all mount
>points need to be with noacl option to avoid problems with permission
>denied.
>4. Ability to change OSNAME that controlled by uname function in Cygwin DLL.
>5. Use shorted mount point options in /etc/fstab - only win32_path and
>posix_path.
>6. SYMLINKS. Now Cygwin can work with native symlinks but it cannot be
>used in all situations. From the other side - Win32 applications
>doesn't understand Cygwin symlinks. As fallback option we need to
>create copies of files and directories instead symlinks.
>
>I want to hear your opinions about how it can be implemented in Cygwin 
>codebase.

Corinna and I have been discussing this in private and I thought
someone (you?) was going to bring this up in the cygwin-developers
list.

However, since you mention it here, my opinion is that we should add
hooks in the DLL which allow certain operations like path translation,
symlinks, and command line substitution to be short-circuited or
modified.  In that scenario, you'd still have a MSYS.dll but it would
rely on cygwin1.dll for most of the heavy lifting.

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: Adding MSYS functionality to Cygwin

[Warren Young]

On 6/18/2013 12:40, Алексей Павлов wrote:


1. The correct definition of executables belonging to Cygwin DLL.


Can you give an example of what you mean here?

This must be some kind of translation error, since executables never 
belong to DLLs.  The reverse is sometimes true, but mostly not.



2. Translating paths in arguments and environment variables to Windows
form for pure Win32 applications.


I don't see how Cygwin can reliably predict when and whether to do this. 
 That is why it provides cygpath(1).  You, the user, use that tool when 
you know you need a translation done.



3. In MSYS mode Cygwin need to be very portable


It would indeed be nice to have a portable Cygwin.  That is, one that 
could be run from a copied directory or USB key, without being formally 
installed.  Such a thing would need to solve the 3PP problem, though, 
which is Hard (tm).



4. Ability to change OSNAME that controlled by uname function in Cygwin DLL.


Who needs this, and why?


5. Use shorted mount point options in /etc/fstab - only win32_path and
posix_path.


Why do you need this?

Doesn't it conflict with your point #3?  A portable Cygwin would go out 
of its way to avoid using /etc/fstab.  I would guess that such a Cygwin 
variant would simply provide an unchangeable default behavior, and you'd 
have to be happy with it.



6. SYMLINKS. Now Cygwin can work with native symlinks but it cannot be
used in all situations. From the other side - Win32 applications
doesn't understand Cygwin symlinks. As fallback option we need to
create copies of files and directories instead symlinks.


Copy semantics are not an acceptable fallback for ln.  (Or where they 
are, you can do your own copying.)


Example:

$ ln -s dir1 dir2

Cygwin decides it can't make the symlink, so it spends a lot of I/O and 
disk space cloning the tree.  Bad enough.  But then:


 $ vi dir2/somefile.txt
 (make edits, :wq)

Now dir2/somefile.txt is not the same as dir1/somefile.txt.

This is going to break something, I'm sure of it.

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

Re: Adding MSYS functionality to Cygwin

[Алексей Павлов]

2013/6/18 Warren Young :
> On 6/18/2013 12:40, Алексей Павлов wrote:
>>
>>
>> 1. The correct definition of executables belonging to Cygwin DLL.
>
>
> Can you give an example of what you mean here?
>
All cygwin applications depends on cygwin1.dll. We need to translate
arguments only for non-cygwin applications.

> This must be some kind of translation error, since executables never belong
> to DLLs.  The reverse is sometimes true, but mostly not.
>
>
>> 2. Translating paths in arguments and environment variables to Windows
>> form for pure Win32 applications.
>
>
> I don't see how Cygwin can reliably predict when and whether to do this.
> That is why it provides cygpath(1).  You, the user, use that tool when you
> know you need a translation done.
>
>
Win32 application doesn't know anything about cygwin paths and can't
use it. For example, you cannot do something like this on Cygwin:
 notepad /home/user/mydoc.txt
Also when you using autoconf utilities generated Makefile has Cygwin
paths and you cannot use it with native compiler.


>> 3. In MSYS mode Cygwin need to be very portable
>
>
> It would indeed be nice to have a portable Cygwin.  That is, one that could
> be run from a copied directory or USB key, without being formally installed.
> Such a thing would need to solve the 3PP problem, though, which is Hard
> (tm).
>
>
>> 4. Ability to change OSNAME that controlled by uname function in Cygwin
>> DLL.
>
>
> Who needs this, and why?
>
To use with native mingw compilers. We change OS to MINGW32 and
autoconf utilities think that it is Mingw shell.

>
>> 5. Use shorted mount point options in /etc/fstab - only win32_path and
>> posix_path.
>
>
> Why do you need this?
For backward compatibility with old MSYS and users experience of using MSYS.

>
> Doesn't it conflict with your point #3?  A portable Cygwin would go out of
> its way to avoid using /etc/fstab.  I would guess that such a Cygwin variant
> would simply provide an unchangeable default behavior, and you'd have to be
> happy with it.
>
No it doesn't conflict. Sometimes you need mount points. File
/etc/fstab doesn't break any portability option)

>
>> 6. SYMLINKS. Now Cygwin can work with native symlinks but it cannot be
>> used in all situations. From the other side - Win32 applications
>> doesn't understand Cygwin symlinks. As fallback option we need to
>> create copies of files and directories instead symlinks.
>
>
> Copy semantics are not an acceptable fallback for ln.  (Or where they are,
> you can do your own copying.)
>
> Example:
>
> $ ln -s dir1 dir2
>
> Cygwin decides it can't make the symlink, so it spends a lot of I/O and disk
> space cloning the tree.  Bad enough.  But then:
>
>  $ vi dir2/somefile.txt
>  (make edits, :wq)
>
> Now dir2/somefile.txt is not the same as dir1/somefile.txt.
>
> This is going to break something, I'm sure of it.
>
For Win32 applications we cannot use Cygwin symlinks - only native.
But native symlinks sometimes can't be used - you haven't privileges
for it, filesystem doesn't support it.

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

Re: Adding MSYS functionality to Cygwin

[Christopher Faylor]

[I'm being a reluctant explicator here]

On Tue, Jun 18, 2013 at 01:10:06PM -0600, Warren Young wrote:
>On 6/18/2013 12:40, ??  wrote:
>>
>> 1. The correct definition of executables belonging to Cygwin DLL.
>
>Can you give an example of what you mean here?
>
>This must be some kind of translation error, since executables never 
>belong to DLLs.  The reverse is sometimes true, but mostly not.

I don't get this one either.  Maybe the OP means that cygwin has to know
when to translate command-line arguments for non-Cygwin executables?

>> 2. Translating paths in arguments and environment variables to Windows
>> form for pure Win32 applications.
>
>I don't see how Cygwin can reliably predict when and whether to do this. 
>  That is why it provides cygpath(1).  You, the user, use that tool when 
>you know you need a translation done.

Yep.  Welcome to MSYS.  I believe that MSYS translates "things that look
like paths" so if you do something like: "foo /blah/blurf" and "foo" is
a Windows program then "/blah/blurf" gets translated into
"c:\whatever\blah\blurf".

>> 3. In MSYS mode Cygwin need to be very portable
>
>It would indeed be nice to have a portable Cygwin.  That is, one that 
>could be run from a copied directory or USB key, without being formally 
>installed.  Such a thing would need to solve the 3PP problem, though, 
>which is Hard (tm).

Why wouldn't that work now?  You can copy cygwin1.dll anywhere you want.

>> 4. Ability to change OSNAME that controlled by uname function in Cygwin DLL.
>
>Who needs this, and why?

Maybe it needs to identify itself as "MSYS" for configure scripts?

>> 5. Use shorted mount point options in /etc/fstab - only win32_path and
>> posix_path.
>
>Why do you need this?
>
>Doesn't it conflict with your point #3?  A portable Cygwin would go out 
>of its way to avoid using /etc/fstab.  I would guess that such a Cygwin 
>variant would simply provide an unchangeable default behavior, and you'd 
>have to be happy with it.

Don't get this one either.

>> 6. SYMLINKS. Now Cygwin can work with native symlinks but it cannot be
>> used in all situations. From the other side - Win32 applications
>> doesn't understand Cygwin symlinks. As fallback option we need to
>> create copies of files and directories instead symlinks.
>
>Copy semantics are not an acceptable fallback for ln.  (Or where they 
>are, you can do your own copying.)

All of the above is just an explanation of the way that MSYS currently
operates.  The argument about semantics of ln (which I agree with)
doesn't really matter since "that's how MSYS works".

This is, however, one of the reasons why I'm not comfortable modifying
Cygwin to behave differently.  Having spent the last 15 years telling
people "That isn't the way POSIX works" makes it hard for me to say
"But if that's what you want then just set CYGWIN=WINCOMPAT and you'll
get it" .

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: git svn fork() problems on cygwin 1.7.20

[Charles Wilson]

On 6/17/2013 10:45 AM, Mikko Rapeli wrote:

On Mon, Jun 17, 2013 at 05:00:47PM +0300, Mikko Rapeli wrote:

Has anyone else seen these when using git svn or other perl programs
on cygwin 1.7.20?



$ git svn rebase
...
   0 [main] perl 4424 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied


Hmm. Searching for clues I saw this
http://stackoverflow.com/questions/12042363/cygwin-git-fork-error-on-pull

and tried out with minimal PATH:

$ PATH=/bin:/usr/bin git svn rebase
Current branch master is up to date.

Default PATH on the machine includes various tools, compilers, CMake etc.
Tried to bisect it but it seems that full long PATH has an 80% failure rate
while mimal PATH=/bin/usr/bin has a 20% failure rate, but I could not identify
which PATH component could be to blame.


See here:
http://www.cygwin.com/ml/cygwin-apps/2013-04/msg00342.html
and Corinna's reply:
"Do you have a big environment?  Thre's a chance that the stack address
moves due to that."

--
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: Adding MSYS functionality to Cygwin

[Warren Young]

On 6/18/2013 13:31, Christopher Faylor wrote:

On Tue, Jun 18, 2013 at 01:10:06PM -0600, Warren Young wrote:

3. In MSYS mode Cygwin need to be very portable


It would indeed be nice to have a portable Cygwin.  That is, one that
could be run from a copied directory or USB key, without being formally
installed.  Such a thing would need to solve the 3PP problem, though,
which is Hard (tm).


Why wouldn't that work now?  You can copy cygwin1.dll anywhere you want.


Because FAQ item 4.19, and because 3PP.

I'm envisioning some configuration option (runtime or build time) that 
would create a cygwin1.dll that only serves the executable(s) shipped 
alongside it.  If there is more than one executable, they would only be 
expected to cooperate with each other, so that the need for a common 
cygheap wouldn't obtain.


Such a distribution wouldn't be "Cygwin" per se.  Its primary purpose 
would be so people could bundle the DLL with a program that runs in its 
own little world, or a system of such programs.


In this mode, Cygwin wouldn't require any persistent configuration 
(files on disk, the registry, etc.) or create such.  It would start up 
in its default mode, provide whatever services the executable that 
loaded it required, and quietly go away again without leaving any 
footprints behind when unloaded.


The executable linked to cygwin1p.dll ('p' = portable build variant) 
could make any persistent changes it wanted, of course.  I'm just saying 
that this Portable Cygwin DLL that I have handwaved into existence 
shouldn't do this on its own behalf, or require that anyone else do it 
for the DLL ahead of time.


In other words, I'm trying to turn the second 'P' in 3PP back into 
"Packagers".  Bring the perverts back into the fold, as it were, instead 
of casting them out, thus giving them no reason to try and cooperate 
with mainline Cygwin.


--
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: Adding MSYS functionality to Cygwin

[Charles Wilson]

On 6/18/2013 2:40 PM, Алексей Павлов wrote:

I want to add MSYS functionality to Cygwin.
More than 10 years ago Cygwin 1.3 had forked to MSYS. But now this
MSYS is very old and don't has any support for it.

...


I want to hear your opinions about how it can be implemented in Cygwin codebase.


Go over to the mingw.org mailing lists; there is ongoing effort related 
to MSYS2 which is based on a much more recent fork of cygwin IIUC. Also, 
many of the earlier hacks that msys-1 implemented are no longer needed 
thanks to exploiting new features in the underlying cygwin (like: 
/etc/fstab).


Also, I *think* the development is being tracked as a branch from a 
cygwin repo clone, so keeping msys2 updated with respect to cygwin 
changes should be easier.


However, discussing "not-cygwin" on the cygwin list(s) is A Bad Idea, so 
you should go "over there" and talk it out with those guys.


--
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: Setup.exe won't run from Bash on Windows 8

[Buchbinder, Barry (NIH/NIAID) [E]]

Yaakov (Cygwin/X) sent the following at Monday, June 17, 2013 7:17 PM
>On 2013-06-17 18:13, Chloe wrote:
>> But it will run if I double click it from Explorer.  I have
>> execute permissions.  What is wrong?
>
>Due to UAC Installer Detection, setup.exe requires Admin permissions
>in order to run, but bash doesn't know that.  Use cygstart
>/path/to/setup.exe to work around this.

Another thing to try is to rename setup.exe.
On Windows 7, getcygwin.exe works for me.

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.


--
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: git svn fork() problems on cygwin 1.7.20

[Larry Hall (Cygwin)]

On 6/18/2013 3:28 AM, Mikko Rapeli wrote:

Missing file: 
/usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll from 
package perl
perl 5.14.2-3 Incomplete


Maybe reinstalling the perl package will help?

--
Larry

_

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

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

Re: Adding MSYS functionality to Cygwin

[Warren Young]

On 6/18/2013 13:30, Алексей Павлов wrote:

2013/6/18 Warren Young :

On 6/18/2013 12:40, Алексей Павлов wrote:


1. The correct definition of executables belonging to Cygwin DLL.


Can you give an example of what you mean here?


All cygwin applications depends on cygwin1.dll. We need to translate
arguments only for non-cygwin applications.


It would be possible, though somewhat evil, for Cygwin's exec() 
implementation to peek at the DLL dependency list of a program before 
starting it, and from that infer whether it should automatically 
translate paths.


The I/O hit this would cause would be nontrivial.  Keep in mind that one 
of the core ideas behind Unix is that fork() is cheap, and exec() is 
even cheaper.  This deeply affects how software native to Unixy systems 
gets designed.  As a result, Cygwin already has a problem with its slow 
fork() implementation; this idea makes exec() expensive, too, with 
predictable consequences to overall system speed.


I don't see how Cygwin couldn't afford to behave this way by default. 
Maybe as an option?



2. Translating paths in arguments and environment variables to Windows


I just re-read this, and realized the implications of "and environment 
variables."  You're proposing some kind of global search-and-replace 
operation, which will inevitably turn into a Whac-a-Mole game.


(http://goo.gl/vpYfA)


  notepad /home/user/mydoc.txt


From my explanation above, you do see how expensive it would be for 
Cygwin to implement your desired behavior, right?



Also when you using autoconf utilities generated Makefile has Cygwin
paths and you cannot use it with native compiler.


Those on the Automake list have wrestled with this off and on.  It's 
more or less impossible to solve, which is why competing systems like 
CMake, SCons and Bakefile were created.


I think the best you can hope for is that if you run ./configure under 
Cygwin with CC=i686-pc-mingw32-gcc and such, it creates a Makefile that 
works with Cygwin make, which calls out to the MinGW cross-compiler. 
Since the cross-compiler is a Cygwin app, not a native executable, it 
understands POSIX paths yet still builds native Windows executables.


Or, you could say "./configure CC=mingw32-gcc" and depend on my proposed 
answer to your point #1.



4. Ability to change OSNAME that controlled by uname function in Cygwin
DLL.



Who needs this, and why?


To use with native mingw compilers. We change OS to MINGW32 and
autoconf utilities think that it is Mingw shell.


What's wrong with using the MinGW cross-compiler from the Cygwin package 
repository instead?



5. Use shorted mount point options in /etc/fstab - only win32_path and
posix_path.



Why do you need this?

For backward compatibility with old MSYS and users experience of using MSYS.


I don't see why that's Cygwin's concern.

It should be sufficient for Cygwin to provides a reasonable path 
forward, so that those relying on MSYS can migrate to the new scheme.


Infinite backwards compatibility is its own problem.


Doesn't it conflict with your point #3?  A portable Cygwin would go out of
its way to avoid using /etc/fstab.  I would guess that such a Cygwin variant
would simply provide an unchangeable default behavior, and you'd have to be
happy with it.


No it doesn't conflict. Sometimes you need mount points. File
/etc/fstab doesn't break any portability option)


If you need custom mount points and such, use Cygwin.


For Win32 applications we cannot use Cygwin symlinks - only native.
But native symlinks sometimes can't be used - you haven't privileges
for it, filesystem doesn't support it.


I already know that.  Your proposal is wrong-headed from the start.  If 
you repeat it, it's still incorrect.


Here's something for you to try on your own system:

$ cd /bin
$ mv ln.exe sane-ln.exe
$ ln -s cp.exe ln.exe

Or if you're feeling really ambitious, do it at the cygwin1.dll level, 
by changing its implementations of link(2) and symlink(2) to recursive 
copy operations.  You have the source.


If the resulting system works well at all, it will be much slower.  I 
predict you'll find that something breaks, though, due to the semantic 
issues I tried to show by example in my previous post.


--
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: Adding MSYS functionality to Cygwin

[Warren Young]

On 6/18/2013 16:04, Warren Young wrote:

 $ cd /bin
 $ mv ln.exe sane-ln.exe
 $ ln -s cp.exe ln.exe


Of course, that final step should be

$ cp cp.exe ln.exe

--
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: UNC and POSIX paths

[Andrey Repin]

Greetings, Christopher Faylor!

> And, it nontrivially complicates path handling since we'd have to make
> decisions about whether to honor // or not.

That's an easy decision: "//" should remain as Cygwin/POSIX equivalent of
"\\" AKA UNC path access.
If anyone want to argument against it with broken scripting examples, ...
I would question their sanity.

> If we do consider this, I think we should take a step back and think
> about revamping path handling to allow hooks for things like /dev,
> /proc, /cygdrive rather than having to special case them.

SHTDI, as you said... But it'd be interesting advancement in /etc/fstab
evolution.


--
WBR,
Andrey Repin (anrdae...@freemail.ru) 19.06.2013, <02:29>

Sorry for my terrible english...


--
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: X11 forwarding request failed on channel 0

[Jon TURNEY]

On 18/06/2013 17:23, Andrew DeFaria wrote:
> Lately I noticed the following error when attempting to ssh from my Ubuntu

Not sure if "lately" means you haven't changed anything, but it didn't report
this error before, or you've only recently started paying attention :D

> (13.04) systems to my Cygwin system with X11 Forwarding turned on:
> 
> X11 forwarding request failed on channel 0
> 
> Any idea of how I can fix this?
> 
> Not sure if this is a Cygwin issue (but it does involve ssh) or a Cygwin/X 
> issue.

Possibly you do not have the remote sshd configured to allow X11 forwarding.

See A5 to Q6.1 in the Cygwin/X FAQ [1].  The other answers may also be
informative.

[1] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-ssh-no-x11forwarding

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
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: Cross-compiling Linux kernel

[Larry Hall (Cygwin)]

On 6/18/2013 2:23 PM, Christopher Faylor wrote:

On Tue, Jun 18, 2013 at 01:07:56PM -0500, Ren? Berber wrote:

On 6/18/2013 9:37 AM, Christopher Faylor wrote:


There was a project out there many years ago which did this.  You could
run simple linux binaries on Windows.  I offered to host the development
on sourceware.org (aka cygwin.com) but, IIRC, the developer never
responded.

I don't remember what the name of the project was and I'm sure that it
won't work with more modern versions of Windows but it is a cool idea.


Here's one project: http://lbw.sourceforge.net/ but I don't remember if
this is the one I was thinking about or not.


Here's another: http://atratus.org/

Quoting their page "Atratus is a Windows program that can run unmodified
Linux binaries."  ... "Atratus can load ELF format executables created
with gcc under Linux run them on a Windows system without a CPU emulator
or virtual machine".

Haven't used it, but it does sound interesting, and its currently being
developed (version 0.10).


Interesting.  That website mentions LINE which, I think is the project I
was struggling to recall.


Yeah, I was just going to mention LINE.  I don't know why I can remember
the name of such an obscure (although very interesting!) project and not
the name of people I just met. ;-)

--
Larry

_

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

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

Re: Cross-compiling Linux kernel

[Dan Kegel]

On Tue, Jun 18, 2013 at 11:07 AM, René Berber  wrote:
> Here's another: http://atratus.org/

Aha.  That's by Mike McCormack, a Codeweavers/Wine alum, who also did
http://ring3k.org/

I wonder how far atratus is from running wine.
At which point one could try running cygwin on wine on atratus on windows :-)

Which reminds me: any interest in fixing an alleged cygwin stack
problem that bothers wine?
http://bugs.winehq.org/show_bug.cgi?id=24018#c9
- Dan

--
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: Adding MSYS functionality to Cygwin

[Warren Young]

On 6/18/2013 16:04, Warren Young wrote:

You're proposing some kind of global search-and-replace
operation, which will inevitably turn into a Whac-a-Mole game.


I just thought of an example.  How many POSIX paths are in this 
perfectly legal command, which invokes a native Windows executable?


$ xcopy /bin foo bar

The wrong answer is, "three."

Now tell me how cygwin1.dll is expected to realize it should only 
translate the final two arguments to xcopy.


--
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: subversion 1.7.10-1 failure: CRYPTO_memcmp entry point not found in cygcrypto-1.0.0.dll

[Yaakov (Cygwin/X)]

On 2013-06-18 12:05, Pascal Dupuis wrote:

OK, found the culprit. It seems some update process went wrong, and
there were a few files under /usr/bin with name like f.i.
libz.dll.new.

I made a script to rename file.dll.new into file.dll ... and found
myself into more troubles, because sometimes the file.dll was newer
than the file.dll.new ! Is it possible to either check each installed
file, either re-install all packages, to ensure every file is at the
right version ?


First, be sure to exit ALL Cygwin processes, including services. 
(Failure to do so is what causes these installation hiccups in the first 
place.)


Second, I suggest deleting all those '*.new' files, as well as your 
entire setup download cache, just in case.


Finally, in setup, choose Install from Internet, then in the package 
chooser view, toggle the word "Default" next to the "All" super-category 
until it says Reinstall.  That will reinstall all currently-installed 
packages; a bit brute-force, but that will fix any such problems in your 
installation.



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: Updating Git

[Yaakov (Cygwin/X)]

On 2013-06-18 08:11, Adam Dinwoodie wrote:

Would it be possible for the Git maintainer to update Git to a more recent
version than 1.7.9, which was released almost 18 months ago?  Git is now on
v1.8.3.1.


FWIW, I have been using 1.8 versions for a little while without incident.


Alternatively, I'd be willing to take over the maintainership, although there
may be initial teething difficulties as I've only just managed to get Git
building on my machine, still see it failing some test cases, and have not
maintained a Cygwin package previously.


For whomever ends up updating git, I would propose a number of changes 
from Ports:


http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/git

There are a number of packaging improvements there, splitting up extra 
components by dependencies, installing all the documentation (to fix git 
help -w), and a patch to use cygstart as the default "browser" (ditto).



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: X11 forwarding request failed on channel 0

[Andrew DeFaria]

On 06/18/2013 04:01 PM, Jon TURNEY wrote:

On 18/06/2013 17:23, Andrew DeFaria wrote:

Lately I noticed the following error when attempting to ssh from my Ubuntu

Not sure if "lately" means you haven't changed anything, but it didn't report
this error before, or you've only recently started paying attention :D
More like the later. I only run Windows in a VM anymore and I only 
really use it for Playon (See http://playon.tv) - that and I have some 
Perl code I want to make sure works on Windows through Cygwin. So most 
of the time I'm not running any X stuff on Cygwin.

(13.04) systems to my Cygwin system with X11 Forwarding turned on:

X11 forwarding request failed on channel 0

Any idea of how I can fix this?

Not sure if this is a Cygwin issue (but it does involve ssh) or a Cygwin/X 
issue.

Possibly you do not have the remote sshd configured to allow X11 forwarding.

See A5 to Q6.1 in the Cygwin/X FAQ [1].  The other answers may also be
informative.

[1] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-ssh-no-x11forwarding
That seems to be it - ForwardX11 was commented out in /etc/sshd_config 
on the Cygwin box. Is this a new default?


In any event thanks.
--
Andrew DeFaria 
It has been said that democracy is the worst form of government except 
all the others that have been tried.



--
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: Adding MSYS functionality to Cygwin

[Christopher Faylor]

On Tue, Jun 18, 2013 at 04:04:06PM -0600, Warren Young wrote:
>On 6/18/2013 13:30, ??? ?? wrote:
>> 2013/6/18 Warren Young :
>>> On 6/18/2013 12:40, ??? ?? wrote:

 1. The correct definition of executables belonging to Cygwin DLL.
>>>
>>> Can you give an example of what you mean here?
>>>
>> All cygwin applications depends on cygwin1.dll. We need to translate
>> arguments only for non-cygwin applications.
>
>It would be possible, though somewhat evil, for Cygwin's exec() 
>implementation to peek at the DLL dependency list of a program before 
>starting it, and from that infer whether it should automatically 
>translate paths.

Cygwin already does this.  It detects whether the program it is about
to run uses the Cygwin DLL and, if not, makes decisions on how to
handle exec.  It would be relatively easy to extend this.

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: Adding MSYS functionality to Cygwin

[Christopher Faylor]

On Tue, Jun 18, 2013 at 03:24:52PM -0600, Warren Young wrote:
>On 6/18/2013 13:31, Christopher Faylor wrote:
>> On Tue, Jun 18, 2013 at 01:10:06PM -0600, Warren Young wrote:
 3. In MSYS mode Cygwin need to be very portable
>>>
>>> It would indeed be nice to have a portable Cygwin.  That is, one that
>>> could be run from a copied directory or USB key, without being formally
>>> installed.  Such a thing would need to solve the 3PP problem, though,
>>> which is Hard (tm).
>>
>> Why wouldn't that work now?  You can copy cygwin1.dll anywhere you want.
>
>Because FAQ item 4.19, and because 3PP.

The FAQ is out-of-date.  Multiple Cygwin copies should coexist peacefully
these days although it still is something that we wouldn't necessarily
advocate for a novice user.

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: Adding MSYS functionality to Cygwin

[Christopher Faylor]

On Tue, Jun 18, 2013 at 05:29:04PM -0400, Charles Wilson wrote:
>However, discussing "not-cygwin" on the cygwin list(s) is A Bad Idea, so 
>you should go "over there" and talk it out with those guys.

Let me state it again: Corinna and I have been having private discussion
about this and are open to talking about the possibility of adding
MSYS capability to Cygwin.  I'm advocating adding hooks to the DLL
which would accomplish that.

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: Cross-compiling Linux kernel

[Christopher Faylor]

On Tue, Jun 18, 2013 at 07:05:56PM -0400, Larry Hall (Cygwin) wrote:
>On 6/18/2013 2:23 PM, Christopher Faylor wrote:
>> On Tue, Jun 18, 2013 at 01:07:56PM -0500, Ren? Berber wrote:
>>> On 6/18/2013 9:37 AM, Christopher Faylor wrote:
>>>
> There was a project out there many years ago which did this.  You could
> run simple linux binaries on Windows.  I offered to host the development
> on sourceware.org (aka cygwin.com) but, IIRC, the developer never
> responded.
>
> I don't remember what the name of the project was and I'm sure that it
> won't work with more modern versions of Windows but it is a cool idea.

 Here's one project: http://lbw.sourceforge.net/ but I don't remember if
 this is the one I was thinking about or not.
>>>
>>> Here's another: http://atratus.org/
>>>
>>> Quoting their page "Atratus is a Windows program that can run unmodified
>>> Linux binaries."  ... "Atratus can load ELF format executables created
>>> with gcc under Linux run them on a Windows system without a CPU emulator
>>> or virtual machine".
>>>
>>> Haven't used it, but it does sound interesting, and its currently being
>>> developed (version 0.10).
>>
>> Interesting.  That website mentions LINE which, I think is the project I
>> was struggling to recall.
>
>Yeah, I was just going to mention LINE.  I don't know why I can remember
>the name of such an obscure (although very interesting!) project and not
>the name of people I just met. ;-)

Don't feel bad about it Harry.  It happens to all of us.

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

gcc4.7.2 cc1 error while loading shared libraries

[Arthur Tu]

$ gcc-4 --version
gcc-4 (GCC) 4.7.2

$ gcc-3 --version
gcc-3 (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)

$ gcc-4 helloWorld.c
/usr/lib/gcc/i686-pc-cygwin/4.7.2/cc1.exe: error while loading shared 
libraries: ?: cannot open shared object file: No such file or directory


$ gcc-3 helloWorld.c
*(success)

$ cygcheck -c|grep gcc
gcc  3.4.4-999OK
gcc-core 3.4.4-999OK
gcc-g++  3.4.4-999OK
gcc-mingw-core   20050522-3   OK
gcc-mingw-g++20050522-3   OK
gcc4 4.7.2-2  OK
gcc4-core4.7.2-2  OK
gcc4-g++ 4.7.2-2  OK
libgcc1  4.7.2-2  OK
mingw64-i686-gcc-core4.5.3-6  OK
mingw64-x86_64-gcc-core  4.5.3-6  OK



--
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.7.2 cc1 error while loading shared libraries

[Arthur Tu]

I found this http://cygwin.com/ml/cygwin/2010-10/msg00063.html.

And call cc1.exe from windows native console.

It reported that cygwin1.dll is missing.

However, cygwin1.dll do exist in /bin/, and $CYGWIN/bin/ is in my 
windows path.


On 6/19/2013 1:40 PM, Arthur Tu wrote:

$ gcc-4 --version
gcc-4 (GCC) 4.7.2

$ gcc-3 --version
gcc-3 (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)

$ gcc-4 helloWorld.c
/usr/lib/gcc/i686-pc-cygwin/4.7.2/cc1.exe: error while loading shared 
libraries: ?: cannot open shared object file: No such file or directory


$ gcc-3 helloWorld.c
*(success)

$ cygcheck -c|grep gcc
gcc  3.4.4-999OK
gcc-core 3.4.4-999OK
gcc-g++  3.4.4-999OK
gcc-mingw-core   20050522-3   OK
gcc-mingw-g++20050522-3   OK
gcc4 4.7.2-2  OK
gcc4-core4.7.2-2  OK
gcc4-g++ 4.7.2-2  OK
libgcc1  4.7.2-2  OK
mingw64-i686-gcc-core4.5.3-6  OK
mingw64-x86_64-gcc-core  4.5.3-6  OK





--
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.7.2 cc1 error while loading shared libraries

[Yaakov (Cygwin/X)]

On 2013-06-19 00:40, Arthur Tu wrote:

$ gcc-4 --version
gcc-4 (GCC) 4.7.2

$ gcc-4 helloWorld.c
/usr/lib/gcc/i686-pc-cygwin/4.7.2/cc1.exe: error while loading shared
libraries: ?: cannot open shared object file: No such file or directory


For now, this version of gcc requires test versions of most of its 
dependencies.  You need to either install those as well, or temporarily 
downgrade to 4.5.3 until 4.7.3 is stabilized (should be a matter of days).



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: gcc4.7.2 cc1 error while loading shared libraries

[Arthur Tu]

Thanks

On 6/19/2013 2:01 PM, Yaakov (Cygwin/X) wrote:

On 2013-06-19 00:40, Arthur Tu wrote:

$ gcc-4 --version
gcc-4 (GCC) 4.7.2

$ gcc-4 helloWorld.c
/usr/lib/gcc/i686-pc-cygwin/4.7.2/cc1.exe: error while loading shared
libraries: ?: cannot open shared object file: No such file or directory


For now, this version of gcc requires test versions of most of its 
dependencies.  You need to either install those as well, or 
temporarily downgrade to 4.5.3 until 4.7.3 is stabilized (should be a 
matter of days).



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




--
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: UNC and POSIX paths

[Fedin Pavel]

 Hello!

> > If we do consider this, I think we should take a step back and think
> > about revamping path handling to allow hooks for things like /dev,
> > /proc, /cygdrive rather than having to special case them.
> 
> SHTDI, as you said... But it'd be interesting advancement in /etc/fstab
> evolution.

 You mean implement complete VFS ? Would be extremely interesting. Would be
very cool to be able to build FUSE backends. This way we could access
various filesystems, not supported by Windows. Or, if we are BSDish enough,
we could take BSD filesystem modules...

 P.S. I know about Dokan project (http://dokan-dev.net/en/about/), but at
least on my machine it didn't work, simply crashed. Additionally, i'm not
sure if i can take source code of FUSE filesystem and build it for Dokan.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia



--
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: Adding MSYS functionality to Cygwin

[Алексей Павлов]

2013/6/19 Christopher Faylor wrote:
> On Tue, Jun 18, 2013 at 04:04:06PM -0600, Warren Young wrote:
>>On 6/18/2013 13:30, ??? ?? wrote:
>>> 2013/6/18 Warren Young :
 On 6/18/2013 12:40, ??? ?? wrote:
>
> 1. The correct definition of executables belonging to Cygwin DLL.

 Can you give an example of what you mean here?

>>> All cygwin applications depends on cygwin1.dll. We need to translate
>>> arguments only for non-cygwin applications.
>>
>>It would be possible, though somewhat evil, for Cygwin's exec()
>>implementation to peek at the DLL dependency list of a program before
>>starting it, and from that infer whether it should automatically
>>translate paths.
>
> Cygwin already does this.  It detects whether the program it is about
> to run uses the Cygwin DLL and, if not, makes decisions on how to
> handle exec.  It would be relatively easy to extend this.
>

Thanks for the point Christopher.
Today I investigate in this direction and find that logic works well
except one line in spawn.cc that I think can be fixed without break
anything.

Index: cygwin/spawn.cc
===
RCS file: /cvs/src/src/winsup/cygwin/spawn.cc,v
retrieving revision 1.345
diff -u -p -r1.345 spawn.cc
--- cygwin/spawn.cc 3 May 2013 19:39:01 - 1.345
+++ cygwin/spawn.cc 19 Jun 2013 05:53:36 -
@@ -406,7 +406,7 @@ child_info_spawn::worker (const char *pr
}
else
{
- if (wascygexec)
+ if (real_path.iscygexec ())
newargv.dup_all ();
else if (!one_line.fromargv (newargv, real_path.get_win32 (),
real_path.iscygexec ()))


Regards,
Alexey.

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