Re: mingw-targeted cross-compiler question

[lemkemch]

On Wed, 22 Dec 2010 15:36:01 +0100, Kai Tietz   
wrote:



2010/12/22  :

On Wed, 22 Dec 2010 15:11:18 +0100, Kai Tietz 
wrote:


2010/12/22  :


On Wed, 22 Dec 2010 14:13:15 +0100, Frédéric Bron  


wrote:


I checked the Make file, it used this flag:
gcc -mno-cygwin -g -Wl,--add-stdcall-alias  
-Wl,--export-all-symbols

...


replace gcc by gcc-3
gcc 4 is now the default on cygwin but the cross compiler is not
supported for that version.
Frédéric




Well, I don't know but I'd really like to know what is the replacement
these days for

gcc -mno-cygwin -mwindows x.c

I tried

i686-w64-mingw32-gcc -mwindows  -m32 x.c

but get

x.c:35:13: error: expected '=', ',', ';', 'asm' or '__attribute__'  
before

'WinMain'

and that also for all other option combinations that made sense to me.

Thanks,
Michael


Btw the -m32 is superflous for the i686-w64-mingw32 cross-compiler, as
it just produces 32-bit and has no 64-bit capabilities builtin.
Could you show please your x.c file, as the message you get is a
compiler error already. I would assume that you missed to include some
header, or you were defining something which cause here the harm.


Well, the program compiles just fine with the old gcc-3 -mno-cygwin but
anyway, here's a stripped down version:


#define WINVER 0x0500
#include 

int STDCALL WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmd, int
nShow) {
  return 0;
}


 orion> i686-w64-mingw32-gcc -mwindows -m32 xx.c
xx.c:4:13: error: expected '=', ',', ';', 'asm' or '__attribute__'  
before

'WinMain'
 orion> gcc-3 -mno-cygwin -mwindows -m32 xx.c
 orion>




Well, the issue is STDCALL. We don't define this macro. Sorry, can
find a single hint on that in msdn. Use here instead the standard
WINAPI and it builds on all compilers you are using.


Thanks, that fixed it.  Don't know where I got that STDCALL from,
it certainly wasn't my invention.  However, the size of the executable
for that noop program went up from about 21kb to about 100kb.  cygcheck
lists the same dlls:

 orion> gcc-3 -mno-cygwin -mwindows -m32 xx.c
 orion> ls -ls a.exe
24 -rwxr-x--- 1 michael None 21347 Dec 22 17:18 a.exe
 orion> cygcheck ./a.exe
d:\cygwin\home\michael\a.exe
  C:\WINDOWS\system32\msvcrt.dll
C:\WINDOWS\system32\KERNEL32.dll
  C:\WINDOWS\system32\ntdll.dll
 orion> i686-w64-mingw32-gcc -mwindows -m32 xx.c
 orion> ls -ls a.exe
100 -rwxr-x--- 1 michael None 100582 Dec 22 17:21 a.exe
 orion> cygcheck ./a.exe
d:\cygwin\home\michael\a.exe
  C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\ntdll.dll
  C:\WINDOWS\system32\msvcrt.dll

Why would that be?

Michael


--
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: mingw-targeted cross-compiler question

[lemkemch]

On Wed, 22 Dec 2010 15:11:18 +0100, Kai Tietz   
wrote:



2010/12/22  :
On Wed, 22 Dec 2010 14:13:15 +0100, Frédéric Bron  


wrote:


I checked the Make file, it used this flag:
gcc -mno-cygwin -g -Wl,--add-stdcall-alias -Wl,--export-all-symbols  
...


replace gcc by gcc-3
gcc 4 is now the default on cygwin but the cross compiler is not
supported for that version.
Frédéric


What do you mean by not supported?  JonY maintains the cross
compilers


I meant that i686-w64-mingw32-gcc exists but not i686-w32-mingw32-gcc.
I thought that w64 meant "built on win64" and mingw32 "run binary on
win32".
So it seems to me that with cygwin running on a 32 bit windows, it is
not possible to cross compile to win32. However with a 64 bit windows
you can produce win32 applications.
However, I just tried to use i686-w64-mingw32-g++ on my win32 machine
with a hello world program and it produces an binary that can be used
from windows on that win32 machine.
So my question to the list: what is the meaning of w64 in the name?


Well, I don't know but I'd really like to know what is the replacement
these days for

gcc -mno-cygwin -mwindows x.c

I tried

i686-w64-mingw32-gcc -mwindows  -m32 x.c

but get

x.c:35:13: error: expected '=', ',', ';', 'asm' or '__attribute__'  
before

'WinMain'

and that also for all other option combinations that made sense to me.

Thanks,
Michael


Hi,

the -w64- within cross-compiler's triplet means that this compiler
uses mingw-w64 runtime headers and libraries. The architecture part of
triplet (i686|x86_64) makes the difference, if a cross-compiler
produces binaries for i686 (means 32-bit), or for x86_64  (means
64-bit) windows native.
Btw the -m32 is superflous for the i686-w64-mingw32 cross-compiler, as
it just produces 32-bit and has no 64-bit capabilities builtin.
Could you show please your x.c file, as the message you get is a
compiler error already. I would assume that you missed to include some
header, or you were defining something which cause here the harm.


Well, the program compiles just fine with the old gcc-3 -mno-cygwin but
anyway, here's a stripped down version:


#define WINVER 0x0500
#include 

int STDCALL WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmd, int  
nShow) {

   return 0;
}


 orion> i686-w64-mingw32-gcc -mwindows -m32 xx.c
xx.c:4:13: error: expected '=', ',', ';', 'asm' or '__attribute__' before  
'WinMain'

 orion> gcc-3 -mno-cygwin -mwindows -m32 xx.c
 orion>

Thanks,
Michael


--
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: mingw-targeted cross-compiler question

[lemkemch]

On Wed, 22 Dec 2010 14:13:15 +0100, Frédéric Bron   
wrote:



I checked the Make file, it used this flag:
gcc -mno-cygwin -g -Wl,--add-stdcall-alias -Wl,--export-all-symbols  
...


replace gcc by gcc-3
gcc 4 is now the default on cygwin but the cross compiler is not
supported for that version.
Frédéric


What do you mean by not supported?  JonY maintains the cross  
compilers


I meant that i686-w64-mingw32-gcc exists but not i686-w32-mingw32-gcc.
I thought that w64 meant "built on win64" and mingw32 "run binary on  
win32".

So it seems to me that with cygwin running on a 32 bit windows, it is
not possible to cross compile to win32. However with a 64 bit windows
you can produce win32 applications.
However, I just tried to use i686-w64-mingw32-g++ on my win32 machine
with a hello world program and it produces an binary that can be used
from windows on that win32 machine.
So my question to the list: what is the meaning of w64 in the name?


Well, I don't know but I'd really like to know what is the replacement
these days for

gcc -mno-cygwin -mwindows x.c

I tried

i686-w64-mingw32-gcc -mwindows  -m32 x.c

but get

x.c:35:13: error: expected '=', ',', ';', 'asm' or '__attribute__' before  
'WinMain'


and that also for all other option combinations that made sense to me.

Thanks,
Michael


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

Re: configure rxvt on cygwin 1.7.5

[lemkemch]

On Fri, 09 Jul 2010 00:41:25 +0200, Jeremy Bopp  wrote:


On 7/8/2010 4:22 PM, philippe wrote:

Jeremy Bopp a écrit :
[...] However, if rxvt used to work for you under Cygwin 1.5, you  
might be

able to make it happy again by changing your LANG setting to LANG=C.


No, i don't know where to modify this option LANG :-)


LANG is an environment variable.  Under Cygwin 1.5, LANG=C was the
default, but under Cygwin 1.7, LANG=C.UTF-8 is the default.  This change
is probably why rxvt stopped working for you out of the box.


If you want to continue with rxvt and want to keep it as close
as possible to the old behavior set

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

in .profile

Works for me.  The LC_TIME is to keep ls -l produce the standard time
strings.

Michael


--
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: UTF8 and cvs issues in 1.7.2

[lemkemch]

On Fri, 26 Mar 2010 15:51:38 -0600 Erik Blake wrote:

On 03/26/2010 03:44 PM, lemke...@t-online.de wrote:
>> What you can do is either to
>> use ISO-8859-1 sort of like above, or you convert the file content
>> to UTF-8 so you can use UTF-8 from now on.
>> The only problem is this file is none of my business.  It's CVS's  
file.

> What does cvs on linux do in this case?
The same thing; it's just that you've probably never used CVS on Linux
with two different charset encodings between the two uses.  Really, the
change in charset from cygwin 1.5 to 1.7 is a rare event, but it can
certainly cause some grief if you aren't expecting it.


Well, on Cygwin 1.7.2 the contents of CVS/Entries depend on my setting
of LANG.  This I find strange but I understand why it happens.  Does
that also happen on Linux?  I guess not as the filename is still a stream
of bytes even in local aware Linux (I haven't used Linux for ages).

Michael


--
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: UTF8 and cvs issues in 1.7.2

[lemkemch]

On Fri, 26 Mar 2010 10:30:28 +0100 Corinna Vinschen wrote:

On Mar 26 00:24, lemkemch wrote:
> Erik Blake wrote:
> >On 03/25/2010 05:05 PM, lemkemch wrote:
> >>  orion> cvs -qn up -l
> >> U Ãppel.txt
> >> cvs update: warning: `âppel.txt' is not (any longer) pertinent
> >> ... I am not talking about the
> >> displayed characters here but that cvs wants to update a file.
> >I wonder if the problem is that CVS/Entries was created under one
> >charset, but you are now using a different charset.  I suppose you  
could

> >use iconv to convert the file to the correct encoding.  Or it may be a
> >sign that cvs has not yet been recompiled to be charset-aware.
>> Yes, that sort of it is.  Further experiments show this:
>> CVS/Entries written by 1.5:
>> /äppel.txt/1.1/Thu Mar 25 22:14:59 2010//
>> With 1.7 it changes to (module character corruption through e mail):
>> /äppel.txt/1.1/Thu Mar 25 22:14:59 2010//
>> The positive is that the cvs update doesn't actually change
> the file on disk.  All that happens is changing CVS/Entries.
> Still annoying.
>> The fix I found is
>>   setenv LANG C.ISO-8859-1
>> But somehow that doesn't smell right.
I explained that a lot in this list and in the User's Guide.  The
problem is that Windows uses UTF-16 under the hood.  So there's no
filename based operation without the requirement to convert from a
multibyte to the widechar charset.


Too bad but I see why that is and that there is no way around it.


What you can do is either to
use ISO-8859-1 sort of like above, or you convert the file content
to UTF-8 so you can use UTF-8 from now on.


The only problem is this file is none of my business.  It's CVS's file.
What does cvs on linux do in this case?


I'm really sorry that
this is necessary, but it's really not my fault.


I know.  But anyway, seems to be the way it is.

Michael

--
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: UTF8 and cvs issues in 1.7.2

[lemkemch]

Erik Blake wrote:

On 03/25/2010 05:05 PM, lemkemch wrote:
>  orion> cvs -qn up -l
> U Ãppel.txt
> cvs update: warning: `âppel.txt' is not (any longer) pertinent
>> And frankly, I can't see how the terminal could influence the
> behavior of the cvs executable.  I am not talking about the
> displayed characters here but that cvs wants to update a file.
I wonder if the problem is that CVS/Entries was created under one
charset, but you are now using a different charset.  I suppose you could
use iconv to convert the file to the correct encoding.  Or it may be a
sign that cvs has not yet been recompiled to be charset-aware.


Yes, that sort of it is.  Further experiments show this:

CVS/Entries written by 1.5:

/äppel.txt/1.1/Thu Mar 25 22:14:59 2010//

With 1.7 it changes to (module character corruption through e mail):

/äppel.txt/1.1/Thu Mar 25 22:14:59 2010//

The positive is that the cvs update doesn't actually change
the file on disk.  All that happens is changing CVS/Entries.
Still annoying.

The fix I found is

  setenv LANG C.ISO-8859-1

But somehow that doesn't smell right.

Michael

--
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: UTF8 and cvs issues in 1.7.2

[lemkemch]

Larry Hall wrote:



With Google.



Pretty easy to find, eh? You practically bumped into each other.


Thanks for the quick answer, but sorry, no, mintty doesn't help:

 orion> cvs -qn up -l
U äppel.txt
cvs update: warning: `▒ppel.txt' is not (any longer) pertinent

And frankly, I can't see how the terminal could influence the
behavior of the cvs executable.  I am not talking about the
displayed characters here but that cvs wants to update a file.

Michael

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

UTF8 and cvs issues in 1.7.2

[lemkemch]

Some time ago in cygwin 1.5 I did this:

 orion> cvs ci äppel.txt
/home/michael/Repos/äppel.txt,v  <--  äppel.txt
initial revision: 1.1
 orion>
 orion> cvs -qn up
 orion>

Exactly the expected behavior.


Now in my new 1.7.2 installation the cvs up gives this
(in an rxvt window):

 orion> cvs -qn up
U äppel.txt
cvs update: warning: `äppel.txt' is not (any longer) pertinent

 orion> locale
LANG=C.ASCII
LC_CTYPE="C.ASCII"
LC_NUMERIC="C.ASCII"
LC_TIME="C"
LC_COLLATE="C.ASCII"
LC_MONETARY="C.ASCII"
LC_MESSAGES="C.ASCII"
LC_ALL=

 orion> printenv | grep ^L | sort
LANG=C.ASCII
LC_TIME=C


 orion> cvs -v

Concurrent Versions System (CVS) 1.12.13 (client/server)
...

How to fix this?

Thanks,
Michael

--
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: [1.7] Accented characters don't work

[lemkemch]

On Sat, 28 Nov 2009 20:23:49 +0100, I wrote:


On Sat, 28 Nov 2009 17:16:44 +0100, Marco Atzeri wrote:


--- Sab 28/11/09, lemkemch  ha scritto:


> and the Cygwin console. Urxvt and xterm require an X
server.

And that I really don't like.  Way too complex for my
taste for the
simple task of popping up a text window.
>


mintty is the right tool for replacing rxvt for not X11.

on XP I have no problem to build a file like
$ touch ÄÄÆÉßü

and to have exactly the same on explorer and from
cmd.



I just gave it a try.  It seemed to have solved the character
problem but I now have a not responding mintty window.  I
started mintty from the rxvt window and tried to send
it to the background with CTRL/D (which is what I have mapped
susp to).  mintty didn't go into the background so I CTRL/C'ed
it in rxvt.  That freed up the rxvt prompt but didn't kill the
mintty process.  The window still hangs around with that
(Not Responding) headline.


I take that back.  Pilot error.  Mintty behaves fine.

But I still like an answer to this:


But how do I get back a pure C locale?  I also
want ls -l to output the old standard date format.  So
setenv LANG C.what?  C.ISO-8859-15 is kind of nice (the accented
chars display fine) but ls then shows the iso-type date format.



Michael


--
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: [1.7] Accented characters don't work

[lemkemch]

On Sat, 28 Nov 2009 17:16:44 +0100, Marco Atzeri wrote:


--- Sab 28/11/09, lemkemch  ha scritto:


> and the Cygwin console. Urxvt and xterm require an X
server.

And that I really don't like.  Way too complex for my
taste for the
simple task of popping up a text window.
>


mintty is the right tool for replacing rxvt for not X11.

on XP I have no problem to build a file like
$ touch ÄÄÆÉßü

and to have exactly the same on explorer and from
cmd.



I just gave it a try.  It seemed to have solved the character
problem but I now have a not responding mintty window.  I
started mintty from the rxvt window and tried to send
it to the background with CTRL/D (which is what I have mapped
susp to).  mintty didn't go into the background so I CTRL/C'ed
it in rxvt.  That freed up the rxvt prompt but didn't kill the
mintty process.  The window still hangs around with that
(Not Responding) headline.

I guess I stick with old trusty rxvt and skip this new fangled
utf-8 stuff.  But how do I get back a pure C locale?  I also
want ls -l to output the old standard date format.  So
setenv LANG C.what?  C.ISO-8859-15 is kind of nice (the accented
chars display fine) but ls then shows the iso-type date format.

Thanks,
Michael

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


--
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: [1.7] Accented characters don't work

[lemkemch]

On Sat, 28 Nov 2009 07:57:52 +0100, Andy Koppe wrote:


2009/11/27  :

What am I doing wrong with my first tries of 1.7?  I created in Windows
Explorer a directory Ébène and in it a file très.  When I look at it
with ls in an rxvt window I don't see the accented characters but the
two utf-8 bytes.  Hm.


Rxvt doesn't support UTF-8.


I knew.  I expected that to mean that certain characters won't be
displayed properly but thinking of it it means rxvt doesn't know
how to `combine' those two (or more) bytes to a single character.
Understandable.


It's dead upstream, so that's unlikely to
change. UTF-8 is supported by urxvt (aka rxvt-unicode), xterm, mintty,
and the Cygwin console. Urxvt and xterm require an X server.


And that I really don't like.  Way too complex for my taste for the
simple task of popping up a text window.




I then created the same directory from tcsh (my standard shell) and
from bash.


Did you run those in rxvt as well?


Yes.  So I guess the byte my keyboard generated (by using a utility
called AllChars) - and which had the 8th bit set - got converted into
something that Windows thinks is Chinese.  Hm, but how is rxvt involved
here?  Isn't that a pure stty kind problem?  Would it work from a cmd
window?

Michael


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

[1.7] Accented characters don't work

[lemkemch]

What am I doing wrong with my first tries of 1.7?  I created in Windows
Explorer a directory Ébène and in it a file très.  When I look at it
with ls in an rxvt window I don't see the accented characters but the
two utf-8 bytes.  Hm.

I then created the same directory from tcsh (my standard shell) and
from bash.  And the result is really weird.  When looking at those
directories in Windows Explorer they have Chinese characters at the
place of the accented ones.

This is with any LC* and LANG unset on XP Pro SP3 in a pure US English
locale (Windows wise).

The 1.7 installation is parallel to a 1.5 install but I use the same
home directory and therefore the same .tcshrc for both.

Here's the summary (from a tcsh shell):

 orion> ls -Rl
.:
total 0
drwxr-x---+ 1 michael None 0 2009-11-27 23:03 Ébène_made_with_explorer
drwxr-x---+ 1 michael None 0 2009-11-27 01:40 ?b?ne_made_with_bash
drwxr-x---+ 1 michael None 0 2009-11-27 01:32 ?b?ne_made_with_tcsh

./Ébène_made_with_explorer:
total 0
-rwxr-x--- 1 michael None 0 2009-11-27 01:39 très

./?b?ne_made_with_bash:
total 0

./?b?ne_made_with_tcsh:
total 0
-rw-r- 1 michael None 0 2009-11-27 01:31 stuff
-rw-r- 1 michael None 0 2009-11-27 01:32 tr?s
 orion> ls -R | od -xc
0003a2ec30a6289a8c3656e6d5f64615f65
  .   :  \n 303 211   b 303 250   n   e   _   m   a   d   e   _
02069776874655f70786f6c65720a7262c9
  w   i   t   h   _   e   x   p   l   o   r   e   r  \n 311   b
0406ee85f65616d6564775f74695f686162
350   n   e   _   m   a   d   e   _   w   i   t   h   _   b   a
0606873c90ae862656e6d5f64615f656977
  s   h  \n 311   b 350   n   e   _   m   a   d   e   _   w   i
1006874745f73630a682e0ac32f6289a8c3
  t   h   _   t   c   s   h  \n  \n   .   / 303 211   b 303 250
120656e6d5f64615f6569776874655f7078
  n   e   _   m   a   d   e   _   w   i   t   h   _   e   x   p
1406f6c65723a72740ac37273a80a0a2f2e
  l   o   r   e   r   :  \n   t   r 303 250   s  \n  \n   .   /
16062c96ee85f65616d6564775f74695f68
311   b 350   n   e   _   m   a   d   e   _   w   i   t   h   _
200616268730a3a2e0ac92fe862656e6d5f
  b   a   s   h   :  \n  \n   .   / 311   b 350   n   e   _   m
22064615f6569776874745f73633a68730a
  a   d   e   _   w   i   t   h   _   t   c   s   h   :  \n   s
2407574740ae8720a73
  t   u   f   f  \n   t   r 350   s  \n
252
 orion> stty -a
speed 38400 baud; rows 52; columns 80; line = 0;
intr = ^C; quit = ^Y; erase = ^?; kill = ^U; eof = ^Z; eol = ;
eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^D; rprnt =  
^R;

werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon  
-ixoff

-iuclc -ixany imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0  
vt0 ff0

isig icanon iexten echo echoe echok -echonl -noflsh -tostop echoctl echoke
 orion> uname -a
CYGWIN_NT-5.1 orion 1.7.0(0.218/5/3) 2009-11-25 13:41 i686 Cygwin
 orion>



There's more strange stuff going on with wildcards but I don't think we
should go into that at this point.  Something basic must be wrong here.

Any ideas?
Michael

--
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: [1.7] su

[lemkemch]

On Thu, 19 Nov 2009 cgf wrote:


On Thu, Nov 19, 2009 at 10:15:17PM +0100, lemke...@t-online.de wrote:

Is su supposed to work?


No.



Ok.

Michael

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

[1.7] su

[lemkemch]

Is su supposed to work?  When I try from an unprivileged account
I get:

michael> su addmini
Password:
su: /bin/bash: Permission denied


michael> procps -ef
UIDPID  PPID  C STIME TTY  TIME CMD
michael   7580 1  0 Nov28 tty0 00:00:11 /usr/bin/rxvt -sb -sl 1024  
-geom

michael   7260  7580  0 Nov28 tty0 00:00:00 -bash
michael   8100  7260  0 Nov28 tty0 00:00:00 procps -ef


This also happens if I run su from a privileged account (started via runas  
from a

windows shortcut) and try to switch to an unprivileged one:


[addm...@orion ~]$ su michael
Password:
su: /bin/bash: Permission denied
[addm...@orion ~]$


I can also play that game via login:


[addm...@orion ~]$ login
login: michael
Password:
  ,  
__
   .L_  
|  |
 .gQQQ__
|  |
 g==   | 
_.---.)   |
 QQQF= |  (^--^)_.-"   
`;  |
 Q!|  ) ee (
|  |
   | (_.__._)  
/   |
   |   `--', 
,'|
  ~"jjj__, |jgs  
)_|--')_| |
    "jj___ |""'
""' |
 ~j__   
|  |
 _jj/  |  The Hippo says: Welcome  
to  |
   .{jjj/~ |  
_|
  .{/` |    _   _     _ _ _ (_)  
  |
   | / ___)| | | | / _  || | | || ||   
_ \ |
   |( (___ | |_| |( (_| || | | || || |  
| ||
 QL___,| \) \__  | \___ | \___/ |_||_|  
|_||
 QQQL___   |(___/   
(| |
 4___   
|  |
 (=Q   |   -.-. -.-- --. .-- ..  
-.|
   (F=  
|__|


login: no shell: /bin/bash: Permission denied

addm...@orion ~
$


Thanks,
Michael

--
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: autoconf/configure problem on text mounts

[lemkemch]

lemkemch wrote on 10 August 2008 18:46:


I am not familar enough with autoconf to be able to tell how that line
gets into configure.  I can't find it in configure.in.  All I can see is
stuff like AH_VERBATIM([HAVE_UINT64_T] and AC_CHECK_TYPES([uint8_t,
int8_t, uint16_t, int16_t, uint32_t, int32_t, uint64_t, int64_t]); I'd
guess it is releated to the latter.


 Yep.  Those are macros that get expanded using m4 scripts based in
/usr/share/autoconf to generate the configure script.


...


  This is an autoconf bug upstream really.  They'd know best what how to
patch it long term.  If you wanted a quick local fix, you could edit
/usr/share/autoconf/autoconf/c.m4 and change that fopen command at  
source,
then any time you regenerate a configure script it'll come out ok for  
your

text mount.



Thanks Dave.  I've sent mail to the autoconf bugs e-mail address
referrring to this thread.


Michael

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

autoconf/configure problem on text mounts

[lemkemch]

There seems to be a problem with autoconf generated scripts when running  
the resulting configure on a text mount.  I came across this when trying  
to compile lame:


checking for int64_t... yes
configure: error: CHECK_TYPE_uint32_t - please report to lame-dev   
lists.sourceforge.net



I tracked this down to this line in configure:

   FILE *f = fopen ("conftest.val", "w")

If I change all occurrences to

   FILE *f = fopen ("conftest.val", "wb")

the configure and build succeeds.

I am not familar enough with autoconf to be able to tell how that line  
gets into configure.  I can't find it in configure.in.  All I can see is  
stuff like AH_VERBATIM([HAVE_UINT64_T] and AC_CHECK_TYPES([uint8_t,  
int8_t, uint16_t, int16_t, uint32_t, int32_t, uint64_t, int64_t]); I'd  
guess it is releated to the latter.


The contents of conftest.val are used later like

ac_cv_sizeof_unsigned_int=`cat conftest.val`

which adds a \r to the assignment causing later tests like

   if test "${ac_cv_sizeof_unsigned_int}" = "4"; then
   ...

to fail.

Running autoconf on cygwin results in the same broken configure script.

Any ideas what should be done other than not using a text mount?  To me  
opening the conftest.val file as text is wrong.


Michael

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