Re: f951: fatal error: can’t open /tmp/ccKB9p5g.s for writing: No such file or directory

[marco atzeri]

Il 6/17/2013 8:57 AM, Eliza Tkacz RIK ha scritto:

Sorry but I am not sure if I verify permissions properly.
I have created a text file mytxt.txt in /tmp and then
cd ..
ls -l tmp/

and the output is

-rw-r--r-- 1 user_name None 6 06-17 08:53 mytxt.txt




try
ls -l / | grep tmp

an followup on the cygwin mailing lsit

Regards

--
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: perl-Text-CSV-1.32-1

[David Stacey]

Version 1.32-1 of perl-Text-CSV has been uploaded.

CHANGE LOG
==

https://raw.github.com/makamaka/Text-CSV/1.21/Changes

1.32
- fix t/rt71_pp.t

1.31  Thu Jun 13 14:06:49 2013
- fix handling UTF8 in parse method.
- fix getline with allow_loose_quotes (rt#83705)
- add allow_unquoted_escape
- fix parsing escapted sep char (found in Text::CSV_XS rt#81295)

* TODO: Updating documents and adding diag_verbose in the next
version

1.30  Tue Jun 11 00:06:02 2013
- catch up Text::CSV_XS 0.99
(except for diag_verbose and allow_unquoted_escape)


DESCRIPTION
===

Text::CSV provides facilities for the composition and decomposition of
comma-separated values using Text::CSV_XS or its pure Perl version.

An instance of the Text::CSV class can combine fields into a CSV string
and parse a CSV string into fields.

The module accepts either strings or files as input and can utilize any
user-specified characters as delimiters, separators, and escapes so it
is perhaps better called ASV (anything separated values) rather than
just CSV.


CPAN


http://search.cpan.org/~makamaka/Text-CSV-1.32/lib/Text/CSV.pm


Cheers,

Dave.



If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) 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@cygwin.com

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

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

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

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

[ANNOUNCEMENT] Updated: perl-Text-CSV_XS-1.00-1

[David Stacey]

Version 1.00-1 of perl-Text-CSV_XS has been uploaded.

CHANGE LOG
==

1.00- 2013-06-13, H.Merijn Brand
* Fix automatic UTF-8 in getline/parse for SV's with \0

0.99- 2013-06-05, H.Merijn Brand
* Documents return value of bind_columns without arguments
* Fix automatic UTF-8 in getline/parse


DESCRIPTION
===

Text::CSV_XS provides facilities for the composition and decomposition
of comma-separated values. An instance of the Text::CSV_XS class will
combine fields into a CSV string and parse a CSV string into fields.

The module accepts either strings or files as input and support the use
of user-specified characters for delimiters, separators, and escapes.


CPAN


http://search.cpan.org/~hmbrand/Text-CSV_XS-1.00/CSV_XS.pm


Cheers,

Dave.



If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) 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@cygwin.com

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

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

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

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

Re: f951: fatal error: can’t open /tmp/ccKB9p5g.s for writing: No such file or directory

[Eliza Tkacz RIK]

With the command

ls -l / | grep tmp

I have

drwxrwxrwt+  1 user_name None  0 06-17 08:53 tmp

- Oryginalna wiadomość -
Il 6/14/2013 4:09 PM, Eliza Tkacz RIK ha scritto:
> Hello,
>
> After installing the package OpenSSH I am not able to compile any fortran 
> code using gfortran command.
> The compilation is terminated with:
>
> f951: fatal error: can’t open /tmp/.s for writing: No such file or 
> directory

what are the permission of /tmp ?



>
>  stands for for some numbers and letters, which differ from one 
> compilation to another.
> Before this last installation gfortran compilation has been warking fine.
>
> You will find attached the cygcheck.out file, where I changed only user name 
> and some system keys.
>
> Can anyone offer advice?
> Thanks in advance,
> E.T.
>


--
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: Invalid link on acronym page

[Corinna Vinschen]

On Jun 16 14:50, Earnie Boyd wrote:
> The link to the list of Big List Of Dodgy Apps is invalid and no
> longer directs correctly.
> 
> http://cygwin.com/faq/faq.using.html#faq.using.bloda
> 
> should become
> 
> http://cygwin.com/faq/faq.html#faq.using.bloda

Thanks for the hint.  There was another one of these in the User's
Guide.  I fixed them both.


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

[Frank Fesevur]

2013/6/17 Shaun Fielder:
> We're so used to vi === vim [fully featured] on Cygwin. At the very least -
> when the full "vim" package is installed 'vi' should use it.
> At the moment, I'm having to get everyone here to uninstall vim-minimal and
> manually setup a sym-link (or alias) to get back to the behaviour they've
> always had.

I have typed "vi" to start the editor for over 25 years now, so it
annoys me as well.
But does uninstalling vim-minimal help? It is in Base. I guess it
keeps coming back.

This all happened when vim-minimal was introduced and at the same
moment Yaakov stopped using alternatives:
http://cygwin.com/ml/cygwin/2013-05/msg00163.html

The workaround he suggest is an alias and he created a patch to have
vim-minimal use virc-files. He is looking into it a bit further.
http://cygwin.com/ml/cygwin/2013-06/msg00273.html

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

[Andrew Schulman]

> > Do we have any idea whether the problem is with mintty or with screen?
> 
> I observed the same behaviour as the OP, but also reproduced it in
> rxvt and xterm, so not a mintty issue. Since it works in a console,
> the Cygwin pty layer has to be the main suspect, unless screen has
> specfic code for Cygwin consoles or ptys?

I don't think so, but there's one big, crufty old patch that I had to use to get
screen to run a few years ago.

The version of screen that we're using now in Cygwin, 4.0.3, is about 8 years
old.  There haven't been any official new releases since then, but development
has continued and there have been a lot of improvements.  I'm in the process of
building an updated package from the latest git, and that version appears not to
need any of the patches I used to have to use to get screen to compile and run
in Cygwin.

So, I suggest that we wait until the new screen test release comes out, within a
few days, and see if that fixes the problem.


--
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: getclip and cygutils and cygcheck

[Corinna Vinschen]

On Jun 14 23:15, Jeremy Hetzler wrote:
> On Fri, Jun 14, 2013 at 5:15 AM, Corinna Vinschen wrote:
> 
> > What's that size?  I'm not aware of any size restriction in the current
> > /dev/clipboard code.  Well, there's an allocation when writing to the
> > clipboard, but it's only restricted by the size of the largest available
> > memory block in the process VM, in theory.
> 
> After some testing, the limit seems to be 64k. It only happens when
> reading data that was copied to the clipboard by a Windows program (in
> this case Excel).
> 
> Steps:
> - Open attached file in Excel
> - Ctrl-a to select all, ctrl-c to copy to clipboard
> - Then:
> 
> 582 $ getclip >out.gc
> 
> 583 $ cat /dev/clipboard >out.cat
> cat: /dev/clipboard: Bad address
> 
> 584 $ wc /dev/clipboard
> wc: /dev/clipboard: Bad address
> 400   13526   65536 /dev/clipboard
> 
> 585 $ ls -la out*
> -rw-r--r--+ 1 jhetzler Domain Users 65536 Jun 14 23:03 out.cat
> -rw-r--r--+ 1 jhetzler Domain Users 73922 Jun 14 23:03 out.gc
> 
> This is 1.7.20 on 64-bit Windows 7 and Excel 2013.
> 
> Does that help?

Yes, thank you.  There was an ill-conceived check for the last character
in the buffer being a high surrogate UTF-16 character.  It worked only
if the clipboard content was small enough to fit into a single read of
the application.  If it was too big, and the application had to call
read again to fetch more from the clipboard, it tried to read the
character beyond the array boundary.  I fixed that in CVS.  I'll probably
create a new developer snapshot and a 64 bit test version later today.


Thanks,
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: get_myaddress error with nfsd

[Corinna Vinschen]

On Jun 14 13:16, Jazz wrote:
> Another problem occurred. Both services mountd and nfsd start, but after a
> while they stop.
> 
> mountd.log says:
> Cannot register service: RPC: Timed out
> mountd[8860] 06/14/113 21:57 rpcmisc.c 99 : unable to register (mountd, 1,
> udp).
> 
> And nfsd.log says:
> Cannot register service: RPC: Timed out
> nfsd[6096] 06/14/113 21:56 rpcmisc.c 99 : unable to register (nfsd, 2, udp).

Define "after a while".  I can't reproduce this.  In my case both
services run as long as I don't kill them.


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: [Fix] Problems with latest version of the ocaml package

[Damien Doligez]

Hello,

On 2013-06-15, at 09:45, 0b1kn00b wrote:

> It's placing the library files in /lib but libdir is configured to /usr/lib,
> although in the patch file in the source, there are /usr/lib prefixed files.

Are you sure? I re-checked the tar files and they have everything in
/usr/{bin,lib,share}. I don't see how setup could put them in /lib.

-- Damien


--
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: [ANNOUNCEMENT] Updated: bison-2.7.1-1

[Shaun Fielder]

That was quick. Thanks!

Shaun



--
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: [GOLDSTAR] Re: [PATCH] Check for existence of the path before processing '..'

[Fedin Pavel]

 Hello!
 How can i contact you in private ? The address specified in messages can be 
used only within the list, and the server forces me to cc: to the public.

> Btw., Fedin, even if I let this go in under the trivial patch rule, it
> would be very nice if you could fill out the Cygwin copyright
> assignment form http://cygwin.com/assign.txt and send it to the given
> address.
> This allows you to provide any length of patch in future.

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: Native symlinks troubles

[Corinna Vinschen]

On Jun 17 08:43, Алексей Павлов wrote:
> This simple example illustrate problem with using native symlinks.
> 
> $ export CYGWIN=winsymlinks:nativestrict
> 
> $ mkdir bld && mkdir source && touch source/srcfile && ln -s
> ../source/srcfile bld/bldfile
> 
> $ ls -l bld
> total 0
> lrwxrwxrwx 1 alexey None 10 Jun 17 08:29 bldfile -> ce/srcfile

Thanks for the report.  I applied a patch which should fix this issue.

I'm just uploading a new developer snapshot 2013-06-17 to
http://cygwin.com/snapshots/, as well as a new 64 bit Cygwin test
release 1.7.21-4.  Please give one of them a try.


Thanks,
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: [GOLDSTAR] Re: [PATCH] Check for existence of the path before processing '..'

[Corinna Vinschen]

On Jun 17 16:37, Fedin Pavel wrote:
>  Hello!
>  How can i contact you in private ? The address specified in messages
>  can be used only within the list, and the server forces me to cc: to
>  the public.

That's deliberate, of course ;)

If it's something which requires privacy you can try the address in my
Cygwin ChangeLog entries.  Just if you want to send me your assignment,
it's of no use.  You have to send it via snail mail to the address given
in the assign.txt file itself.


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: getclip and cygutils and cygcheck

[Corinna Vinschen]

On Jun 17 12:16, Corinna Vinschen wrote:
> On Jun 14 23:15, Jeremy Hetzler wrote:
> > After some testing, the limit seems to be 64k. It only happens when
> > reading data that was copied to the clipboard by a Windows program (in
> > this case Excel).
> > [...]
> > 583 $ cat /dev/clipboard >out.cat
> > cat: /dev/clipboard: Bad address
> > [...]
> > Does that help?
> 
> Yes, thank you.  There was an ill-conceived check for the last character
> in the buffer being a high surrogate UTF-16 character.  It worked only
> if the clipboard content was small enough to fit into a single read of
> the application.  If it was too big, and the application had to call
> read again to fetch more from the clipboard, it tried to read the
> character beyond the array boundary.  I fixed that in CVS.  I'll probably
> create a new developer snapshot and a 64 bit test version later today.

FYI, I'm just uploading a new developer snapshot 2013-06-17 to
http://cygwin.com/snapshots/, as well as a new 64 bit Cygwin test
release 1.7.21-4.  Please give one of them a try.


Thanks,
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: [Fix] Problems with latest version of the ocaml package

[0b1kn00b]

I've really no experience with cygwin packages, I saw afterward that the
windows directory /lib is the cygwin directory /usr/lib and threw my toys
out the pram.

Something somewhere is busted and it gives errors of the same form as the
original post, beyond that, I really can't say atm.

regards,
Laurence

On Mon, Jun 17, 2013 at 1:27 PM, Damien Doligez [via Cygwin] <
ml-node+s1069669n99702...@n5.nabble.com> wrote:

> Hello,
>
> On 2013-06-15, at 09:45, 0b1kn00b wrote:
>
> > It's placing the library files in /lib but libdir is configured to
> /usr/lib,
> > although in the patch file in the source, there are /usr/lib prefixed
> files.
>
> Are you sure? I re-checked the tar files and they have everything in
> /usr/{bin,lib,share}. I don't see how setup could put them in /lib.
>
> -- Damien
>
>
> --
> 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
>
>
>
> --
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://cygwin.1069669.n5.nabble.com/Problems-with-latest-version-of-the-ocaml-package-tp99376p99702.html
>  To unsubscribe from Problems with latest version of the ocaml package, click
> here
> .
> NAML
>




--
View this message in context: 
http://cygwin.1069669.n5.nabble.com/Problems-with-latest-version-of-the-ocaml-package-tp99376p99709.html
Sent from the Cygwin list mailing list archive at Nabble.com.

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

Cross-compiling Linux kernel

[Fedin Pavel]

 Hello!

 In order to cross-compile Linux kernel i have to patch host-side tools a
little bit. Current problems are:
 1. Cygwin misses linux/types.h
 2. Cygwin defines the following ELF macros according to host machine:
ELF_ST_BIND, ELF_ST_TYPE, ELF_R_SYM, ELF_R_TYPE

 What about improving Linux compatibility ? We could have own version of
linux/types.h (for __u8. __u16, etc), and omit ELF definitions. AFAIK they
are not used anywhere, they are just inherited from BSD.
 At the other hand, i believe the same problem will happen if i try to
cross-compile Linux kernel under BSD. And Cygwin is BSD-style system...

 Just decided to drop this in as one more "what if...".

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

UNC and POSIX paths

[Fedin Pavel]

 Hello!

 I decided to pay attention to one more problem. Lots of not very well
written configure scripts and makefiles like to access things like
'//usr/bin'. Under Cygwin this causes problem because Cygwin treats '//' in
Windows-style as access to network shares.
 What if we change this ? We could have a mount entry, something like '/unc'
(or /smb, /net, whatever) and access it like '/smb/computername/sharename'.
I think this would improve POSIX compatibility a lot.

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: f951: fatal error: can’t open /tmp/ccKB9p5g.s for writing: No such file or directory

[Andrey Repin]

Greetings, marco atzeri!

>> Sorry but I am not sure if I verify permissions properly.
>> I have created a text file mytxt.txt in /tmp and then
>> cd ..
>> ls -l tmp/
>>
>> and the output is
>>
>> -rw-r--r-- 1 user_name None 6 06-17 08:53 mytxt.txt
>>
>>

> try
> ls -l / | grep tmp

I wonder, would that be different from

ls -ld /tmp

?

Is there any caveats under cygwin?


--
WBR,
Andrey Repin (anrdae...@freemail.ru) 17.06.2013, <17:35>

Sorry for my terrible english...

Re: UNC and POSIX paths

[Andrew DeFaria]

On 06/17/2013 06:36 AM, Fedin Pavel wrote:

  Hello!

  I decided to pay attention to one more problem. Lots of not very well
written configure scripts and makefiles like to access things like
'//usr/bin'. Under Cygwin this causes problem because Cygwin treats '//' in
Windows-style as access to network shares.
  What if we change this ? We could have a mount entry, something like '/unc'
(or /smb, /net, whatever) and access it like '/smb/computername/sharename'.
I think this would improve POSIX compatibility a lot.
Why not simply fix the "not very well written configure scripts and 
makefiles" instead? BTW I've never come across a single one of those. 
Where are you getting yours?

--
Andrew DeFaria 
Very funny Scotty - now beam down my clothes.


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

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

[Christopher Faylor]

On Mon, Jun 17, 2013 at 06:08:27AM -0400, Andrew Schulman wrote:
>> > Do we have any idea whether the problem is with mintty or with screen?
>> 
>> I observed the same behaviour as the OP, but also reproduced it in
>> rxvt and xterm, so not a mintty issue. Since it works in a console,
>> the Cygwin pty layer has to be the main suspect, unless screen has
>> specfic code for Cygwin consoles or ptys?
>
>I don't think so, but there's one big, crufty old patch that I had to use to 
>get
>screen to run a few years ago.
>
>The version of screen that we're using now in Cygwin, 4.0.3, is about 8 years
>old.  There haven't been any official new releases since then, but development
>has continued and there have been a lot of improvements.  I'm in the process of
>building an updated package from the latest git, and that version appears not 
>to
>need any of the patches I used to have to use to get screen to compile and run
>in Cygwin.
>
>So, I suggest that we wait until the new screen test release comes out, within 
>a
>few days, and see if that fixes the problem.

I looked at this briefly over the weekend and saw a problem in Cygwin's
pty handling code.  I don't know exactly what the problem is yet but there
is something not quite right there.  Something is closing a windows handle
and that's causing a SIGHUP to be sent to the pty owner.  That's not right.

I'll fix this problem eventually but it will be interesting to see if a
newer screen behaves any better.

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

git svn fork() problems on cygwin 1.7.20

[Mikko Rapeli]

Hi,

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

Sometimes these go away after reboot and rebaseall. These happen mostly on
my jenkins build server running 64bit Windows 7, especially after Windows
security updates, but another 32bit machine seems to be ok.

-Mikko

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

  0 [main] perl 4208 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  1 [main] perl 4216 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  1 [main] perl 5984 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  1 [main] perl 5016 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  0 [main] perl 2248 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  0 [main] perl 456 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  1 [main] perl 5144 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  1 [main] perl 2988 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  1 [main] perl 5624 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  0 [main] perl 2320 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  0 [main] perl 5800 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  0 [main] perl 4304 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  1 [main] perl 1992 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  1 [main] perl 1792 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  0 [main] perl 3948 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  0 [main] perl 5924 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  0 [main] perl 3584 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  0 [main] perl 5360 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  1 [main] perl 3664 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  0 [main] perl 5208 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  1 [main] perl 6140 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  1 [main] perl 3092 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  0 [main] perl 4652 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  0 [main] perl 4256 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  1 [main] perl 2160 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  0 [main] perl 5808 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  0 [main] perl 4380 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  0 [main] perl 1516 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  0 [main] perl 5148 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  0 [main] perl 5448 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  0 [main] perl 4320 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  0 [main] perl 5788 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  0 [main] perl 412 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  0 [main] perl 5480 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  0 [main] perl 4644 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  0 [main] perl 1252 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  7 [main] perl 3624 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already occupied

  0 [main] perl 1264 child_info_fork::abort: address space needed by 
'_Client.dll' (0x52) is already

Re: UNC and POSIX paths

[Christopher Faylor]

On Mon, Jun 17, 2013 at 05:36:42PM +0400, Fedin Pavel wrote:
> Hello!
>
> I decided to pay attention to one more problem. Lots of not very well
>written configure scripts and makefiles like to access things like
>'//usr/bin'. Under Cygwin this causes problem because Cygwin treats '//' in
>Windows-style as access to network shares.
> What if we change this ? We could have a mount entry, something like '/unc'
>(or /smb, /net, whatever) and access it like '/smb/computername/sharename'.
>I think this would improve POSIX compatibility a lot.

To rephrase what you're asking: "How about if we change Cygwin's
path-handling to deviate from 15 years of established behavior?"

Sorry, not going to happen.  We're within our rights to treat //
differently and, although it doesn't give us complete Linux
compatibility, this is one case where the utility outweighs the
pedantry.

That said, I guess we *could* add something like the above and only use
it when it was specifically mounted but that would be a fair amount of
work.

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

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.

Somehow PATH is related to this but maybe it's just a side effect.

-Mikko

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

[Dan Kegel]

On Mon, Jun 17, 2013 at 6:36 AM, Fedin Pavel wrote:
>  I decided to pay attention to one more problem. Lots of not very well
> written configure scripts and makefiles like to access things like
> '//usr/bin'. Under Cygwin this causes problem because Cygwin treats '//' in
> Windows-style as access to network shares.
>  What if we change this ? We could have a mount entry, something like '/unc'
> (or /smb, /net, whatever) and access it like '/smb/computername/sharename'.
> I think this would improve POSIX compatibility a lot.

It'd be interesting to find out how many such scripts there are.
Have you tried looking for them, e.g. by hooking open()
( 
http://stackoverflow.com/questions/880263/how-can-i-detect-file-accesses-in-linux
)
and logging them while doing something big (like rebuilding a linux distro,
or building all your company's linux software)?
- 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: UNC and POSIX paths

[gmt]

On Mon, 17 Jun 2013, at 06:57, Andrew DeFaria thusly quipped:

> On 06/17/2013 06:36 AM, Fedin Pavel wrote:
>>   Hello!
>>   
>>   I decided to pay attention to one more problem. Lots of not very
>> well written configure scripts and makefiles like to access things
>> like '//usr/bin'. Under Cygwin this causes problem because Cygwin
>> treats '//' in Windows-style as access to network shares.
>>   What if we change this ? We could have a mount entry, something like
'/unc'
>> (or /smb, /net, whatever) and access it like
'/smb/computername/sharename'.
>> I think this would improve POSIX compatibility a lot.
> Why not simply fix the "not very well written configure scripts and
makefiles"
> instead? BTW I've never come across a single one of those.
> Where are you getting yours?

Can't answer this offhand (aware you didn't ask me :P) but, under the
misguidance of PM's like Gentoo(portage) and rpm(build), when combined with
poorly and/or belligerently written packaging scripts, this can happen
incessantly.  But that mostly only comes up when building Frankencygwins.
Sometimes you can fix it by forcing something like --prefix=///usr/local.

A CYGWIN env flag to disable UNC paths, or graft them somewhere other than
//, or an fstab-hack--basically anything allowing one to turn this feature
off--would be a moderate blessing for a small number (greater than or equal
to one) of people, but SHTDI, and this is endlessly proposed and
insta-shot-down.

At least one "merit-based" argument does recommend against implementing this
-- a great many configure scripts test for whether // == /, which means
packages could break if packagers happened to build while using the proposed
anti-feature-feature (the inevitable response being, "shouldn't those
packages just fix their broken configure scripts"? :P)

-gmt



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

[Adam Dinwoodie]

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.
> 
> Somehow PATH is related to this but maybe it's just a side effect.

Two possible guesses: you've multiple cygwin1.dll files in your PATH, or you
just need to rebase (run `rebaseall` from a shell and follow the instructions).
If that doesn't help, follow the problem reporting guidelines:

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

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

[Corinna Vinschen]

On Jun 17 17:24, Fedin Pavel wrote:
>  Hello!
> 
>  In order to cross-compile Linux kernel i have to patch host-side tools a
> little bit. Current problems are:
>  1. Cygwin misses linux/types.h
>  2. Cygwin defines the following ELF macros according to host machine:
> ELF_ST_BIND, ELF_ST_TYPE, ELF_R_SYM, ELF_R_TYPE
> 
>  What about improving Linux compatibility ? We could have own version of
> linux/types.h (for __u8. __u16, etc), and omit ELF definitions. AFAIK they
> are not used anywhere, they are just inherited from BSD.
>  At the other hand, i believe the same problem will happen if i try to
> cross-compile Linux kernel under BSD. And Cygwin is BSD-style system...

I have no opinion on the ELF definition issue, but just adding a
linux system header looks pretty wrong to me.


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: Windows 8 permissions broken after a reboot

[Simon Majou]

Of course, I completely forgot the "Run as admin" option ...

After another small issue with the cyg_server account (I had to create
a new account cyg_server2), now it works.

Thanks a lot Larry !

--
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 17:36, Fedin Pavel wrote:
>  Hello!
> 
>  I decided to pay attention to one more problem. Lots of not very well
> written configure scripts and makefiles like to access things like
> '//usr/bin'. Under Cygwin this causes problem because Cygwin treats '//' in
> Windows-style as access to network shares.
>  What if we change this ? We could have a mount entry, something like '/unc'
> (or /smb, /net, whatever) and access it like '/smb/computername/sharename'.
> I think this would improve POSIX compatibility a lot.

Maybe there has been said enough in this thread already, but I have
to add this:  Cygwin's behaviour *is* POSIX compatible.  Consider
this excerpt from SUSv4 Base specifications, section 4.12 "Pathname
Resolution" (1):

  A pathname consisting of a single  shall resolve to the root
  directory of the process. [...] If a pathname begins with two
  successive  characters, the first component following the
  leading  characters may be interpreted in an
  implementation-defined manner, although more than two leading 
  characters shall be treated as a single  character.


Corinna

(1) http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html


-- 
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: Building a new package help

[wynfield]

Larry,
  thanks.  Your advice, was on the spot and got me closer to making a 
succsessful build.  The other problem I found was that on cygwin, an additional 
header file called  "zconf.h" is required and has to be included along with the 
zlib.h file.  It builds now.

Thanks for your assistance. 

Larry Hall (Cygwin) 
>
> > The last (I believe) problem is the linker can't find zlib to link to.
> > Below is what Makefile outputs when the error occurs.
> 
> Do you have the zlib-devel package installed?  Does '-lz' occur in
> the makefile and in the right order?  Remember, library dependencies
> on Windows is linear.
> 
> -- 
> Larry
> 

--
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: Building a new package help

[wynfield]

Larry,
  thanks.  Your advice, was on the spot and got me closer to making a 
succsessful build.  The other problem I found was that on cygwin, an additional 
header file called  "zconf.h" is required and has to be included along with the 
zlib.h file.  It builds now.

Thanks for your assistance. 

Larry Hall (Cygwin) <...delete e-mail addr...>
> On 6/16/2013 12:38 AM, 
> > The last (I believe) problem is the linker can't find zlib to link to.
> > Below is what Makefile outputs when the error occurs.
> 
> Do you have the zlib-devel package installed?  Does '-lz' occur in
> the makefile and in the right order?  Remember, library dependencies
> on Windows is linear.
> 
> -- 
> Larry
> 

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

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

[Andrew Schulman]

> On Mon, Jun 17, 2013 at 06:08:27AM -0400, Andrew Schulman wrote:
> >> > Do we have any idea whether the problem is with mintty or with screen?
> >> 
> >> I observed the same behaviour as the OP, but also reproduced it in
> >> rxvt and xterm, so not a mintty issue. Since it works in a console,
> >> the Cygwin pty layer has to be the main suspect, unless screen has
> >> specfic code for Cygwin consoles or ptys?
> >
> >I don't think so, but there's one big, crufty old patch that I had to use to 
> >get
> >screen to run a few years ago.
> >
> >The version of screen that we're using now in Cygwin, 4.0.3, is about 8 years
> >old.  There haven't been any official new releases since then, but 
> >development
> >has continued and there have been a lot of improvements.  I'm in the process 
> >of
> >building an updated package from the latest git, and that version appears 
> >not to
> >need any of the patches I used to have to use to get screen to compile and 
> >run
> >in Cygwin.
> >
> >So, I suggest that we wait until the new screen test release comes out, 
> >within a
> >few days, and see if that fixes the problem.
> 
> I looked at this briefly over the weekend and saw a problem in Cygwin's
> pty handling code.  I don't know exactly what the problem is yet but there
> is something not quite right there.  Something is closing a windows handle
> and that's causing a SIGHUP to be sent to the pty owner.  That's not right.
> 
> I'll fix this problem eventually but it will be interesting to see if a
> newer screen behaves any better.

No, I just tested it on the latest screen release, and the problem still occurs.


--
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: python-gdata-2.0.18-1

[Chris Sutcliffe]

Version 2.0.18-1 of python-gdata has been uploaded.

python-gdata is the Google Data Python Client Library.  The Google
Data Python Client Library provides a library and source code that
make it easy to access data through Google Data APIs.

Changes are listed below.

 *** 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://sourceware.org/lists.html#unsubscribe-simple

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

=== 2.0.18 ===
1173[tip] 93c436da2d19 2013-06-14 07:21 -0700 afshar
Remove unused script.

1172 e692050ec194 2013-06-14 07:20 -0700 afshar
Updated docs.

1171 159874713088 2013-06-14 07:20 -0700 afshar
Bumped version.

1170 7b4e3c22e83c 2013-06-07 15:52 +0200 burcud
Adding missing unit attributes for unit picing elements.

1169 ad8ee900dda5 2013-06-06 19:01 +0200 burcud
Fixing identifier_exists attribute for product items.

1168 d6ce8dc4970a 2013-06-06 17:53 +0200 burcud
Fixing multipack attribute.

1167 b87779918c90 2013-06-06 15:10 +0200 burcud
Adding new product spec attributes.

1166 624d33ad26f2 2013-02-11 12:47 -0800 rkubiak
Update Sites Python API to allow page creation from a template

1165 ecb1d49b5fbe 2013-01-07 11:29 -0800 dhermes
Adding an OAuth2Token subclass which can interact with google-api-python-client.

1164 f76c53eaf151 2012-11-20 16:09 +0100 burcud
Modifying Content API for Shopping client to use schema projection.

1163 a8c25010b8b7 2012-08-27 13:50 -0700 dhermes
Adding in ability to change Content for Shopping base URI via a kwarg
for client constructor. (Fixes 6479060).

1162 c5d57eff0ef4 2012-08-15 08:31 -0700 dhermes
Adding paid clicks to Content API performance datapoint. (Issue 6443130)

1161 71971b013563 2012-08-06 15:20 -0700 dhermes
Adding support for adwords_accounts settings element in
managedaccounts feed of Content API. (6443092)

1160 cf0208e89433 2012-07-30 09:53 -0700 dhermes
Changing OAuth2 Authorization Header lead in from OAuth to Bearer (per
http://goo.gl/QDiLZ). (issue 6455060)

1159 3b021605570f 2012-07-12 18:14 -0700 dhermes
Adding missing name XML attribute to gdata.contentforshopping.data.Group.

1158 524fc2b2e821 2012-06-19 08:43 -0700 dhermes
Renaming classes for inventory feed of Content API. (Issue 6296085)

1157 32c0cb313b2e 2012-06-14 15:36 -0700 dhermes
Updating offline URI for OAuth2 and explicity specifying
approval_prompt as a kw arg. (Issue 6296072)

1156 f7593ae5d035 2012-06-14 15:35 -0700 dhermes
Added individual get for ManagedAccounts, functionality for paging and
changed to correct endpoint. (issue 6304076)

1155 723e577ada7b 2012-06-14 13:53 -0700 dhermes
Adding support for Local Products feed in Content API. (Issue 6305091)

1154 75ee2830ca74 2012-06-13 12:48 -0700 dhermes
Adding support for wrong open search version hack on other ContentAPI
Feed classes. (Issue 6296071)

1153 f783c64b953f 2012-06-13 10:07 -0700 dhermes
Adding support for Data Quality Feed of Content API for Shopping.
(Issue 6295074)

1152 4cc916619658 2012-06-13 09:07 -0700 dhermes
Adding back accidentally removed code from commit
c92bc870e3a4363bed2732d50d782189407af7ac.

1151 c92bc870e3a4 2012-06-13 09:01 -0700 dhermes
Adding support for Content API Users Feed. (Issue 6295071)

1150 0dcb1f3aff81 2012-06-12 17:25 -0700 dhermes
Adding custom id parser for Content API errors. (issue 6306073)

1149 8f11de681f03 2012-06-12 17:21 -0700 dhermes
Adding support for product status elements in app:control for content
for shopping. (Fixes 6299076)


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

[Chris J. Breisch]

On 6/17/2013 11:18 AM, Corinna Vinschen wrote:

On Jun 17 17:24, Fedin Pavel wrote:

  Hello!

  In order to cross-compile Linux kernel i have to patch host-side tools a
little bit. Current problems are:
  1. Cygwin misses linux/types.h
  2. Cygwin defines the following ELF macros according to host machine:
ELF_ST_BIND, ELF_ST_TYPE, ELF_R_SYM, ELF_R_TYPE

  What about improving Linux compatibility ? We could have own version of
linux/types.h (for __u8. __u16, etc), and omit ELF definitions. AFAIK they
are not used anywhere, they are just inherited from BSD.
  At the other hand, i believe the same problem will happen if i try to
cross-compile Linux kernel under BSD. And Cygwin is BSD-style system...

I have no opinion on the ELF definition issue, but just adding a
linux system header looks pretty wrong to me.


Corinna

There are far better ways to cross-compile the Linux kernel. I built a 
Cross Linux From Scratch system under Cygwin earlier this year. I just 
got back from vacation, though. Give me a day or so, and I'll find my 
notes on it. I believe most of them have already been posted here in the 
past, however.


Chris J. Breisch

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

[Larry Hall (Cygwin)]

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.

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

[Andrew DeFaria]

On 06/17/2013 08:12 AM, g...@malth.us wrote:

Why not simply fix the "not very well written configure scripts and
makefiles"instead? BTW I've never come across a single one of those.
Where are you getting yours?

Can't answer this offhand (aware you didn't ask me :P) but, under the
misguidance of PM's like Gentoo(portage) and rpm(build), when combined with
poorly and/or belligerently written packaging scripts, this can happen
incessantly.  But that mostly only comes up when building Frankencygwins.
Sometimes you can fix it by forcing something like --prefix=///usr/local.
I'm trying to understand the reluctance towards "fixing the problem" and 
instead the insistence on "putting a band aid on it". So in the above, 
why would you not instead do --prefix=/usr/local?

A CYGWIN env flag to disable UNC paths, or graft them somewhere other than
//, or an fstab-hack--basically anything allowing one to turn this feature
off--would be a moderate blessing for a small number (greater than or equal
to one) of people, but SHTDI, and this is endlessly proposed and
insta-shot-down.

At least one "merit-based" argument does recommend against implementing this
-- a great many configure scripts test for whether // == /, which means
packages could break if packagers happened to build while using the proposed
anti-feature-feature (the inevitable response being, "shouldn't those
packages just fix their broken configure scripts"? :P)

Yes, indeed. See above.
--
Andrew DeFaria 
If a mute swears does his mother wash his hands with soap?


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

[Achim Gratz]

Andrew DeFaria writes:
> I'm trying to understand the reluctance towards "fixing the problem"
> and instead the insistence on "putting a band aid on it". So in the
> above, why would you not instead do --prefix=/usr/local?

Because some scripts try to use

$(DESTDIR)/$(PREFIX)

rather than

$(DESTDIR)$(PREFIX)

or otherwise insist on adding a slash somewhere in the expansion of
directory paths without checking whether they are "" or "/".  While it'd
be preferable that these expansions be fixed, simply prepending a few
more slashes usually works when the system follows POSIX rules since
only "//" is special.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada


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

[gmt]

On Mon, 17 Jun 2013, at 10:07, Andrew DeFaria thusly quipped:
> On 06/17/2013 08:12 AM, g...@malth.us wrote:
>>> Why not simply fix the "not very well written configure scripts and
>>> makefiles"instead? BTW I've never come across a single one of those.
>>> Where are you getting yours?
>> Can't answer this offhand (aware you didn't ask me :P) but, under the
>> misguidance of PM's like Gentoo(portage) and rpm(build), when combined
>> with poorly and/or belligerently written packaging scripts, this can
>> happen incessantly.  But that mostly only comes up when building
>> Frankencygwins. Sometimes you can fix it by forcing something like
>> --prefix=///usr/local.

> I'm trying to understand the reluctance towards "fixing the problem" and
instead
> the insistence on "putting a band aid on it". So in the above, why would
you not
> instead do --prefix=/usr/local?

This  is indeed a band-aid in the truest sense of the metaphor.  It relies
on the specificity of POSIX's reservation of "//" for platform purposes (and
cygwin's correct implementation of same) -- unlike "//", anything matching
the regex "^///[/]*$" is, indeed, equivalent to "/".  So, as if the POSIX
"//" reservation wasn't an obscure enough fact, here is a way to /really/
impress people at cocktail parties :)

As to why not fix the upstreams committing these atrocities, it's the
obvious reason -- occasionally one encounters a large body of dense,
non-fixable-by-sed/perl, poorly commented "spaghetti" script-code that makes
"clever," deep usage of the assumption that "//" == "/".  Being able to turn
this feature off at one's option would enable them to rule out "//" as a
problem when they suspect it might be, and have the additional benefit of
not having to fix such code, in order to run it.

-gmt



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

[Tim Prince]

On 06/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 ?

I have just updated cygwin. I attach cygcheck.out

Or any suggestions for another profiling tool that actually reports times ?
Cheers,
Beau

If the gprof section of binutils is properly built and installed, it 
should satisfy the mcount reference.
It's a bit strange to make a .o with -g -pg together, particularly when 
you don't link with the same options.
FWIW, latest version of Intel VTune works with cygwin builds with -g3 
-gdwarf-2 (and of course PATH considerations).


--
Tim Prince


--
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: f951: fatal error: can’t open /tmp/ccKB9p5g.s for writing: No such file or directory

[marco atzeri]

Il 6/17/2013 3:36 PM, Andrey Repin ha scritto:

Greetings, marco atzeri!





try
ls -l / | grep tmp


I wonder, would that be different from

ls -ld /tmp

?

Is there any caveats under cygwin?


Andrey Repin


No, they are equivalent.
I was just away from my PC and I do not remember
all "ls" options by memory.

Regards
Marco



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

Re: UNC and POSIX paths

[Larry Hall (Cygwin)]

On 6/17/2013 1:54 PM, g...@malth.us wrote:

On Mon, 17 Jun 2013, at 10:07, Andrew DeFaria thusly quipped:

On 06/17/2013 08:12 AM, g...@malth.us wrote:

Why not simply fix the "not very well written configure scripts and
makefiles"instead? BTW I've never come across a single one of those.
Where are you getting yours?

Can't answer this offhand (aware you didn't ask me :P) but, under the
misguidance of PM's like Gentoo(portage) and rpm(build), when combined
with poorly and/or belligerently written packaging scripts, this can
happen incessantly.  But that mostly only comes up when building
Frankencygwins. Sometimes you can fix it by forcing something like
--prefix=///usr/local.



I'm trying to understand the reluctance towards "fixing the problem" and

instead

the insistence on "putting a band aid on it". So in the above, why would

you not

instead do --prefix=/usr/local?


This  is indeed a band-aid in the truest sense of the metaphor.  It relies
on the specificity of POSIX's reservation of "//" for platform purposes (and
cygwin's correct implementation of same) -- unlike "//", anything matching
the regex "^///[/]*$" is, indeed, equivalent to "/".  So, as if the POSIX
"//" reservation wasn't an obscure enough fact, here is a way to /really/
impress people at cocktail parties :)

As to why not fix the upstreams committing these atrocities, it's the
obvious reason -- occasionally one encounters a large body of dense,
non-fixable-by-sed/perl, poorly commented "spaghetti" script-code that makes
"clever," deep usage of the assumption that "//" == "/".  Being able to turn
this feature off at one's option would enable them to rule out "//" as a
problem when they suspect it might be, and have the additional benefit of
not having to fix such code, in order to run it.


So it's a question of convenience vs correctness.  It seems the argument
offered is that it is convenient to allow incorrect scripts.  An alternate
argument could be made that it is equally convenient to continue having
Cygwin correctly interpret '//' as it has been.  In addition, since the UNC
interpretation of paths comes for free (it's a Windows feature), it
would be pretty inconvenient to make Cygwin work otherwise.

I don't think the convenience vs correctness argument is going to inspire
someone to action. ;-)

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

cyginw64 ioperm package

[Balaji Venkataraman]

I don't see the ioperm package in Cygwin64, unless I'm not looking in
the right place. Any ideas on if/when it might become available?
Thanks.

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

[Andrew DeFaria]

On 06/17/2013 10:35 AM, Achim Gratz wrote:

Andrew DeFaria writes:

I'm trying to understand the reluctance towards "fixing the problem"
and instead the insistence on "putting a band aid on it". So in the
above, why would you not instead do --prefix=/usr/local?

Because some scripts try to use

$(DESTDIR)/$(PREFIX)

rather than

$(DESTDIR)$(PREFIX)

or otherwise insist on adding a slash somewhere in the expansion of
directory paths without checking whether they are "" or "/".  While it'd
be preferable that these expansions be fixed, simply prepending a few
more slashes usually works when the system follows POSIX rules since
only "//" is special.
I'm confused. Let me ask a different way - why not fix such scripts 
instead? That's all I'm asking.

--
Andrew DeFaria 
Copywight 1994 Elmer Fudd. All wights wesewved.


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

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

On 06/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 ?
>
> I have just updated cygwin. I attach cygcheck.out
>
> Or any suggestions for another profiling tool that actually reports times ?
> Cheers,
>   Beau
>
If the gprof section of binutils is properly built and installed, it should 
satisfy the mcount reference.
It's a bit strange to make a .o with -g -pg together, particularly when you 
don't link with the same options.
FWIW, latest version of Intel VTune works with cygwin builds with -g3
-gdwarf-2 (and of course PATH considerations).

--
Tim Prince

_

Thanks Larry and Tim,
I was not sure if -g was required as well, and tried all combinations.
May I ask if VTune works with non-MinGW compilations ? 
I looked and was not clear.
I am reluctant to change my other ygwin installations, they are required for 
other projects.
I have certainly had interaction in the past with Altera Cygwin package 
and_

Thanks Larry and Tim,
I was not sure if -g was required as well, and tried all combinations.

May I ask if VTune works with non-MinGW compilations ?  I looked and was not 
clear.

I am reluctant to change my other Cygwin installations, they are required for 
other projects.
I have certainly had problems in the past with the Altera Cygwin package and 
the XMOS one interacting, but they seem to have sorted that.
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: UNC and POSIX paths

[Andrew DeFaria]

On 06/17/2013 10:54 AM, g...@malth.us wrote:
As to why not fix the upstreams committing these atrocities, it's the 
obvious reason -- occasionally one encounters a large body of dense, 
non-fixable-by-sed/perl, poorly commented "spaghetti" script-code that 
makes "clever," deep usage of the assumption that "//" == "/". Being 
able to turn this feature off at one's option would enable them to 
rule out "//" as a problem when they suspect it might be, and have the 
additional benefit of not having to fix such code, in order to run it. 
-gmt 
If upstream code is broken it's broken. You can 1) fix it and submit it 
as a patch or 2) don't fix it and find a better solution.


Stripping off additional '/''s is not that hard a problem to solve - 
even in spaghetti code.

--
Andrew DeFaria 
I just got skylights put in my place. The people who live above me are 
furious!



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

[Feature request] Setup64.exe should respect more recent packages' version

[Vasiliy]

Could it be possible for Setup64.exe that it would not offer
downgrading packages by default if their more recent counterparts are
installed? Example of an undesirable behavior: installed is bash 4.2,
but 4.1 version is wrongly suggested, etc.

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

[Dan Kegel]

Andrew DeFaria wrote:
> I'm confused. Let me ask a different way - why not fix such scripts instead?
> That's all I'm asking.

He's probably daunted by the thought.

If he really wants to change the world here, he should
consider writing a tool that scanned for such problems,
and lobbying to get it included in some broadly used suite of checks
like lintian.
- 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: [Feature request] Setup64.exe should respect more recent packages' version

[Larry Hall (Cygwin)]

On 6/17/2013 2:54 PM, Vasiliy wrote:

Could it be possible for Setup64.exe that it would not offer
downgrading packages by default if their more recent counterparts are
installed? Example of an undesirable behavior: installed is bash 4.2,
but 4.1 version is wrongly suggested, etc.


Setup suggests downgrading only when you've install a test package.
There's nothing distinctive about 'setup.64.exe' vs 'setup.exe' in
this regard.

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

Fwd: [Feature request] Setup64.exe should respect more recent packages' version

[Vasiliy]

Ok, I understand, and, yes, it's also about setup.exe. That would be
true if the package was marked as 'a test package', aka those marked
'[test]' in setup.ini, but what if they were not? From my example bash
4.2 is not marked as [test] (I've changed 'installed.db' file
accordingly), yet setup(64) downgrades it to 4.1

Why not use two conditions instead of just one? Say, 'if package is
more recent, and not marked as [test], then do not downgrade (keep)'.

___
From: "Larry Hall (Cygwin)" 
To: cygwin at cygwin dot com
Date: Mon, 17 Jun 2013 15:01:37 -0400
Subject: Re: [Feature request] Setup64.exe should respect more recent
packages' version
References: 
Reply-to: cygwin at cygwin dot com



On 6/17/2013 2:54 PM, Vasiliy wrote:

Could it be possible for Setup64.exe that it would not offer
downgrading packages by default if their more recent counterparts are
installed? Example of an undesirable behavior: installed is bash 4.2,
but 4.1 version is wrongly suggested, etc.

Setup suggests downgrading only when you've install a test package.
There's nothing distinctive about 'setup.64.exe' vs 'setup.exe' in
this regard.

--
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: cyginw64 ioperm package

[marco atzeri]

Il 6/17/2013 8:23 PM, Balaji Venkataraman ha scritto:

I don't see the ioperm package in Cygwin64, unless I'm not looking in
the right place. Any ideas on if/when it might become available?
Thanks.



as the 32 bit package is orphaned, we need a volunteer to take over.
Are you interested ?

Marco

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

Re: Fwd: [Feature request] Setup64.exe should respect more recent packages' version

[Larry Hall (Cygwin)]

Please, no .

On 6/17/2013 3:27 PM, Vasiliy wrote:

Ok, I understand, and, yes, it's also about setup.exe. That would be
true if the package was marked as 'a test package', aka those marked
'[test]' in setup.ini, but what if they were not? From my example bash
4.2 is not marked as [test] (I've changed 'installed.db' file
accordingly), yet setup(64) downgrades it to 4.1

Why not use two conditions instead of just one? Say, 'if package is
more recent, and not marked as [test], then do not downgrade (keep)'.


That is the way it works for non-test packages.

I'm not sure what mirror you're using but on mirror.mcs.anl.gov, bash
4.1.11 is the only version available for x64.

--
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: Fwd: [Feature request] Setup64.exe should respect more recent packages' version

[marco atzeri]

Il 6/17/2013 9:27 PM, Vasiliy ha scritto:

Ok, I understand, and, yes, it's also about setup.exe. That would be
true if the package was marked as 'a test package', aka those marked
'[test]' in setup.ini, but what if they were not? From my example bash
4.2 is not marked as [test] (I've changed 'installed.db' file
accordingly), yet setup(64) downgrades it to 4.1

Why not use two conditions instead of just one? Say, 'if package is
more recent, and not marked as [test], then do not downgrade (keep)'.




0) please do NOT top post

1) installed.db have no info about test or current.
  That info is in setup.ini

2) about changing setup way of working, we need someone to write
   a patch. Please feel free to send your proposed one.
  I doubt it is on the top list of anyone else to change
  the current behaviour

Regards
Marco


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

Re: Fwd: [Feature request] Setup64.exe should respect more recent packages' version

[Vasiliy]

On 6/17/2013, Larry wrote:

That is the way it works for non-test packages.

I'm not sure what mirror you're using but on mirror.mcs.anl.gov, bash
4.1.11 is the only version available for x64.

~~~

No, it does not.

I've compiled, and installed bash 4.2.45 for x64, and made appropriate
changes in the /etc directory, so, it is up on the list of the
installed packages. However, it keeps downgrading.

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

Re: Fwd: [Feature request] Setup64.exe should respect more recent packages' version

[Larry Hall (Cygwin)]

On 6/17/2013 3:50 PM, Vasiliy wrote:

On 6/17/2013, Larry wrote:

That is the way it works for non-test packages.

I'm not sure what mirror you're using but on mirror.mcs.anl.gov, bash
4.1.11 is the only version available for x64.

~~~

No, it does not.

I've compiled, and installed bash 4.2.45 for x64, and made appropriate
changes in the /etc directory, so, it is up on the list of the
installed packages. However, it keeps downgrading.


You'll need to update your local 'setup.ini' file to account for your
local version.  As Marco mentioned, 'setup.ini' is what setup uses to
determine the proper version to offer.


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

[ANNOUNCEMENT] Updated: {openldap/openldap-server/libopenldap2_4_2/openldap-devel}-2.4.35-2: Lightweight Directory Access Protocol suite

[Dr . Volker Zell]

Hi

New versions of 'openldap/openldap-server/libopenldap2_4_2/openldap-devel' have 
been uploaded to a server near you.

 o Build for cygwin 1.7.20-1 with gcc-4.5.3-3
 o Fixed buildsystem for cygwin
   -> http://cygwin.com/ml/cygwin-apps/2013-06/msg00076.html
 o Fixed coredump in ldapsearch (for 64bit version)
   -> http://cygwin.com/ml/cygwin-apps/2013-06/msg00126.html
 o slapd server packaged separately


CYGWIN-ANNOUNCE UNSUBSCRIBE INFO



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


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

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


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

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

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

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

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

Re: Cross-compiling Linux kernel

[Yaakov (Cygwin/X)]

On 2013-06-17 08:24, Fedin Pavel wrote:

  In order to cross-compile Linux kernel i have to patch host-side tools a
little bit. Current problems are:
  1. Cygwin misses linux/types.h


I have been trying to get this fixed upstream for quite some time 
without success:


https://lkml.org/lkml/2012/6/11/604
https://lkml.org/lkml/2012/10/15/608
https://lkml.org/lkml/2013/4/28/84


  2. Cygwin defines the following ELF macros according to host machine:
ELF_ST_BIND, ELF_ST_TYPE, ELF_R_SYM, ELF_R_TYPE


Those are indeed copied straight from BSD's headers; I'll have to look 
into this further.



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

[Yaakov (Cygwin/X)]

On 2013-06-16 21:54, Shaun Fielder wrote:

Since the vim-minimal package came into existence, it's caused a fair bit of
mucking around and frustration here (broken .vimrc; time to figure out
what's going on). (Especially as each update wants to re-install vim-minimal
which we don't want.)


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.



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: Fwd: [Feature request] Setup64.exe should respect more recent packages' version

[Warren Young]

On 6/17/2013 13:54, Larry Hall (Cygwin) wrote:

On 6/17/2013 3:50 PM, Vasiliy wrote:


I've compiled, and installed bash 4.2.45 for x64, and made appropriate
changes in the /etc directory, so, it is up on the list of the
installed packages. However, it keeps downgrading.


You'll need to update your local 'setup.ini' file to account for your
local version.


...and resign yourself to saying "Install from Local Directory," since 
your hand-hacked setup.ini is going to keep getting overwritten each 
time you say "Install from Internet" instead.


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

[Andrew DeFaria]

On 06/17/2013 12:01 PM, Dan Kegel wrote:

Andrew DeFaria wrote:

I'm confused. Let me ask a different way - why not fix such scripts instead?
That's all I'm asking.

He's probably daunted by the thought.

Doesn't really address the question.

OK, I'm out of here...
--
Andrew DeFaria 
Always try to be modest. And be damn proud 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: Fwd: [Feature request] Setup64.exe should respect more recent packages' version

[Larry Hall (Cygwin)]

On 6/17/2013 6:24 PM, Warren Young wrote:

On 6/17/2013 13:54, Larry Hall (Cygwin) wrote:

On 6/17/2013 3:50 PM, Vasiliy wrote:


I've compiled, and installed bash 4.2.45 for x64, and made appropriate
changes in the /etc directory, so, it is up on the list of the
installed packages. However, it keeps downgrading.


You'll need to update your local 'setup.ini' file to account for your
local version.


...and resign yourself to saying "Install from Local Directory," since your
hand-hacked setup.ini is going to keep getting overwritten each time you say
"Install from Internet" instead.


Aw, now you ruined my implicit "left as an exercise for the reader"! ;-)

--
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: Fwd: [Feature request] Setup64.exe should respect more recent packages' version

[Ken Brown]

On 6/17/2013 6:24 PM, Warren Young wrote:

On 6/17/2013 13:54, Larry Hall (Cygwin) wrote:

On 6/17/2013 3:50 PM, Vasiliy wrote:


I've compiled, and installed bash 4.2.45 for x64, and made appropriate
changes in the /etc directory, so, it is up on the list of the
installed packages. However, it keeps downgrading.


You'll need to update your local 'setup.ini' file to account for your
local version.


...and resign yourself to saying "Install from Local Directory," since
your hand-hacked setup.ini is going to keep getting overwritten each
time you say "Install from Internet" instead.


It won't get overwritten if it's in his own repository, parallel to the 
ones that get downloaded from mirrors.


Ken


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

Setup.exe won't run from Bash on Windows 8

[Chloe]

But it will run if I double click it from Explorer. I have execute 
permissions. What is wrong?


Chloe@xps ~
$ /setup.exe
-bash: /setup.exe: Permission denied

Chloe@xps ~
$ ls -l /setup.exe
-rwx--+ 1 Chloe None 705053 Jun 13 02:03 /setup.exe

Chloe@xps ~
$ icacls 'c:\cygwin\setup.exe'
c:\cygwin\setup.exe xps\Chloe:(RX,W)
BUILTIN\Administrators:(I)(F)
NT AUTHORITY\SYSTEM:(I)(F)

Successfully processed 1 files; Failed processing 0 files

Chloe@xps ~
$ uname -a
CYGWIN_NT-6.2-WOW64 xps 1.7.17(0.262/5/3) 2012-10-19 14:39 i686 Cygwin

Setup.exe version 2.774.



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

[Dan Kegel]

On Mon, Jun 17, 2013 at 4:13 PM, Chloe wrote:
> But it will run if I double click it from Explorer. I have execute
> permissions. What is wrong?

Does
  cmd /c setup.exe
work?

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

[Yaakov (Cygwin/X)]

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.



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

[Dan Kegel]

Andrew DeFaria wrote:
>>> I'm confused. Let me ask a different way - why not fix such scripts
>>> instead?
>>
>> He's probably daunted by the thought.
>>[snipped description of how to approach this huge task]
>
> Doesn't really address the question.

Armed with the tool I outlined, one could have a realistic
chance at fixing all such scripts in finite time.
- 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: cyginw64 ioperm package

[Balaji Venkataraman]

On Mon, Jun 17, 2013 at 12:41 PM, marco atzeri  wrote:

> as the 32 bit package is orphaned, we need a volunteer to take over.
> Are you interested ?

I'm new to maintaining a Cygwin package but sure, I'd like to give it
a shot. Is there more info besides this: http://cygwin.com/setup.html.
Would appreciate any more pointers. Thanks.

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

[Shaun Fielder]

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

Shaun


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

[gmt]

On Mon, 17 Jun 2013, at 11:19, Larry Hall (Cygwin) thusly quipped:
> So it's a question of convenience vs correctness.  It seems the argument
offered
> is that it is convenient to allow incorrect scripts.  An alternate
argument could be
> made that it is equally convenient to continue having Cygwin correctly
interpret
> '//' as it has been.  In addition, since the UNC interpretation of paths
comes for
> free (it's a Windows feature), it would be pretty inconvenient to make
Cygwin
> work otherwise.
> 
> I don't think the convenience vs correctness argument is going to inspire
> someone to action. ;-)

On Mon, 17 Jun 2013, at 12:01, Dan Kegel thusly quipped:
> Andrew DeFaria wrote:
>> I'm confused. Let me ask a different way - why not fix such scripts
instead?
>> That's all I'm asking.
> 
> He's probably daunted by the thought.
> 
> If he really wants to change the world here, he should consider writing a
tool
> that scanned for such problems, and lobbying to get it included in some
broadly
> used suite of checks like lintian.
> - Dan

Geez, tough ml.  If you are referring to me, you've misunderstood.

This was a rhetorical exercise, not an advocacy campaign :)  At no point
have I advocated not fixing broken scripts, or changing the world in any
way.  And I am undaunted by thoughts.  Mostly, I couldn't resist giving a
literal answer to Andrew's (maybe-not-so-literally-intended) question of
"why not fix it?" (nevertheless, I did fix it, already).

Plus, I reasoned that, as somebody who could have benefited from OP's
proposal in the past, I was in a good position to play devil's advocate (I
expected the other side of the argument would be adequately presented by
everyone else but me).

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/double-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).

-gmt



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

[Andrew DeFaria]

On 06/17/2013 07:18 PM, g...@malth.us wrote:
Mostly, I couldn't resist giving a literal answer to Andrew's 
(maybe-not-so-literally-intended) question of "why not fix it?" 
(nevertheless, I did fix it, already). 

I see, and I rest my case...
--
Andrew DeFaria 
A Clean House Is A Sign Of A Misspent Life


--
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: cyginw64 ioperm package

[marco atzeri]

Il 6/18/2013 2:19 AM, Balaji Venkataraman ha scritto:

On Mon, Jun 17, 2013 at 12:41 PM, marco atzeri  wrote:


as the 32 bit package is orphaned, we need a volunteer to take over.
Are you interested ?


I'm new to maintaining a Cygwin package but sure, I'd like to give it
a shot. Is there more info besides this: http://cygwin.com/setup.html.
Would appreciate any more pointers. Thanks.



that is the base, but a bit outdated on packaging details.
Install cygport and read the documentation for effective package 
construction.


A lot of pratical example are here
http://cygwin-ports.git.sourceforge.net/git/gitweb-index.cgi



Regards
Marco

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

[ANNOUNCEMENT] Updated: cygport-0.12.2-1

[Yaakov (Cygwin/X)]

I have just released cygport-0.12.2 for the Cygwin distributions and the
Fedora Cygwin repository.  Notable changes in this release include:

* cygautoreconf() replaces config.guess and config.sub with its own 
copies from upstream git, fixing packages using automake-1.9 or older on 
x86_64-cygwin.


* New perl_sax_parser_register() function in perl.cygclass, for handling 
postinst/prerm registration of XML::SAX parser engines.


Changes in this release (8):
  list_deps: refine Python dependency detection
  perl: add XML::SAX parser postinst/prerm commands
  mirrors: update mirror_portage
  autotools: always replace config.guess and config.sub
  waf: allow use of bundled waf
  list_deps: ignore deps of rubygem sample/test code
  Update gnuconfig
  cygport 0.12.2

--

Yaakov
Cygwin/X


CYGWIN-ANNOUNCE UNSUBSCRIBE INFO


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

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

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

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

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

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

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

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

Re: UNC and POSIX paths

[Christopher Faylor]

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/double-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.

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

Bug with Cygwin's 'quilt'

[Matt D.]

There seems to be a problem with Cygwin's quilt. This simple example 
simply alters a #define from 'MESAGL' to 'NX_MESAGL'. That's it.


New quilt created, ok.
New patch, ok.
Edit file, ok.
Refresh (create patch), ok.
Rollback changes, ok.
Reapply patch.. error:

 >>> quilt push
 >>> Applying patch test.patch
 >>> patching file Imakefile
 >>> Hunk #1 FAILED at 2.
 >>> 1 out of 1 hunk FAILED -- rejects in file Imakefile
 >>> Patch test.patch does not apply (enforce with -f)

Extract quilt_cygwin_bug to a directory, cd in, and run 'quilt push' to 
generate the error.



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

Bug with Cygwin's 'quilt'

[Matt D.]

The last e-mail I supplied to the mailing list was missing the link to 
the example. See this one for the link.


---

There seems to be a problem with Cygwin's quilt. This simple example 
simply alters a #define from 'MESAGL' to 'NX_MESAGL'. That's it.


New quilt created, ok.
New patch, ok.
Edit file, ok.
Refresh (create patch), ok.
Rollback changes, ok.
Reapply patch.. error:

  >>> quilt push
  >>> Applying patch test.patch
  >>> patching file Imakefile
  >>> Hunk #1 FAILED at 2.
  >>> 1 out of 1 hunk FAILED -- rejects in file Imakefile
  >>> Patch test.patch does not apply (enforce with -f)

http://codespunk.com/files/upload/cygwin_quilt_00.zip

Extract to a directory, cd in, and run 'quilt push' to generate the error.



--
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: Bug with Cygwin's 'quilt'

[Matt D.]

Built the latest source 0.60 (same version as Cygwin) from 
http://freecode.com/projects/quilt. Built on CentOS 6.4 and passes my 
previously provided test just fine.


Downloaded the same source to Cygwin, rebuilt, replaced quilt in /bin; 
test still errors out. I also tried the latest cygwin1.dll snapshot; 
same problem.



On 6/18/2013 1:09 AM, Matt D. wrote:

The last e-mail I supplied to the mailing list was missing the link to
the example. See this one for the link.

---

There seems to be a problem with Cygwin's quilt. This simple example
simply alters a #define from 'MESAGL' to 'NX_MESAGL'. That's it.

New quilt created, ok.
New patch, ok.
Edit file, ok.
Refresh (create patch), ok.
Rollback changes, ok.
Reapply patch.. error:

 >>> quilt push
 >>> Applying patch test.patch
 >>> patching file Imakefile
 >>> Hunk #1 FAILED at 2.
 >>> 1 out of 1 hunk FAILED -- rejects in file Imakefile
 >>> Patch test.patch does not apply (enforce with -f)

http://codespunk.com/files/upload/cygwin_quilt_00.zip

Extract to a directory, cd in, and run 'quilt push' to generate the error.



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

[gmt]

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.

Although I hate to continue casting myself in this "advocate" role -- I
really have very little stake in this -- otherwise you would have patches
for this, rather than 1000 words.

-gmt



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

> Because some scripts try to use
> 
> $(DESTDIR)/$(PREFIX)
> 
> rather than
> 
> $(DESTDIR)$(PREFIX)

 Yes, exactly, this is what i have got.
 I start to have these problems when i try to do non-standard things like
cross-compiling Linux kernel and some 3rd party modules. :)
 Ability to run 'make install_modules' requires /sbin/depmod. With hardcoded
/sbin path. So, i have to cross-compile module-init-tools with '--prefix=/'.
This is the first place where i get '//'. Well, perhaps i'm lame and
'--prefix=' is the correct thing, not what i write. However i just followed
the tradition here
 Next, module-init-tools relies on either 'docbook2man' or 'docbook-to-man'.
I guess both packages are considered obsolete by Cygwin, we have
'docbook2x-man' instead. So, i have to build one of those two packages.
$(DESTDIR)/$(PREFIX) is found in the first one.
 Well, perhaps irrelevant because it fails to build with new awk (or
something like that, already don't remember). So i have found (ancient)
docbook-to-man and built it. Works.

 Also i remember getting this little problem somewhere else in the past.
Already don't remember...

 Now my last arguments...
 First. Actually, we may consider this as kind of interoperability problem.
Technically it's possible to fix this at either side. However, let's say we
have three packages suffering from this problem. So, it's possible to do
either three fixes (for packages), or a single fix (for Cygwin). A single
fix is less time-consuming. Especially taking into account that a half of us
uses Cygwin at work, where we have other tasks to do.
 Second, if we take a look at real-world POSIX systems (Linux, BSD, whatever
else), they don't use '//' for network paths. Instead they use mountable
filesystems. And Cygwin's goal is to fully implement UNIX-compatible
environment, isn't it ? So, consequently, having a mount point would me more
compatible with other real-world systems.
 Third, package's author can say: 'nobody else has this problem, so it's
Cygwin's bug, not mine, i won't fix'. Or he can simply blindly hate Windows.
My another topic (cross-compiling Linux kerne) contains an example of such
an attitude.
 And, i agree, '//' is shorter to type than '/unc/'. :) And perhaps someone
already relies on '//' in his scripts for his installation.

 To sum things up, this was just an opinion. I didn't want to start a war.
:)

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

[Václav Zeman]

On 06/18/2013 08:20 AM, Fedin Pavel wrote:
>  Hello!
> 
>> Because some scripts try to use
>>
>> $(DESTDIR)/$(PREFIX)
>>
>> rather than
>>
>> $(DESTDIR)$(PREFIX)
> 
>  Yes, exactly, this is what i have got.
>  I start to have these problems when i try to do non-standard things like
> cross-compiling Linux kernel and some 3rd party modules. :)
>  Ability to run 'make install_modules' requires /sbin/depmod. With hardcoded
> /sbin path. So, i have to cross-compile module-init-tools with '--prefix=/'.
> This is the first place where i get '//'. Well, perhaps i'm lame and
> '--prefix=' is the correct thing, not what i write. However i just followed
> the tradition here
>  Next, module-init-tools relies on either 'docbook2man' or 'docbook-to-man'.
> I guess both packages are considered obsolete by Cygwin, we have
> 'docbook2x-man' instead. So, i have to build one of those two packages.
> $(DESTDIR)/$(PREFIX) is found in the first one.
>  Well, perhaps irrelevant because it fails to build with new awk (or
> something like that, already don't remember). So i have found (ancient)
> docbook-to-man and built it. Works.
Does replacing "/" with "/." help or does it not help? I cannot test
this right now.


> 
>  Also i remember getting this little problem somewhere else in the past.
> Already don't remember...
> 
>  Now my last arguments...
>  First. Actually, we may consider this as kind of interoperability problem.
> Technically it's possible to fix this at either side. However, let's say we
> have three packages suffering from this problem. So, it's possible to do
> either three fixes (for packages), or a single fix (for Cygwin). A single
> fix is less time-consuming. Especially taking into account that a half of us
> uses Cygwin at work, where we have other tasks to do.
>  Second, if we take a look at real-world POSIX systems (Linux, BSD, whatever
> else), they don't use '//' for network paths. Instead they use mountable
> filesystems. And Cygwin's goal is to fully implement UNIX-compatible
> environment, isn't it ? So, consequently, having a mount point would me more
> compatible with other real-world systems.
>  Third, package's author can say: 'nobody else has this problem, so it's
> Cygwin's bug, not mine, i won't fix'. Or he can simply blindly hate Windows.
> My another topic (cross-compiling Linux kerne) contains an example of such
> an attitude.
>  And, i agree, '//' is shorter to type than '/unc/'. :) And perhaps someone
> already relies on '//' in his scripts for his installation.
> 
>  To sum things up, this was just an opinion. I didn't want to start a war.
> :)

-- 
VZ





signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: screen 4.1.0-20130513-1

[Andrew Schulman]

A new test version of screen, 4.1.0-20130513-1, is available in the Cygwin
distribution, both 32 and 64 bits.

This is a test release.  To get it in setup.exe or setup64.exe, you'll have to
click on the "Exp" radio button at top right of the "Select Packages" window.

This is the first update of screen in Cygwin since the last official upstream
release, version 4.0.3, back in 2005.  Although version 4.1.0 isn't officially
released, development has continued and there are many fixes and new features in
this Cygwin release:

* The much-requested vertical split feature is now supported upstream and
available in this release.

* All the old crufty patches that used to be needed to get screen to work in
Cygwin, are apparently no longer needed now.  Both Cygwin and screen have
matured a lot in the last 8 years, so I take this as a good sign.

* And I'm sure lots more stuff in the last 8 years that I don't know about.

Please test this release, and report here how it's working for you.  I'll be
using it for my daily work now, and if there are no major complaints after a few
weeks, I'll move it from test to current.

screen is a terminal multiplexer and window manager that runs several separate
'screens' on a single physical character-based terminal.  Each virtual terminal
emulates a DEC VT100 plus several ANSI X3.64 and ISO 2022 functions.  You can
create multiple windows with any programs in them, kill the current window,
switch between windows or copy text between them, view a list of active windows,
rename windows, view scrollback history, and more.  You can detach your session
and even log out if you wish; your programs will keep running, and you can
reattach later, maybe when logged in from a different host.

Andrew E. Schulman


***


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.

  *** 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.com_at_cygwin.com  

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

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

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

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

RE: Cross-compiling Linux kernel

[Fedin Pavel]

 Hello!

> >   1. Cygwin misses linux/types.h
> 
> I have been trying to get this fixed upstream for quite some time
> without success:
> 
> https://lkml.org/lkml/2012/6/11/604
> https://lkml.org/lkml/2012/10/15/608
> https://lkml.org/lkml/2013/4/28/84

 Looks like Linux developers have taken over Olympus from greek gods, and
totally don't care about anyone except themselves any mote. I have already
met this problem when tried to push Amiga SFS filesystem implementation to
LKML. They told me something like: "We are *L*I*N*U*X*, we have own cool
filesystems and we don't care about one more obscure filesystem". I was
extremely angry and barely stopped myself from replying that whole their
Linux is not less obscure, because 99% of the world actually use NTFS. :(

 Again, from the practical point of view... May be make some package like
linux-compat ?

 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.

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

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

[Fedin Pavel]

 Hello!

> Does replacing "/" with "/." help or does it not help? I cannot test
> this right now.

 Yes, it does, this is how i did it. So - yes, it is also a matter of
convenience, and time needed to find this workaround.

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