Augusto Deoliveira/SVL/SC/PHILIPS is out of the office.
I will be out of the office starting 12/17/2001 and will not return until 01/08/2002. I am in Brasil. If you need to reach me, please contact my Admin Melinda Riddle. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Bison 1.30
You need to define your own yyerror function. Bison uses it the report an error. It has the following prototype: void yyerror(char*s) As for the rest, include and/or , and perhaps some others depending on the actions you used in your rules. I have used bison 1.28, a LOT, and found no real problems other than suboptimal code in some cases. Stphano Mariani PS: You can try bison-1.30-1 now, and see for yourself bison is not at fault. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Fractal A. Sent: Wednesday, 26 December 2001 4:31 To: Randall R Schulz; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Bison 1.30 Hi, Because the compiler (bison 1.28) appears to be working incorrectly, I believe that a newer version of bison might solve the problem. I don't know why the "implicit declaration" error is occurring. I don't know what to do to solve it. The arithmetic.lex and arithmetic.y files were compiling properly before. When the other files started outputting the "implicit declaration" error, it seems that everything stopped working correctly. The error is of the type "implicit declaration" of several different yy functions. If you think of something to help, please let me know. Thanks. Examples of the error: Errors of this nature cause me to believe that the compiler is failing. C:\cygwin2\c15>g++ -Wall -c -gstabs ch1-05.y.tab.c /usr/share/bison.simple: In function `int yyparse()': /usr/share/bison.simple:358: implicit declaration of function `int yyerror(...)' C:\cygwin2\ega>g++ -Wall -c -gstabs arithmetic.y.tab.c /usr/share/bison.simple: In function `int yyparse()': /usr/share/bison.simple:361: implicit declaration of function `int free(...)' = Fractal A.[EMAIL PROTECTED] __ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: uptime.c
On Wed, Dec 26, 2001 at 09:16:29PM -0500, Facey Brian wrote: > uptime.c. Is there a way to just compile uptime.c by itself? There's an `UPTIME.EXE' e.g. in the W2K Resource Kit. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Bison 1.30
Thanks Stephano! I wondered about versions of Bison simply to rule out possible sources of error. You are right in that using Bison 1.30 did not make any difference. I'll try this solution next. Thanks again! = Fractal A.[EMAIL PROTECTED] __ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Bison 1.30
The *only* solution is:
Add
#include
#include
Into the
%{
%} Section
And add
void yyerror(char*s)
{
printf("%s",s);
}
After the final %%
Then see if you get the same.
If so send me a copy of the output from the compiler and bison.
Stephano
PS: bison is not a compiler. In your case g++ is. Bison Is a parser
generator.
-Original Message-
From: Fractal A. [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 27 December 2001 10:18
To: Stephano Mariani; 'Randall R Schulz'; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: Bison 1.30
Thanks Stephano!
I wondered about versions of Bison simply to rule out possible sources
of error. You are right in that using Bison 1.30 did not make any
difference.
I'll try this solution next. Thanks again!
=
Fractal A.[EMAIL PROTECTED]
__
Do You Yahoo!?
Send your FREE holiday greetings online! http://greetings.yahoo.com
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Potential problems with Cygwin GCC and -mno-cygwin switch
- Original Message -
From: "Jon Leichter" <[EMAIL PROTECTED]>
> 1) MinGW support in Cygwin GCC is flaky and buggy
That pages suggests that is _has been_ f & b - and it has. It's better
now than it ever has been, and still has ... quirks.
> 2) MinGW support in Cygwin GCC will possibly be deprecated
This won't happen unless a realistic way of building Cygwin is found!
(Cygwin cannot link to itself).
> 3) a better solution for MinGW binaries from a Cygwin environment
>is to install MinGW GCC over Cygwin
No way! I've read what they sugegst and it will cripple any cygwin user
from being able to build cygwin linked exe's. A cygwin hosted, mingw
targeted cross compiler however, would be a great tool and would
co-exist without any difficulty.
> While I do think Cygwin GCC currently does a great job of supporting
MinGW,
> I do have a few issues with it:
>
> 1) The --print-search-dirs switch outputs the same information whether
or
> not the -mno-cygwin switch is specified. This is a problem
particularly for
> GNU libtool. When the command "gcc -mno-cygwin --print-search-dirs" is
> executed, it ought to output the MinGW-specific directories and leave
the
> Cygwin-specific directories out. GNU libtool also expects a semi-colon
as
> the path separator.
I've not enough gcc innards to suggest a solution here. I suggest that
you do the following:
1) Ask just this question on a gcc specific list (how do a change the
output of print-search-dirs via the .specs, and if I can't do that
today, can anyone give me a pointer as to where I should look in the
code to add that capability). [It doesn't matter if gcc would accept
such a patch or not, cygwin often has things that the upstream don't
want in our releases, for various good reasons].
2) When you've got it working, submit it here, and the cygwin gcc
maintainer will likely pick it up and put it into the cygwin gcc release
(after testing of course)
You can hope that the cygwin gcc maintainer has the time to do 1)
himself, but I don't expect that to happen for a year or so :}.
>
>
> 2) In the specs file, /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/specs,
the
> following switch is declared in the *link section:
>
> --dll-search-prefix=cyg
>
> It seems to me that this switch should not be specified when GCC is in
MinGW
> mode. A fix would be to alter to the declaration:
>
> %{!mno-cygwin:--dll-search-prefix=cyg}
>
> Indeed, I have done this in my own specs file.
Here you may get luckly and have this (trivial change) picked up by the
maintainer. However the standard way for getting patches submitted is to
provide the output of diff -up against the original source, along with a
changelog.
> =
>
> 3) There's a problem with Cygwin-specific libraries residing in
/usr/lib.
...
> I, of course, updated the specs file to accomodate this. My
environment now
> works flawlessly. When OpenLDAP looks for libncurses, it doesn't find
it, as
> it shouldn't.
This seems like an interesting approach. I wonder if anything would get
broken by it (other than ALL the existing packages that provide
libraries :}).
> I wonder if anyone else thinks it would be a good idea to relocate
Cygwin
I think this may be easier than fixing gcc, but I'm sure that fixing gcc
is a better long term approach. However as I don't have the time nor
inclination to fix gcc myself, my opinion is just that.
Cheers,
Rob
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
windres doesn't accept DOS paths
Hi, I think someone mentioned that if cygwin utilities do not accept DOS paths then this should be considered a bug. Just to report then, if you pass a DOS path to windres, it barfs: windres "c:\test.rc" gives gcc: c:test.rc: No such file or directory gcc: Warning: `-x c-header' after last input file has no effect gcc: No input files windres: warning: preprocessor failed windres: no resources Best, Matthew -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rxvt and command prompt
You'll likely need to look at the source to answer that one. Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX At 03:24 PM 12/23/2001, Robert White wrote: >Christopher > >Thanks for replying. > >Can you elaborate please? > >Is there a way I can get isql to recognise rxvt's pyts? > >Thanks > >Rob > >Christopher Faylor wrote: > > > On Sun, Dec 23, 2001 at 09:57:04AM +, Robert White wrote: > > >All > > > > > >I have a problem using rxvt on the Windows 98 platform. I use rxvt over > > >the command prompt because it gives me a useful scrollback facility. > > > > > >I do a lot of database administration on SYBASE and Microsoft servers, > > >and these come bundled with a utility called isql. > > > > > >The problem I have is in the way this application works with rxvt. > > >Usually when you open an isql session you get a prompt like > > > > > >1> > > > > > >However on rxvt, this is not the case, you get nothing. Although if you > > >run a command the results are returned, but without the prompt again. > > > > > >This is not due to the cygwin environment, because if I run cygwin in a > > >command shell, isql works fine. > > > > This is an incorrect assumption. rxvt is using ptys. Obviously isql > > isn't recognizing cygwin's ptys. > > > > cgf > > > > -- > > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > > Bug reporting: http://cygwin.com/bugs.html > > Documentation: http://cygwin.com/docs.html > > FAQ: http://cygwin.com/faq/ > > >-- >Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple >Bug reporting: http://cygwin.com/bugs.html >Documentation: http://cygwin.com/docs.html >FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: windres doesn't accept DOS paths
At 10:00 AM 12/27/2001, Matthew Brett wrote: >Hi, > >I think someone mentioned that if cygwin utilities do not accept DOS paths >then this should be considered a bug. Just to report then, if you pass a >DOS path to windres, it barfs: > >windres "c:\test.rc" > >gives > >gcc: c:test.rc: No such file or directory >gcc: Warning: `-x c-header' after last input file has no effect >gcc: No input files >windres: warning: preprocessor failed >windres: no resources There does appear to be some issue here. Even at the DOS prompt, the backslash needs to be escaped in order to work (in the example above). Other Cygwin utilities don't have this problem. It's worth noting that the POSIX path and the "c:/test.rc" alternative paths both work fine though with windres. Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Potential problems with cygwin GCC and -mno-cygwin switch
On Fri, Dec 28, 2001 at 12:28:22AM +1100, Robert Collins wrote: >> = >> >>3) There's a problem with Cygwin-specific libraries residing in >>/usr/lib. ... I, of course, updated the specs file to accomodate >>this. My environment now works flawlessly. When OpenLDAP looks for >>libncurses, it doesn't find it, as it shouldn't. > >This seems like an interesting approach. I wonder if anything would >get broken by it (other than ALL the existing packages that provide >libraries :}). Yeah, and we can kiss that pesky "UNIX emulation" claim of cygwin's goodbye, too. Somehow, I don't think that you'll find many library files in /usr/lib/cygwin on, say, HP/UX, Linux, Tru64, etc. This method solves a "problem" for -mno-cygwin at the expense of impacting many other packages. I agree that the print-search-dirs should work correctly and even suggested this in the libtools forum. I agree that --dll-search-prefix=cyg should not be activated when the user specifies -mno-cygwin. I've made the appropriate change to my version of gcc but I don't think that this warrants a new release. We will not be moving .a files to /usr/lib/cygwin, so please lets not even discuss this. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Potential problems with cygwin GCC and -mno-cygwin switch
On Thu, Dec 27, 2001 at 12:02:46PM -0500, Christopher Faylor wrote: >On Fri, Dec 28, 2001 at 12:28:22AM +1100, Robert Collins wrote: >>> = >>> >>>3) There's a problem with Cygwin-specific libraries residing in >>>/usr/lib. ... I, of course, updated the specs file to accomodate >>>this. My environment now works flawlessly. When OpenLDAP looks for >>>libncurses, it doesn't find it, as it shouldn't. >> >>This seems like an interesting approach. I wonder if anything would >>get broken by it (other than ALL the existing packages that provide >>libraries :}). > >Yeah, and we can kiss that pesky "UNIX emulation" claim of cygwin's >goodbye, too. Somehow, I don't think that you'll find many library >files in /usr/lib/cygwin on, say, HP/UX, Linux, Tru64, etc. > >This method solves a "problem" for -mno-cygwin at the expense of >impacting many other packages. > >I agree that the print-search-dirs should work correctly and even suggested >this in the libtools forum. I agree that --dll-search-prefix=cyg should >not be activated when the user specifies -mno-cygwin. > >I've made the appropriate change to my version of gcc but I don't think >that this warrants a new release. Btw, by "appropriate change", I mean that I"ve moved the --dll-search-prefix inside of a !mno-cygwin block in the gcc specs file. I haven't made any changes to print-search-dirs and have no plans on doing so. cgf >We will not be moving .a files to /usr/lib/cygwin, so please lets not >even discuss this. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: duplicate regexec/regcomp functions detected
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf > Of Corinna Vinschen > Sent: Friday, December 14, 2001 11:36 AM > To: cygwin > Subject: Re: duplicate regexec/regcomp functions detected > > > On Thu, Dec 13, 2001 at 09:18:39PM +0100, Ralf Habacker wrote: > > Hi all, > > > > kde needs the regexp functions regexec and regcomp. > > > > The cygwin lib contains the System V8 function call style, while the pcre > package (pcreposix) > > provides another style (the system V style I guess). The problem is now, that both >libs > > supports the same names for regexec and regcomp but with different > parameter/return types. > > This results sometimes in execution failures if the libs are not in the right >order like > > shown in the following example. > > > > pcre regexp wanted > > > > $ gcc ... -lpcreposix -lcygwin -> okay > > > > $ gcc ... -lpthreads|-lm|-lc -lpcreposix -lcygwin -> failure: the functions in > cygwin lib > > are used > > But that order should never happen EXCEPT you're making the big > mistake to give `-lm' or `-lc' on the command line explicitly. > Since -lcygwin is appended automagically and libc.a and libm.a > are the same library anyway, the answer is simply, "Don't do that." This may be for -lm and -lc, but what about libpthread Think about this link line: gcc -o test -lpthread main.o [-lcygwin] This will result in multiple defined symbols for WinMain (expected that main.o contains a main function). You can say don't do this, but what about bigger packages like qt. The qt configuring process does only allow like the above link line. anyway, saying don't do this is a way, but solving this problem is another. A general possible solution for this, is not to make several links to cygwin, but to create linkage libraries with only special symbols used for each cygwin derivated lib, like pthread. The appended script does exactly this for libpthread. It extracts the pthread relating object files from libcygwin.a and create a new archive libpthread.a. Using this technology removes any ordering problems with pthread and other libs on the input line. > > Especially in libtool related environment with many dependency libs like kde > this causes much > > trouble. > > > > Should it not be better, to remove the regexp support from cygwin into a seperate >lib, so > > that users has an easier possibility to choose which regexp style they want ? > > We didn't want that for compatibility reasons. We often already > discussed to trash the V8 implementation in favor of a POSIX > implementation but that would break older applications which we're > trying to avoid. I understand, but what about to cast the function to another name (like _prefix or so) in the headerfiles. This would prevent some debugging sessions for people, who are not very confirm with this issue. Another solution may be the concept of creating extracted linking libraries desribed above. > Btw., we have another POSIX regex library besides pcreposix: -lregex. > It's somewhat smaller and it's also DLLized. OpenSSH's configure.ac > file has a special check to see if a regex lib exists and if the base > regexp implementation in the std C lib is POSIX compliant. We added > that to the OpenSSH configury a few weeks ago to make Cygwin happy. Thanks for this hint. > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Developermailto:[EMAIL PROTECTED] > Red Hat, Inc. > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Bug reporting: http://cygwin.com/bugs.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > > make_libpthread Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: duplicate regexec/regcomp functions detected
On Thu, Dec 27, 2001 at 06:22:43PM +0100, Ralf Habacker wrote: >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf >> Of Corinna Vinschen >> Sent: Friday, December 14, 2001 11:36 AM >> To: cygwin >> Subject: Re: duplicate regexec/regcomp functions detected >> >> >> On Thu, Dec 13, 2001 at 09:18:39PM +0100, Ralf Habacker wrote: >> > Hi all, >> > >> > kde needs the regexp functions regexec and regcomp. >> > >> > The cygwin lib contains the System V8 function call style, while the pcre >> package (pcreposix) >> > provides another style (the system V style I guess). The problem is now, that >both libs >> > supports the same names for regexec and regcomp but with different >> parameter/return types. >> > This results sometimes in execution failures if the libs are not in the right >order like >> > shown in the following example. >> > >> > pcre regexp wanted >> > >> > $ gcc ... -lpcreposix -lcygwin -> okay >> > >> > $ gcc ... -lpthreads|-lm|-lc -lpcreposix -lcygwin -> failure: the functions in >> cygwin lib >> > are used >> >> But that order should never happen EXCEPT you're making the big >> mistake to give `-lm' or `-lc' on the command line explicitly. >> Since -lcygwin is appended automagically and libc.a and libm.a >> are the same library anyway, the answer is simply, "Don't do that." > >This may be for -lm and -lc, but what about libpthread > >Think about this link line: > >gcc -o test -lpthread main.o [-lcygwin] > >This will result in multiple defined symbols for WinMain (expected that >main.o contains a main function). You can say don't do this, but what >about bigger packages like qt. The qt configuring process does only >allow like the above link line. The above link line makes no sense. It is wrong. It should be corrected. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Can't spawn shell for authenticated user in SSHD (revisited)
Hi all, I posted the message appended at the end of this one last week, and didn't receive a _single_ response to it. This leads me to believe that either 1) I have unwittingly committed some horrendous faux pax, despite the fact that I did attempt to research this problem before posting to this list, or 2) this is a bizarre problem which others have not encountered nor know what to do about. If (1) above, I sincerely apologize and ask forgiveness, and would urge some kind soul to take pity on me and direct me to the problem solution that I missed in my research. If (2), I guess I'm just going to have to abandon the Cygwin OpenSSH solution and figure out some other approach - perhaps MS telnet service (shudder...). Anybody out there gonna take pity on a poor IT schmuck in need of help? John Fishbeck MSU Physical Plant Computer Systems I want merely the ability to do limited remote WINNT command prompt sys administration tasks without exposing myself to the plain text and implementation vulnerabilities of telent server; i.e., I want to launch /winnt/system32/cmd.exe upon logging in via a SSH client to SSHD on an NT 4.0, SP 6 system. To that end I used the cygwin setup program to download and install from the Internet the openssh package. This process apparently worked correctly, as I can get components, including sshd, running. In fact, launching sshd in debug mode, I can use a ssh client on another machine and successfully (apparently, from the debug trace) authenticate to sshd. However, it looks as though when sshd proceeds to spawn my shell, there is some sort of a process launch/communication failure, with the following debug text emitted from sshd: Accepted password for Administrator from 35.10.77.61 port 1540 ssh2 debug1: Entering interactive session for SSH2. debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 8192 max 8192 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 channel 0 request pty-req reply 0 debug1: Allocating pty. debug1: session_pty_req: session 0 alloc /dev/tty0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 channel 0 request shell reply 0 0 [main] sshd 290 sync_with_child: child 300(0x148) died before initialization with status code 0x80 304 [main] sshd 290 sync_with_child: *** child state waiting for longjmp Disconnecting: fork failed: Resource temporarily unavailable debug1: Calling cleanup 0x414188(0x43e794) debug1: session_pty_cleanup: session 0 release /dev/tty0 debug1: Calling cleanup 0x41eb24(0x0) debug1: channel_free: channel 0: server-session, nchannels 1 debug1: Calling cleanup 0x4169cc(0x0) The /etc/passwd entry for the user I'm logging in as looks like this: Administrator:/c:/c/winnt/system32/cmd.exe and my mount environment looks like: C:\cygwin\bin on /usr/bin type system (textmode) C:\cygwin\lib on /usr/lib type system (textmode) C:\cygwin on / type system (textmode) c: on /c type system (textmode) It appears to me from the debug output that the cmd.exe process does get launched, but then something goes awry, and I have been unsuccessful in resolving this. Can anyone help me with this? I did try to search the archives for references to this problem, but found nothing that seemed to be an exact match to this scenario. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rebase addon - Bas and Size listing of dll's without rebasing
Ralf, On Wed, Dec 26, 2001 at 09:08:49PM +0100, Ralf Habacker wrote: > On analysing this problem I added an option "-l" to the rebase tool to > list dll's imagebase and -size without rebasing. It's very interesting > to see how MS chooses there Imagebase. What about the following alternative solution: $ objdump -p foo.dll | egrep '(ImageBase|SizeOfImage)' ImageBase 6800 SizeOfImage 0003f000 > Because I hacked this very quick, I have used simple FILE structure > and fopen/fread calls. Perhaps someone like to change this to iostream > functionality. At this point, my priorities are: 1. attempt to contribute rebase to binutils 2. work on the integration with setup.exe After the above is completed, then I would entertain adding such an option if the community deemed it appropriate. But, wouldn't implementing it via ReBaseImage()'s fReBase parameter as opposed to plucking certain bytes out of the executable be a better approach? I presume that this is how MS implements their '-s' (just sum image range) option. Jason -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
cron/crontab
Dear Cygwin, I am eager to use cron to automate scripts running under cygwin 1.3.6-6 on Windows Nt 4 Server. I downloaded it with setup.exe and installed it with cygrunsrv. I created a file for my user in /var/cron/tabs. I crontabed it to get things going. I checked to make sure it was running with ps. I even rebooted the server. Furthermore, I did a crontab -l and can view the user's entry. However, cron will not launch the scripts. Here is an example of my crontab. 0 6 * * * D:/scripta 0 6 * * * D:/scriptb Is there something I missed? I need to get this running ASAP. Please advise. P.S. please include a sample crontab(5) entry with user field. man pages were not clear on format Brian Facey -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[Fwd: cron/crontab]
--- Begin Message --- Dear Cygwin, I am eager to use cron to automate scripts running under cygwin 1.3.6-6 on Windows Nt 4 Server. I downloaded it with setup.exe and installed it with cygrunsrv. I created a file for my user in /var/cron/tabs. I crontabed it to get things going. I checked to make sure it was running with ps. I even rebooted the server. Furthermore, I did a crontab -l and can view the user's entry. However, cron will not launch the scripts. Here is an example of my crontab. 0 6 * * * D:/scripta 0 6 * * * D:/scriptb Is there something I missed? I need to get this running ASAP. Please advise. P.S. please include a sample crontab(5) entry with user field. man pages were not clear on format Brian Facey --- End Message --- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Request for update to rsync
I have debugged my problem a little closer. The rsync from cygwin on NT using 2.5.0 works as expected, only copies the updated files. The rsync from cygwin on Windows 98 is not working, it copies every file every time. I am getting the feeling that this bug is not in rsync, but perhaps the way that Windows 98 is getting file attributes ?? Any ideas? -Thanks Stephen More P.S. On the NT box where everyhting works as expected 'make test' says: - overall results: 2 passed 2 failed 1 skipped At 12:37 AM 12/27/01 +0100, Gerrit P. Haase wrote: >Hallo Stephen, > >Am 2001-12-26 um 14:24 schriebst du: > >> When using rsync with cygwin ( 2.4.6 ), my sessions have been hanging. >> rsync 2.5.0 is out and states: > >> BUG FIXES: >> * Fix for various bugs causing rsync to hang. > >> Can someone update the rsync package? > >> I was able to download it, compile it, and run it. But perhaps I missed >> something because it seemed to copy every file, every time. > >What does a `make test' say? >I get this: >- overall results: > 1 passed > 3 failed > 1 skipped > >That doesn't look like no problems. > >Gerrit >-- >=^..^=mailto:[EMAIL PROTECTED] > > > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
New user question
I discovered Cygwin last week and I like what I see so far. I have one question in regards to installing gcc. Can I go with 3.0.3 or do I have to use an older version? This is for installing on Win98 and WinNT 4.0 systems. Bill Gallip CDSA Dam Neck Virginia Beach, VA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: python 2.2
Mark, On Wed, Dec 26, 2001 at 04:59:22PM -0800, Mark McEahern wrote: > Python 2.2 final was released last week. When will > the version that comes with Cygwin be updated? I read the above many times. I even slept on it before responding. Forgive me if I misinterpreted your terse message, but I am offending by the perceived insistence. I will update Cygwin Python to 2.2 when I can get to it. Please remember that I *contribute* Python to the standard Cygwin distribution as a way to give back to the community. If you find that my timeliness does not meet your expectations, then you are always welcome to download the source and build it yourself. Jason -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Can't spawn shell for authenticated user in SSHD (revisited)
I am taking a wild guess- when you ssh in, it spawns a shell and then still does some ssh-ish tasks. Maybe it can't complete them from the command shell. Are you logging in or just firing off remote processes? It might be worth trying to set your shell to /bin/bash, ssh in and see if you can then start a command shell. Maybe- ssh machine "cd /cygdrive/c/path-to-batch-file; cmd /c mytest.bat; sleep 2" (the 'sleep x' might not be necessary with ssh, but it is with rsh if you want all the output from the last command) I don't have sshd running anywhere remotely, but I can rlogin to a machine running inetd, it starts a bash shell, and then I type "cmd" and it gives me a command shell. HTH (or at least spawns some discussion), Peter John Fishbeck wrote: > Hi all, > > I posted the message appended at the end of this one last week, and didn't receive a >_single_ response to it. This leads me to believe that either 1) I have unwittingly >committed some horrendous faux pax, despite the fact that I did attempt to research >this problem before posting to this list, or 2) this is a bizarre problem which >others have not encountered nor know what to do about. > > If (1) above, I sincerely apologize and ask forgiveness, and would urge some kind >soul to take pity on me and direct me to the problem solution that I missed in my >research. If (2), I guess I'm just going to have to abandon the Cygwin OpenSSH >solution and figure out some other approach - perhaps MS telnet service (shudder...). > > Anybody out there gonna take pity on a poor IT schmuck in need of help? > > John Fishbeck > MSU Physical Plant Computer Systems > > > > I want merely the ability to do limited remote WINNT command prompt sys >administration tasks without exposing myself to the plain text and implementation >vulnerabilities of telent server; i.e., I want to launch /winnt/system32/cmd.exe upon >logging in via a SSH client to SSHD on an NT 4.0, SP 6 system. > > To that end I used the cygwin setup program to download and install from the >Internet the openssh package. This process apparently worked correctly, as I can get >components, including sshd, running. In fact, launching sshd in debug mode, I can use >a ssh client on another machine and successfully (apparently, from the debug trace) >authenticate to sshd. However, it looks as though when sshd proceeds to spawn my >shell, there is some sort of a process launch/communication failure, with the >following debug text emitted from sshd: > > Accepted password for Administrator from 35.10.77.61 port 1540 ssh2 > debug1: Entering interactive session for SSH2. > debug1: server_init_dispatch_20 > debug1: server_input_channel_open: ctype session rchan 0 win 8192 max 8192 > debug1: input_session_request > debug1: channel 0: new [server-session] > debug1: session_new: init > debug1: session_new: session 0 > debug1: session_open: channel 0 > debug1: session_open: session 0: link with channel 0 > debug1: server_input_channel_open: confirm session > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 channel 0 request pty-req reply 0 > debug1: Allocating pty. > debug1: session_pty_req: session 0 alloc /dev/tty0 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 channel 0 request shell reply 0 > 0 [main] sshd 290 sync_with_child: child 300(0x148) died before initialization >with status code 0x80 > 304 [main] sshd 290 sync_with_child: *** child state waiting for longjmp > Disconnecting: fork failed: Resource temporarily unavailable > debug1: Calling cleanup 0x414188(0x43e794) > debug1: session_pty_cleanup: session 0 release /dev/tty0 > debug1: Calling cleanup 0x41eb24(0x0) > debug1: channel_free: channel 0: server-session, nchannels 1 > debug1: Calling cleanup 0x4169cc(0x0) > > The /etc/passwd entry for the user I'm logging in as looks like this: > > Administrator:/c:/c/winnt/system32/cmd.exe > > and my mount environment looks like: > > C:\cygwin\bin on /usr/bin type system (textmode) > C:\cygwin\lib on /usr/lib type system (textmode) > C:\cygwin on / type system (textmode) > c: on /c type system (textmode) > > It appears to me from the debug output that the cmd.exe process does get launched, >but then something goes awry, and I have been unsuccessful in resolving this. > > Can anyone help me with this? I did try to search the archives for references to >this problem, but found nothing that seemed to be an exact match to this scenario. > > > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Bug reporting: http://cygwin.com/bugs.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > > -- Your mouse has moved. Windows NT must be restarted for the change to take effect. Reboot now? [OK] -- -- Unsubscribe info:
RE: chmod
Hi, Brian ... > I am using cygwin 1.3.6-6 on Windows NT 4 Server SP 6 and cannot do a > chmod on a file. The permissions just remain the same. I even did a > chmod -v 600 on a file. The output showed that the permissions had > changed. However, when I did an ls -la, the permissions remained the > same. I think you should investigate the CYGWIN environment variable and its value "ntsec" ;-) Greetings from Germany, Th. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: New user question
Only the gcc which comes with cygwin has all the cygwin patches applied. Since you don't specify any requirements which would move you toward a newer version, such as the more modern C++ library, or P4 support, you may not have a good reason for changing. Attempting to build and install gcc without upgrading your OS carries additional risk. - Original Message - From: "Gallip William C DLDN" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, December 27, 2001 10:18 AM Subject: New user question > I discovered Cygwin last week and I like what I see so far. I have one > question in regards to installing gcc. Can I go with 3.0.3 or do I have to > use an older version? This is for installing on Win98 and WinNT 4.0 > systems. > > Bill Gallip > CDSA Dam Neck > Virginia Beach, VA > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Bug reporting: http://cygwin.com/bugs.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ PATCH ] Cygwin groups.t (PLEASE CHECK)
Hallo H,
Am 2001-12-27 um 19:49 schriebst du:
> On Wed 26 Dec 2001 16:55, "Gerrit P. Haase" <[EMAIL PROTECTED]> wrote:
>> Hallo H.Merijn,
>>
>> Am 2001-12-26 um 14:22 schriebst du:
>>
>> > I *do* however feel comfortable with this one. Passes on all my Cygwin systems
>> > both NT and 2k, both English and Dutch. The catch doesn not seem to be true
>> > anymore for modern cygwin systems.
>>
>> > --- t/op/groups.t.org Wed Dec 26 14:14:38 2001
>> > +++ t/op/groups.t Wed Dec 26 14:15:11 2001
>> > @@ -116,11 +116,7 @@
>> >
>> > $pwgid = $( + 0;
>> > ($pwgnam) = getgrgid($pwgid);
>> > -if ($Config{myuname} =~ /^cygwin_nt/i) { # basegroup on CYGWIN_NT has id = 0.
>> > -@basegroup{$pwgid,$pwgnam} = (0,0);
>> > -} else {
>> > -@basegroup{$pwgid,$pwgnam} = (1,1);
>> > -}
>> > +@basegroup{$pwgid,$pwgnam} = (1,1);
>> > $seen{$pwgid}++;
>> >
>> > print "# pwgid = $pwgid, pwgnam = $pwgnam\n";
>>
>> If you setup Cygwin and there are no /etc/passwd and no /etc/group
>> files and (AFAIK) there is no /etc/postinstall/passwd-grp.bat.done
>> file then setup.exe runs /bin/mkpasswd -l and /bin/mkgroup -l and then
>> I get these entries in that files:
>>
>> $ cat /etc/passwd
>> Jeder:*:0:0:,S-1-1-0::
>> SYSTEM:*:18:18:,S-1-5-18::
>> Administratoren:*:544:544:,S-1-5-32-544::
> This is wrong. I admit it happens, but it isn't a user ID it's a group ID, and
> thusly belongs in /etc/group.
>>
>>
>> $ cat /etc/group
>> Jeder:S-1-1-0:0:
>> SYSTEM:S-1-5-18:18:
>> Administratoren:S-1-5-32-544:544:
>>
>>
>>
>> Jeder == Everyone == ...
>> has GID 0 and UID 0 and that was never changed so it makes no difference
>> whether you run cygwin-1.1.8 or 1.3.6.
> What's the influence of using 'login' vs. just starting bash?
Good question. e.g. `id' gives me the same result in both cases.
I don't remember reading about it on the Cygwin list.
We should ask Corinna, she is the `ntsec-queen' :-)
>> This was the cause for the previous patch because it fails
>> if there is checked for UID/GID 1/1.
>>
>> > One down two to go ...
>>
>> I will try to build now and then run both tests.
> I saw your (disappointing) results.
Why disappointing?
We have just different ressults;)
The MM_Cygwin.t failure was patched by chromatic (what a name;)
basic.t isn't failing for me, I don't understand why your warnings.t
doesn't fail...
> Note that there is not a single reason to forbid the user to alter the
> /etc/passwd and /etc/group files. I did it on my work PC to make files
> extracted from tar archives use the same user/group names as on my unix
> systems
Well, if one changes his /etc/group or /etc/passwd file then the test may
fail, I have no problems with this.
> Differences I noted when tracing this fail
> - gid (with name) did not appear in groups=
> - different gID's with same name
> - double gID's (with name) in groups=
> One of the systems is a fresh install, no /etc/* tweakage, and I do not use
> login. Just a plain bash.exe shortcut
The default shortcut is one to x:\cygwin\cygwin.bat and there bash
is called with `--login -i'.
That is supported, if you modify the shortcut to point directely
to bash then you have the choice: use --login -i here as well
or don't use it, but we can only support one version.
It should run clean without changing something and if one changes
the default setup he should be prepared that there nay be some more
faults then.
> Why does my patch succeed on all my systems (NT and 2k), but fails on yours.
Hmmm, I use a shortcut: `bash --login -i' to start the shell,
this is the default in a fresh installed Cygwin. Maybe it is
not the best way to use Cygwin and bash, but it is the default.
I never changed the basic entries in the /etc/files, only added
some users/groups now and then.
Gerrit
--
=^..^=mailto:[EMAIL PROTECTED]
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Expect hanging on long "send" commands
I'm working on an SNMP agent and have written an expect script to
simplify using the test SNMP manager provided by our vendor. However,
I ran into problems whenever the "send" string was long (to avoid any
proprietary issues, I've sanitized the names of the command and the
variables, but the length of each one is the same):
-re "^ *cmdName +(.+) +(.+) +(.+) +(\[0-9]+) *\[\n\r]+" {
send "set a.0 $s\
.0 $c\
cc.0 $j\
d.0 1\
.0 \"$expect_out(1,string)\"\
ff.0 \"$expect_out(2,string)\"\
g.0 \"$expect_out(3,string)\"\
hh.0 $expect_out(4,string)\r"
dump_output
}
Then the script would just hang and never come back. Using
"exp_internal 1" provided this information:
send: sending "set a.0 101 .0 11 ccc
ccc.0 1 d.0 1 .0 "A" ff.0 "B" gg
ggg.0 "C" hh.0 1\r" to { 4
I verified that the test manager's input buffer was big enough and
that the "set" command succeeded if entered into the test manager
running outside of expect. I then verified that the command succeeded
under expect if entered in manually using the "interact" command.
After further experimentation, I discovered that the command would
succeed if I added the following kludge:
-re "^ *cmdName +(.+) +(.+) +(.+) +(\[0-9]+) *\[\n\r]+" {
send "set a.0 $s\
.0 $c\
cc.0 $j\
d.0 1\
.0 \"$expect_out(1,string)\""
send_user "...Press ..."
expect_user -re ".*\[\r\n]+"
send "ff.0 \"$expect_out(2,string)\"\
g.0 \"$expect_out(3,string)\"\
hh.0 $expect_out(4,string)\r"
dump_output
}
The longest "set" command in the script had to be broken up into four
chunks (three user prompts) to work reliably.
A severely pruned version of my "cygcheck" dump:
Windows NT Ver 4.0 Build 1381 Service Pack 6
Cygwin DLL version info:
DLL version: 1.3.6
Build date: Sat Dec 8 17:02:30 EST 2001
Package Version
expect 20010117-1
tcltk 20001125-1
This issue isn't critical for me, since I've found a workaround. I
just thought I'd let you know. Thanks.
--
Bradley Holdridge
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: python 2.2
Jason, I am sorry that my message seemed insistent to you. That was certainly not intended. I posted out of complete ignorance of how Python was updated in the Cygwin distribution--by whom, under what circumstances, schedule, etc. I appreciate your generous efforts and am very thankful for Python's inclusion in the Cygwin distribution. My apologies, // mark --- Jason Tishler <[EMAIL PROTECTED]> wrote: > Mark, > > On Wed, Dec 26, 2001 at 04:59:22PM -0800, Mark > McEahern wrote: > > Python 2.2 final was released last week. When > will > > the version that comes with Cygwin be updated? > > I read the above many times. I even slept on it > before responding. > Forgive me if I misinterpreted your terse message, > but I am offending > by the perceived insistence. > > I will update Cygwin Python to 2.2 when I can get to > it. Please remember > that I *contribute* Python to the standard Cygwin > distribution as a > way to give back to the community. If you find that > my timeliness does > not meet your expectations, then you are always > welcome to download the > source and build it yourself. > > Jason __ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rebase addon - Bas and Size listing of dll's without rebasing
=== - Original Message - From: "Jason Tishler" <[EMAIL PROTECTED]> > After the above is completed, then I would entertain adding such an > option if the community deemed it appropriate. But, wouldn't > implementing it via ReBaseImage()'s fReBase parameter as opposed to > plucking certain bytes out of the executable be a better approach? I > presume that this is how MS implements their '-s' (just sum image range) > option. IMO we should be using bfd not the MS helper libraries - in the long term. Otherwise one cannot do any of this as part of a cross compile or cross-manipulation toolkit. Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Starting program under bash as Scheduled Task
I would like to create a Windows 2000 Scheduled Task. This task is a shell script that requires environment variables set within my .bashrc. Is there any way to run bash (to set the environment variables) followed immediately by the shell script from a scheduled task or, similarly, from a desktop icon? Thanks for the help. Scott "Just a mirror for the sun... My smiling eyes are just a mirror for the sun." -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Potential problems with Cygwin GCC and -mno-cygwin switch
Sorry Chris... just some final words... > -Original Message- > From: Robert Collins [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 27, 2001 5:28 AM > To: Jon Leichter; [EMAIL PROTECTED] > Subject: Re: Potential problems with Cygwin GCC and -mno-cygwin switch > > > 3) There's a problem with Cygwin-specific libraries residing in > >/usr/lib. ... I, of course, updated the specs file to accomodate > >this. My environment now works flawlessly. When OpenLDAP > >looks for libncurses, it doesn't find it, as it shouldn't. > > This seems like an interesting approach. I wonder if anything would get > broken by it (other than ALL the existing packages that provide > libraries :}). Most libraries included with packages install in /usr/local/lib (opposed to /usr/lib). As for libraries that it may depend upon, as long as my GCC specs file knows where to find libraries, I don't see a problem. > > I wonder if anyone else thinks it would be a good idea to relocate > > Cygwin > > I think this may be easier than fixing gcc, but I'm sure that fixing gcc > is a better long term approach. However as I don't have the time nor > inclination to fix gcc myself, my opinion is just that. > Not only is relocating easier, but it's the only current solution to this particular situation. However, I FULLY agree that the CORRECT solution is to "enhance" gcc, perhaps to have it honor a switch (e.g. -nostdlibdirs) which will cause it to ignore the hard-coded standard default directories, i.e. /usr/lib and /lib (which are one and the same in Cygwin). Since I won't be submitting this proposed patch either, this is all just my opinion as well... Jon -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Potential problems with Cygwin GCC and -mno-cygwin switch
- Original Message - From: "Jon Leichter" <[EMAIL PROTECTED]> > Most libraries included with packages install in /usr/local/lib (opposed to > /usr/lib). As for libraries that it may depend upon, as long as my GCC specs > file knows where to find libraries, I don't see a problem. Please check your facts before making assertions. === $ ls -lR /usr/local/lib/ /usr/local/lib/: total 0 drwxrwxrwx2 Administ None0 Dec 27 22:00 pkgconfig /usr/local/lib/pkgconfig: total 0 === I have nearly every package provided by cygwin installed, and as you can see, the libraries are not installed in /usr/local/lib. Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Potential problems with Cygwin GCC and -mno-cygwin switch
Ok... you got me... One problem with cyberspace communication is how two (or more) people can be talking about the same topic but are on different pages (metaphorically, of course)... :) What I was talking about is packages that you download and build yourself, e.g. GNU regex, GNU libtool, GDBM, OpenLDAP: all of these packages configure with a default prefix of /usr/local. I was not talking about pre-packaged Cygwin binaries. And I still claim that even after you install Cygwin packages, they will operate if you relocate the libraries in /usr/lib. This is because the Cygwin binaries depend on DLLs accessible via the PATH, which are NOT relocated from /usr/bin. Jon > -Original Message- > From: Robert Collins [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 27, 2001 6:23 PM > To: Jon Leichter > Cc: [EMAIL PROTECTED] > Subject: Re: Potential problems with Cygwin GCC and -mno-cygwin switch > > - Original Message - > From: "Jon Leichter" <[EMAIL PROTECTED]> > > Most libraries included with packages install in /usr/local/lib > (opposed to > > /usr/lib). As for libraries that it may depend upon, as long as my GCC > specs > > file knows where to find libraries, I don't see a problem. > > Please check your facts before making assertions. > === > $ ls -lR /usr/local/lib/ > /usr/local/lib/: > total 0 > drwxrwxrwx2 Administ None0 Dec 27 22:00 pkgconfig > > /usr/local/lib/pkgconfig: > total 0 > === > > I have nearly every package provided by cygwin installed, and as you can > see, the libraries are not installed in /usr/local/lib. > > Rob > > > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Potential problems with Cygwin GCC and -mno-cygwin switch
- Original Message - From: "Jon Leichter" <[EMAIL PROTECTED]> > I was not talking about pre-packaged Cygwin binaries. And I still claim that > even after you install Cygwin packages, they will operate if you relocate > the libraries in /usr/lib. This is because the Cygwin binaries depend on > DLLs accessible via the PATH, which are NOT relocated from /usr/bin. However , once gcc's specs are changedm linking with the libraries they provide will fail - which is what I was talking about. (Until every package gets repackaged, at a significant time cost to the package maintainers). And as this would be (at best) an interim fix until gcc is corrected, I for one do not support implementing this - the time cost would get gcc fixed many times over. Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: python 2.2
Mark, On Thu, Dec 27, 2001 at 04:04:06PM -0800, Mark McEahern wrote: > My apologies, Apology accepted. Thanks, Jason -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Potential problems with Cygwin GCC and -mno-cygwin switch
> -Original Message- > From: Robert Collins [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 27, 2001 6:35 PM > To: Jon Leichter > Cc: [EMAIL PROTECTED] > Subject: Re: Potential problems with Cygwin GCC and -mno-cygwin switch > > However , once gcc's specs are changedm linking with the libraries they > provide will fail - which is what I was talking about. Hmm... I'm not sure why this would be the case. I have relocated my libraries, and I have updated my specs file. Things work just fine for me (or it seems). I wonder if you could elaborate your assertion with an example. (I don't want to upset Chris Faylor - is this something we should discuss off the mailing list?) > (Until every > package gets repackaged, at a significant time cost to the package > maintainers). > > And as this would be (at best) an interim fix until gcc is corrected, I > for one do not support implementing this - the time cost would get gcc > fixed many times over. > > Rob Based on the conversation we've been having, I no longer think this is a general good idea either. I stated this is a previous email. I agree that the right solution is to "correct" gcc. The relocation that I have done merely serves as an interim solution for me. Jon -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: printing in cygwin
Jeff,
On Thu, Dec 27, 2001 at 02:02:45PM -0800, Jeff Lu wrote:
> I was able to print to a network printer in cygwin in my C program for a
> while. It just stops printing for no reason and I couldn't figure it out
> why.
>
> The network printer is //host_1/printer_1
>
> In my C program:
>
> prn = fopen("//host_1/printer_1", "wb");
> fwrite(buffer, sizeof(char), strlen(buffer), prn);
> fclose(prn);
>
> Do you have any suggestion?
Post to [EMAIL PROTECTED] Sorry, but I have never tried to print via a
C program under Cygwin.
Jason
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Potential problems with cygwin GCC and -mno-cygwin switch
On Thu, Dec 27, 2001 at 06:46:25PM -0800, Jon Leichter wrote: >>From: Robert Collins [mailto:[EMAIL PROTECTED]] >>However , once gcc's specs are changed linking with the libraries they >>provide will fail - which is what I was talking about. > >Hmm... I'm not sure why this would be the case. I have relocated my >libraries, and I have updated my specs file. Things work just fine for >me (or it seems). I wonder if you could elaborate your assertion with >an example. (I don't want to upset Chris Faylor - is this something we >should discuss off the mailing list?) I'm not a censor. If you are discussing something that deals with cygwin feel free to do it here. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Potential problems with Cygwin GCC and -mno-cygwin switch
- Original Message - From: "Jon Leichter" <[EMAIL PROTECTED]> > > However , once gcc's specs are changedm linking with the libraries they > > provide will fail - which is what I was talking about. > > Hmm... I'm not sure why this would be the case. I have relocated my > libraries, and I have updated my specs file. Things work just fine for me > (or it seems). I wonder if you could elaborate your assertion with an > example. (I don't want to upset Chris Faylor - is this something we should > discuss off the mailing list?) It's an onlist topic. Because the two things have to happen concurrently. Cygwin has over a 100 packages, of which maybe 40 provide libraries that would need to be relocated. The mechanism for relocation is quite simple: every package maintainer repackages their package with the libraries in the new location. > The relocation that I have done merely serves as an interim solution for me. Exactly. Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Potential problems with Cygwin GCC and -mno-cygwin switch
> - Original Message - > From: "Jon Leichter" <[EMAIL PROTECTED]> > > > However , once gcc's specs are changedm linking with the libraries > they > > > provide will fail - which is what I was talking about. > > > > Hmm... I'm not sure why this would be the case. I have relocated my > > libraries, and I have updated my specs file. Things work just fine for > me > > (or it seems). I wonder if you could elaborate your assertion with an > > example. (I don't want to upset Chris Faylor - is this something we > should > > discuss off the mailing list?) > > It's an onlist topic. > Because the two things have to happen concurrently. Cygwin has over a > 100 packages, of which maybe 40 provide libraries that would need to be > relocated. The mechanism for relocation is quite simple: every package > maintainer repackages their package with the libraries in the new > location. I think I understand what you're saying now. The wording in your previous email threw me off. I'm not sure the two things have to happen concurrently. If the GCC specs file were to change first, then GCC would start looking in /usr/lib/cygwin, and it would continue to look in (the hard-coded path) /usr/lib, where old package libraries would still reside. Also, I'm not sure that all packages need to be relocated. Just the ones that place files in /usr/lib. There is no problem with a package that places files in a subdirectory of /usr/lib. At this point, this conversation is purely hypothetical... :) I really don't think 100 packages should should be re-packaged... Jon -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
