Maintainers of CURL, MUTT, PYTHON and WGET, heads up!
=== == == == IMPORTANT== == == === Hi, I'm going to update OpenSSL from version 0.9.6b to version 0.9.6c very soon now, probably next Sunday. You as the maintainers of the packages who depend on OpenSSL should check, if the existing binary packages will still run when I upgrade. The reasons I'm asking are - the fifth package depending on OpenSSL, OpenSSH, would have been broken by an upgrade. That's the reason I've uploaded a new version of OpenSSH a few hours ago. - The next OpenSSL binary package will not include support for two crypto algorithms which still have licensing problems in some contries, IDEA and RC5. So I'd like to ask you to check if your packages will still run with an patchlevel upgrade of OpenSSL. Otherwise I'd suggest to patch the code which checks the OpenSSL version (if any). The version of OpenSSL is returned by the function SSLeay(). It returns a hex number with the format MMNNFFPPS: M = major, N = minor, F = fix, p = patch, s = status. Accordingly the release version 0.9.6b returns SSLeay() = 0x00090602f == 0 9 6 b and f=release the release version 0.9.6c returns SSLeay() = 0x00090602f == 0 9 6 c f=release Description is in `man 3 OPENSSL_VERSION_NUMBER'. The situation in OpenSSH was, OpenSSH-3.0.2p1 unfortunately checks for exact equality against the version number of OpenSSL which is linked against: if ((SSLeay() != OPENSSL_VERSION_NUMBER) exit The current CVS version of OpenSSH contains a patch which checks for the version but w/o checking for the patch level: if ((SSLeay() ^ OPENSSL_VERSION_NUMBER) ~0xff0L) exit I patched OpenSSH-3.0.2p1-4 so that it also uses that test. This version will have no problem when I upgrade to OpenSSL-0.9.6c. Please make sure that your package will still run next Sunday. I'm not going to use a different name for the DLL since it's not a version upgrade, just a patchlevel upgrade. The shared libs on U*X systems would still use the same name either (libcrypto.0.9.6.so, libssl.0.9.6.so). The next point is, please check if your packages depend on either the IDEA or the RC5 algorithms. If so, please rebuild w/o that dependency. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
On Mon, Jan 14, 2002 at 09:23:46PM +1100, Robert Collins wrote: === - Original Message - From: Charles Wilson [EMAIL PROTECTED] Hmmm...I must spend too much time with computers. My human brain parsed tetex-beta-20001218-2 as tetex-beta 20001218 2. You have been using tetex as an example of how setup/upset *misparses* a string, while I thought it was a perfect example of good parsing. :-) otflwmmf. wslpfrmpft? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: Maintainers of CURL, MUTT, PYTHON and WGET, heads up!
On Mon, Jan 14, 2002 at 09:33:40PM +1100, Robert Collins wrote: === - Original Message - From: Corinna Vinschen [EMAIL PROTECTED] To: cygapp [EMAIL PROTECTED] Sent: Monday, January 14, 2002 9:26 PM Subject: Maintainers of CURL, MUTT, PYTHON and WGET, heads up! === == == == IMPORTANT== == == === Hi, I'm going to update OpenSSL from version 0.9.6b to version 0.9.6c very soon now, probably next Sunday. ... Can I suggest you tag this as a test, for a few days, to allow the maintainers to check w/o affecting any end users. Sure. Probably from tomorrow on. I've just got a hint from a collegue to exclude the MDC2 algorithm as well. The OpenSSL distro in Cygwin would then exclude the exact same crypto algorithms as the RH Linux distro. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: Maintainers of CURL, MUTT, PYTHON and WGET, heads up!
Corinna, On Mon, Jan 14, 2002 at 02:13:04PM +0100, Corinna Vinschen wrote: I've just uploaded a PRELIMINARY version of OpenSSL-0.9.6c. It's marked as a test version for setup. I'll not announce it. Please test your packages against that version. It's already build omitting the IDEA, RC5 and MDC2 crypto algorithms. I ran Python's test_socket_ssl regression test with the above installed and it still passes. I also grep-ed Python's socket module for SSLeay() and no lines matched, so I will assume that this module is version independent. Jason
Preliminary patch for symlink problem in setup.exe
I've found a problem in setup.exe which potentially results in
two symlinks with the same name.
As you know, the default setting for symlinks in Cygwin is using
Windows shortcuts while setup.exe always creates symlinks as
the old-style system files.
Now imagine the following simple situation
- Delete /usr/bin/slogin by mistake.
- Recreate /usr/sbin/slogin with ln(1) creates a Windows shortcut
/usr/sbin/slogin.lnk.
- A new OpenSSH package is downloaded using setup.exe.
Now look into the /usr/bin directory. You will find two files,
`slogin' and `slogin.lnk'.
The following patch is a quick hack which I'd like to get reviewed
by the active setup contributors (not me).
The additional advantage of that patch is that it alleviates the
problem that setup complains when a file couldn't be installed
because the file already exists and couldn't be unlinked before.
That happens mostly when the R/O file attribute is set since
DeleteFile() fails then.
Oh, and I'm using the new INVALID_FILE_ATTRIBUTES define which
I found in the latest MSDN (surprise, surprise) and which
substitutes all prior ((DWORD) -1) or 0x constants
to mark the return code of GetFileAttributes() for ... yeah, you
guessed it, invalid file attributes.
Corinna
2002-01-14 Corinna Vinschen [EMAIL PROTECTED]
* package_meta.cc (packagemeta::uninstall): Uninstall a file
even with trailing .lnk. Unset R/O file attribute before
trying to delete file.
Index: package_meta.cc
===
RCS file: /cvs/src/src/winsup/cinstall/package_meta.cc,v
retrieving revision 2.11
diff -u -p -r2.11 package_meta.cc
--- package_meta.cc 2002/01/06 11:31:47 2.11
+++ package_meta.cc 2002/01/14 21:08:44
@@ -120,11 +120,22 @@ packagemeta::uninstall ()
{
dirs.add_subdirs (line);
+ char buf[512];
char *d = cygpath (/, line, NULL);
+
DWORD dw = GetFileAttributes (d);
- if (dw != 0x !(dw FILE_ATTRIBUTE_DIRECTORY))
+ if (dw == INVALID_FILE_ATTRIBUTES)
{
+ /* Check for Windows shortcut. */
+ strcpy (buf, d);
+ strcat (buf, .lnk);
+ d = buf;
+ dw = GetFileAttributes (d);
+ }
+ if (dw != INVALID_FILE_ATTRIBUTES !(dw FILE_ATTRIBUTE_DIRECTORY))
+ {
log (LOG_BABBLE, unlink %s, d);
+ SetFileAttributes (d, dw ~FILE_ATTRIBUTE_READONLY);
DeleteFile (d);
}
line = installed-getnextfile ();
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.
Re: cygpath patch
--- Charles Wilson [EMAIL PROTECTED] wrote: Joshua Franklin wrote: --- Charles Wilson [EMAIL PROTECTED] wrote: Sounds like a great idea to me. Note however, than symbolic links are implemented using windows shortcuts, so: ln -s foo.html `cygpatch -P`/foo_help.html will do what you want. Huh? That was my example. Except with the desktop directory, and I used $(...) instead of `...` Fine fine fine. The point of my example was really unrelated to the cygpath command itself. You were talking about grabbing code from setup.exe to assist in create a shortcut, or something -- I dunno exactly 'cause I've deleted the message. My point was merely that you DON'T need to worry about that. Just use the 'ln -s' command -- because symbolic links == windows shortcuts. --Chuck Ah. But what if you want to link to: rxvt.exe -rv -fn FixedSys -e /bin/bash --login -i --or-- command.com /E:4096 /c bash.exe --login -i from the working directory c:\cygwin\bin --or-- http://www.cygwin.com/FAQ/ My point is, there are a lot more possible options in W32 shortcuts that seem to be supported by the setup.exe mklink2.c COM interface. __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/
Setup.exe: / prefix on symlinks
Mainly a heads-up for you Rob: I'm getting bad symlinks now with the latest setup.exe. They end up looking like this: ... lrwxrwxrwx1 Gary_VS None 21 Dec 27 00:36 etags.exe - /ctags.exe ... The / of course leads to all manner of havoc. This is the earliest one I see here. -- Gary R. Van Sickle Brewer. Patriot.
Re: xwinclip authorisation problem with remote hosts using XDMCP
What is your DISPLAY variable set to? I am a bit confused, since one output talks about a server going to 127.0.0.1:3.0 . If your X server is on :0, xwinclip will never be able to connect, regardless of the authorities. Will other local X programs run? xterm, xeyes, xwininfo, etc? Brian --- Matthew Donald [EMAIL PROTECTED] wrote: Hi, There is a problem when using xwinclip with an X server which connects to a remote host using XDMCP. Basically the sequence is this: 1. Execute XWin :0 -query some.host.system. Initially, the authorisation file contains no records, so the localhost has access to the X server by default. I quote from the Xserver man page: If this file contains any authorization records, the local host is not automatically allowed access to the server, and only clients which send one of the authorization records contained in the file in the connection setup information will be allowed access. 2. XDMCP is used to query some.host.system, which then opens a connection to the local PC. The first thing done is that XDMCP adds an auth record for some.host.system This means that localhost loses access to the X server. 3. After XWin starts, xwinclip executes on the local host. It fails with the error message: Could not open display Ok, so I added an xhost command, to explicitly allow access: xhost +127.0.0.1 I failed with the error messages: Xlib: connection to 127.0.0.1:0.0 refused by server Xlib: Client is not authorized to connect to Server I read some more about host access, and I created a /etc/X0.hosts file, and I deleted the .Xauthority file. This caused a different error. XWin failed with the message: X connection to 127.0.0.1:3.0 broken (explicit kill or server shutdown). I tried running XWin with the '-ac' command line parameter. This is meant to open access to all hosts. Xwinclip still couldn't open the display. If XWin is used with a local window manager, this xwinclip (and any other client program which runs on the PC) will run sucessfully. However, if XDMCP is used to connect to another system, then it fails. I'm completely stuck. Any help would be very appreciated. regards Matthew __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/
$B$*855$$G$9$+(B
$B2K$D$V$7$K$I$&$>(B http://www.mailland.tv
RE: Building Enlightenment
Sure, I will put add to URL Suhaib -Original Message- From: Ralf Habacker [mailto:[EMAIL PROTECTED]] Sent: Monday, January 14, 2002 5:19 PM To: Cygwin-Xfree Subject: Building Enlightenment Hi Suhaib, it is interesting for the xfree people to have a link to a patched libxext relating to this thread http://sources.redhat.com/ml/cygwin-xfree/2001-q2/msg01466.html? If so I would send a mail to the cygwin-xfree list with a link to the kde-cygwin project on sourcforge, where one can find such a lib. Ralf
RE: Building Enlightenment
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Suhaib Siddiqi Sent: Monday, January 14, 2002 11:23 PM To: 'Cygwin-Xfree' Subject: RE: Building Enlightenment Sure, I will put add to URL This is the url to the downloadpage http://sourceforge.net/project/showfiles.php?group_id=27249 The package is currently named kde-xlib-1.1.tar.gz and contains libXext and libICE (missing ICEConnectionNumber symbol) and based on the xfree 4.1 release. The release number my be changed If the libICE in this package is a problem, let me know. Ralf Suhaib -Original Message- From: Ralf Habacker [mailto:[EMAIL PROTECTED]] Sent: Monday, January 14, 2002 5:19 PM To: Cygwin-Xfree Subject: Building Enlightenment Hi Suhaib, it is interesting for the xfree people to have a link to a patched libxext relating to this thread http://sources.redhat.com/ml/cygwin-xfree/2001-q2/msg01466.html? If so I would send a mail to the cygwin-xfree list with a link to the kde-cygwin project on sourcforge, where one can find such a lib. Ralf
RE: Building Enlightenment
Sure, I will put add to URL This is the url to the downloadpage http://sourceforge.net/project/showfiles.php?group_id=27249 The package is currently named kde-xlib-1.1.tar.gz and contains libXext and libICE (missing ICEConnectionNumber symbol) ^^ Ups. This is not right. It is IceLastMajorOpcode, that is missing. Index: ICE-def.cpp === RCS file: /cvs/xc/lib/ICE/ICE-def.cpp,v retrieving revision 1.5 diff -u -b -B -r1.5 ICE-def.cpp --- ICE-def.cpp 2001/04/18 16:13:18 1.5 +++ ICE-def.cpp 2002/01/14 23:00:34 @@ -69,6 +69,7 @@ _IceTransGetConnectionNumber _IceTransRead _IceTransWrite + _IceLastMajorOpcode /* $Xorg: ICE-def.cpp,v 1.3 2000/08/21 16:42:31 coskrey Exp $ */ /* $XFree86: xc/lib/ICE/ICE-def.cpp,v 1.5 2001/04/18 16:13:18 dawes Exp $ */ If the libICE in this package is a problem, let me know. Ralf Suhaib -Original Message- From: Ralf Habacker [mailto:[EMAIL PROTECTED]] Sent: Monday, January 14, 2002 5:19 PM To: Cygwin-Xfree Subject: Building Enlightenment Hi Suhaib, it is interesting for the xfree people to have a link to a patched libxext relating to this thread http://sources.redhat.com/ml/cygwin-xfree/2001-q2/msg01466.html? If so I would send a mail to the cygwin-xfree list with a link to the kde-cygwin project on sourcforge, where one can find such a lib. Ralf
Re: xwinclip authorisation problem with remote hosts using XDMCP
Hi Brian, The DISPLAY variable is set to 127.0.0.1:0 The .3 value is a typo. My previous tests were showing that xwinclip always failed to open the display. This time, I waited until the kdm logon screen was displayed. Provided that the localhost was specified in /etc/X0.hosts, xwinclip would run. Clearly, there is a timing problem here. I added a 30 second delay (some kludges really make me gag :-) and xwinclip runs sucessfully. Does anyone know why xterm waits for the server while xwinclip doesn't? regards Matthew - Original Message - From: Brian Genisio [EMAIL PROTECTED] To: Matthew Donald [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, January 15, 2002 6:25 AM Subject: Re: xwinclip authorisation problem with remote hosts using XDMCP What is your DISPLAY variable set to? I am a bit confused, since one output talks about a server going to 127.0.0.1:3.0 . If your X server is on :0, xwinclip will never be able to connect, regardless of the authorities. Will other local X programs run? xterm, xeyes, xwininfo, etc? Brian --- Matthew Donald [EMAIL PROTECTED] wrote: Hi, There is a problem when using xwinclip with an X server which connects to a remote host using XDMCP. Basically the sequence is this: 1. Execute XWin :0 -query some.host.system. Initially, the authorisation file contains no records, so the localhost has access to the X server by default. I quote from the Xserver man page: If this file contains any authorization records, the local host is not automatically allowed access to the server, and only clients which send one of the authorization records contained in the file in the connection setup information will be allowed access. 2. XDMCP is used to query some.host.system, which then opens a connection to the local PC. The first thing done is that XDMCP adds an auth record for some.host.system This means that localhost loses access to the X server. 3. After XWin starts, xwinclip executes on the local host. It fails with the error message: Could not open display Ok, so I added an xhost command, to explicitly allow access: xhost +127.0.0.1 I failed with the error messages: Xlib: connection to 127.0.0.1:0.0 refused by server Xlib: Client is not authorized to connect to Server I read some more about host access, and I created a /etc/X0.hosts file, and I deleted the .Xauthority file. This caused a different error. XWin failed with the message: X connection to 127.0.0.1:3.0 broken (explicit kill or server shutdown). I tried running XWin with the '-ac' command line parameter. This is meant to open access to all hosts. Xwinclip still couldn't open the display. If XWin is used with a local window manager, this xwinclip (and any other client program which runs on the PC) will run sucessfully. However, if XDMCP is used to connect to another system, then it fails. I'm completely stuck. Any help would be very appreciated. regards Matthew __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/
RE: [ANNOUNCEMENT] Updated: readline-4.2a-1
From: Charles Wilson [mailto:[EMAIL PROTECTED]] Note to python, postgres, and units maintainers: Binaries within your packages are linked against cygreadline5.dll. I have taken the following actions: units: didn't include readline in the requires: field (although it should have done so). I added 'libreadline5' so everything should now be fine. Sorry, thanks. I'll update my copy of setup.hint so the next version should be OK too. J. === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF -- 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: Proposed Mailing List Page Reorg
- Original Message - From: Soren Andersen [EMAIL PROTECTED] Sent: Monday, January 14, 2002 3:17 PM - can one safely assume that a noobie who finds Cygwin grasps that the tools that are packed with cygwin (bash, login, man, for example) aren't specific to Cygwin at all but long predate it, and Can we? The newbie who finds cygwin because they are told to by a friend, may not have any unix background, and therefore see *nothing* to cause them to realise that the tools come from elsewhere - particularly Win32 users, where MS provide *everything* (or so they may think). - can one safely assume that noobies will think these tools that i am given with Cygwin run the same 'on cygwin' as they do on any Uni* -like platform (and therefore general documentation 'out there' will apply too), From experience on this list, I can assert that this is an unsafe assumption. Many many many questions are asked that are solveable by simple examination of existing documentation - like the recent lex-flex question (while I didn't know that answer, that's gotta be a flex FAQ!). and - can one safely assume that noobies who might even guess at the first two points might not think anyway that maybe I'll find friendlier, more sympathetic folks to hold my trembling timorous hand here, than I would if I ventured onto onto the Wierd Wild Web in search of generalized help on these tools? (Point of this last is not to characterize the cygwin list as nasty or to propose that it self-characterize this way, but to suggest that a LITTLE warning of a slightly stern-sounding nature at the front door might be expeditious and appropriate given that folks on this list BAL [By And Large] clearly DON'T want anymore to answer questions like what does man do or how do I login to bash). Good point. Unless there is one single extremely knowledgeable and encyclopedically- oriented person who knows where to send people (and such people do exist I think, but whether one will care to undertake this is another question) then I think that a little project (or a little coordinated multi-person collaboration, for lovers of ornate terminology!) needs to be created to develop and verify a list of resources to send such visitors to. The task (of writing up re-directions for some of these categories or inquiries) can be done once, -- to set up more precise explanations and info at the site; or it can be done as its been done, repeated over and over again as similar questions appear on the list and are answered one at a time. I can make an assertion here: contribute patches. Contribute the links *you know* (come on' after more than a years use you must have collected a few useful links). Don't worry about whether they are the best links, that's what open source doco is for! If *you* don't, and noone else *does*, then nothing will happen, and in 6 months Chris will say I've been cogitating... As a side note: Perhaps we can have a homepage link in setup.ini (and thus the package listing too) for each package? 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: Proposed Mailing List Page Reorg
On Monday 14 Jan 02, Robert Collins writes: The task (of writing up re-directions for some of these categories or inquiries) can be done once, -- to set up more precise explanations and info at the site; or it can be done as its been done, repeated over and over again as similar questions appear on the list and are answered one at a time. I can make an assertion here: contribute patches. Contribute the links *you know* (come on' after more than a years use you must have collected a few useful links). Don't worry about whether they are the best links, that's what open source doco is for! If *you* don't, and noone else *does*, then nothing will happen, and in 6 months Chris will say I've been cogitating... As you might expect, this has come up before. I would consider devoting space in the FAQ for pointers to basic UNIX resources. However, I'm not the person to locate the resources or judge which are suitable and which are crap. (After 20 years of UNIX, my skills are such that man pages and google are enough!) If someone can distill a few good resource pointers, I'll provide an item in the FAQ for them. That is, when I get my home internet connection working... :-( Regards, David (Cygwin FAQ maintainer) -- 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: Compiling apps to Mingw32 with cygwin
Robert Collins wrote: - Original Message - From: Earnie Boyd [EMAIL PROTECTED] 1) `gcc -mno-cygwin' is not a cross compile. 2) it is possible to emulate a cross build system using a scripted `gcc -mno-cygwin' and symlinks. 3) `gcc -mno-cygwin' switches the build environment from Cygwin to MinGW. Earnie, on 3) I believe we have a terminology problem. gcc -mno-cygwin changes the _build target_ to mingw32, no the build _environment_. In the context of configure scripts the build _environment_ is the platform hosting the running script, and doing the compilation - that is cygwin. You need to narrow your thinking to GCC and binutils the processes of consequence. You only need to specify the triplet because config.guess guesses wrong based on the value of `uname -s'. The cygwin binutils as named will produce executables that use MSVCRT.DLL instead of CYGWIN1.DLL without having to do anything special with their names or output. So, my statement stands based on what happens with GCC, you're switching the build environment. You said this was wrong. To be consisent with future behavior, it seems that I must specify build. So if you're suggesting that I'm not cross-compiling, then it would be: $ env CC=mgcc ./configure --host=i686-pc-mingw32 --build=i686-pc-mingw32 This is what I would do. IMO this is wrong (wrong build value) - see my comment earlier. No, you're not doing a cross build, therefore I've stated the correct switches. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.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/
Problem with cygwin.bat
Sorry for this stupid question,
but I did not find a way to solve the problem myself. I work with
Windows NT 4.0 SP 6a and the actual cygwin (just some minutes ago
updated) distribution.
Some weeks ago, I changed the way, windows reacts when I click onto
a desktop-icon which stands for a .bat file. (I forgot the rule:
Never change a running system) Now every time i click onto the
cygwin-icon, a normal dos-windows opens with the Prompt:
C:\WINNT\Profiles\ponnath\Desktop
Before I did the change, the cygwin shell opened with my home
directory as prompt. OK, I change into C:\cygwin and run cygwin.bat
- but doing this is not the best way to solve the problem.
I dont know how to change back to the usual behaviour.
I think, I misconfigured something in the options part of windows
explorer. For .bat Files there are now the following entries (I try
to translate from german) there:
Description: batch processing file for MS-DOS
MIME-type : empty
standard-ending for this type: empty
actions:
open
print
For open the edit-card shows:
action: open
program for this action: C:\WINNT\system32\Cmd.exe[%1]
Use DDE: empty
For print the edit-card shows:
action: print
program for this action: L:\PROGRAMME\UEDIT32.EXE/p%1
Use DDE: marked
DDE message: [print{%1}]
program: UEDIT32
DDE program not active: empty
Theme: System
I think, the solution must be somewhere in the configuration of the
open properties. But I have no idea, what is wrong and how to
reconfigure it.
I hope, you can help me. Best wishes
Heimo
--
Heimo Ponnath Webdesign, Rotenhäuserstr. 51, 21109 Hamburg
Tel: 040-753 47 95,Fax: 040-752 68 03, http://www.heimo.de/
--
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: Compiling apps to Mingw32 with cygwin
Jon Leichter wrote: Using Robert's invocation WOULD put configure in cross-compile mode. But since using Cygwin GCC to generate MinGW is ALMOST like a cross-compile, it will work out ok. In fact, one compelling reason to use Robert's method is because one wants the configure script to use the correct build tools, e.g. cp instead of copy, rm instead of del, etc. I tend to agree that the build environment IS Cygwin for this very reason. You're not going to switch the tools from cp to copy or rm to del by doing as I suggest. You would have to buggle (use unnecessary conditions) the Makefile.in to do that. So here's a question. If configure is put into cross-compile mode (with Robert's method), then wouldn't it be the case that configure would NOT execute test binaries? If so, does that hurt the configuration process in any way? Is this a problem? Errgle. It _can_ affect the configure process. Say for instance, squid. Squid uses test binaries to determine socket sizes, maximum fd limits and the like, which it can't do during a cross compile run, so the cross compiler (individual) has to provide those on the command line. Cross-compiling certainly reduces the 'magic' detection that can take place. Rob Grrr... This makes one start believing that Earnie's method is more correct. Uhm, yes, that would be the reason not to emulate the cross build. I suppose the right answer to this question is: use whichever method seems to work best for the project that you're working on. If they both work the same, then use your favorite one. Note, that I think that a _true_ cross build is the more correct way to build for MinGW using Cygwin. However, `gcc -mno-cygwin' isn't a _true_ cross compiler so you shouldn't treat it as one. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.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: Ash spawning win32 programs (was Re: bash/cmd CTRL-C problem...)
At 10:50 AM 1/12/2002 +1100, Robert Collins wrote: Have you tried the latest snapshot and confirmed that this still occurs? Yes, this is with the latest snapshot. I actually haven't upgraded past 1.3.2 because the problems (like this) get worse from then on (using bash as /bin/sh being the only solution). I'm just trying to suck your brain dry while the issues are still clear in your mind :) I guess I don't understand why this is expected. It always used to work (i.e. the subprocess would get killed also). It's expected because win32 programs don't understand cygwin signals. Console programs that appear to understand signals actually get told by the OS when CTRL-C is hit on the console. So I'm confused. I realise that signals are a cygwin (UNIX) thing but I thought that they were written in such a way as to Do The Right Thing in this instance. Certainly my experience has been that the Right Thing happened at various points in cygwin's history. If you are saying that this is not the right thing anymore then I can accept that but just want to understand why. The key question here is : what semantics should apply to a _non signal aware program_ when cygwin detects a signal is generated for it? I.e., to pick a couple, for SIGINT and SIGKILL. One is obvious, we call (IIRC) TerminateProcess and *boom* it's gone. Hope your work was saved. Er, why isn't it signal aware. It is AFAIK. I thought this was obvious. Is it linked against cygwin1.dll? No? Then it's not signal aware. Signals are one of the cygwin additions to the win32 platform. Hmn, ok. So shouldn't we just do the same thing as happens under the DOS console? andy -- 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/
AW: Problem with cygwin.bat
Hallo Heimo.
If you just want to repair your Windows settings:
My Machine says:
open: %1 %*
Bearbeiten: C:\WINNT\System32\NOTEPAD.EXE
Print: C:\WINNT\System32\NOTEPAD.EXE /p
Sorry to all non-germans to bother you with german words.
Kristof Doffing
Lufthansa Systems
Airline Services GmbH, FRA AS/S
FAC, Hugo-Eckener-Ring A.8.02
60549 Frankfurt/Main
Tel.: +49 69 / 696 92630
Fax : +49 69 / 696 92062
-Ursprüngliche Nachricht-
Von: Heimo Ponnath [mailto:[EMAIL PROTECTED]]
Gesendet am: Montag, 14. Januar 2002 14:51
An: [EMAIL PROTECTED]
Betreff: Problem with cygwin.bat
Sorry for this stupid question,
but I did not find a way to solve the problem myself. I work with
Windows NT 4.0 SP 6a and the actual cygwin (just some minutes ago
updated) distribution.
Some weeks ago, I changed the way, windows reacts when I click onto
a desktop-icon which stands for a .bat file. (I forgot the rule:
Never change a running system) Now every time i click onto the
cygwin-icon, a normal dos-windows opens with the Prompt:
C:\WINNT\Profiles\ponnath\Desktop
Before I did the change, the cygwin shell opened with my home
directory as prompt. OK, I change into C:\cygwin and run cygwin.bat
- but doing this is not the best way to solve the problem.
I dont know how to change back to the usual behaviour.
I think, I misconfigured something in the options part of windows
explorer. For .bat Files there are now the following entries (I try
to translate from german) there:
Description: batch processing file for MS-DOS
MIME-type : empty
standard-ending for this type: empty
actions:
open
print
For open the edit-card shows:
action: open
program for this action: C:\WINNT\system32\Cmd.exe[%1]
Use DDE: empty
For print the edit-card shows:
action: print
program for this action: L:\PROGRAMME\UEDIT32.EXE/p%1
Use DDE: marked
DDE message: [print{%1}]
program: UEDIT32
DDE program not active: empty
Theme: System
I think, the solution must be somewhere in the configuration of the
open properties. But I have no idea, what is wrong and how to
reconfigure it.
I hope, you can help me. Best wishes
Heimo
--
Heimo Ponnath Webdesign, Rotenhäuserstr. 51, 21109 Hamburg
Tel: 040-753 47 95,Fax: 040-752 68 03, http://www.heimo.de/
--
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: [ANNOUNCEMENT] Updated: readline-4.2a-1
On Sun, Jan 13, 2002 at 01:08:54PM -0500, Christopher Faylor wrote: On Sun, Jan 13, 2002 at 12:47:00PM -0500, Charles Wilson wrote: postgres: this setup hint is absolutely incomplete. It has no sdesc, ldesc, category, OR requires. I made no changes -- the maintainer needs to generate a REAL setup.hint; and when he does, add 'libreadline5' as a requires: Gah! This is the dreaded put the versions in the setup.hint rather than let the computer figure it out for me syndrome. The other information was correct in the setup.ini but it was never imported to setup.hint. It's possible that Jason hasn't updated PostGres since the new setup.exe with dependencies was introduced. Chris' assumption is correct -- I have not updated PostgreSQL since categories have been added. I'm still waiting for PostgreSQL 7.2 ... I've created a new setup.hint from info in the setup.ini file and added the libreadline5 dependency. The file is still missing the ldesc but that is no big deal. Chris, thanks for coming to my rescue. BTW, the old setup.hint is a vestige of the update-setup era which did not deal appropriately with versions such as 7.1rc4. Now that we are in the upset era, its time for this old dog to learn new tricks. :,) 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: AW: Problem with cygwin.bat
Hi Kristof, Am Montag, 14. Januar 2002 15:08 schrieb [EMAIL PROTECTED]: If you just want to repair your Windows settings: My Machine says: open: %1 %* This solution does not work for me. When I change the entry in program for open from: C:\WINNT\system32\Cmd.exe[%1] to %1 %* as you tould me, I get an error message: Die angegebene Anwendung wurde nicht gefunden. Überprüfen Sie die Pfad- und Dateinamenangabe. In english language: The given application could not be found. Examine the path- and file name. (oh my englih knowledge!!) Best wishes Heimo -- Heimo Ponnath Webdesign, Rotenhäuserstr. 51, 21109 Hamburg Tel: 040-753 47 95,Fax: 040-752 68 03, http://www.heimo.de/ -- 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: Windows question (was Problem with cygwin.bat)
Sorry for this stupid question, You forgot to mention completely off topic and maybe inappropriate for this list too. Keith -- 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: Proposed Mailing List Page Reorg
Robert Collins wrote: given with Cygwin run the same 'on cygwin' as they do on any Uni* -like platform (and therefore general documentation 'out there' will apply too), From experience on this list, I can assert that this is an unsafe assumption. Many many many questions are asked that are solveable by simple examination of existing documentation - like the recent lex-flex question (while I didn't know that answer, that's gotta be a flex FAQ!). Well, I'm sorry about asking, but I'd been looking for the key to that for 2 years, and only recently has cygwin come up to speed to be able to build and run my application. With the help of the latest incarnation of 'info flex' and recent improvements in vim syntax coloring, I did find both the latent bugs and the features which aren't supported exactly the same by lex and flex. If there were a flex FAQ or a flex mailing list, would it not show up on gcc.gnu.org or a newsgroup or google search? BAL [By And Large] clearly DON'T want anymore to answer questions like what does man do or how do I login to bash). Good point. But another one where there are minor gotchas for people who have 20 years experience on Unix with shells which pre-date free software. And, without experience specific to Cygwin, no one knows exactly which variations on the standard behavior of free software will apply on Cygwin. For example, has anyone documented the ways in which cygwin differs from linux in application of code and data alignments? Does anyone think the newlib mailing list is a helpful place? -- Tim Prince [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/
Re: Proposed Mailing List Page Reorg
Here is a good place to look for info about flex. I found some good stuff about bison there. http://www.faqs.org/faqs/ Have you ever tried using Daves Quick Search Bar? It's a convenient helpful search tool. http://notesbydave.com/toolbar/searchdoc.htm --- Tim Prince [EMAIL PROTECTED] wrote: If there were a flex FAQ or a flex mailing list, would it not show up on gcc.gnu.org or a newsgroup or google search? = Fractal A.[EMAIL PROTECTED] __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ -- 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: segfault with xemacs 21.4.6/cygwin, setup.exe distribution, re_match_2_internal
I don't know what this is but I'm not going to to run an executable which has no description. cgf On Mon, Jan 14, 2002 at 09:35:46AM +, Henry S. Thompson wrote: -- 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/ -- [EMAIL PROTECTED]Red Hat, Inc. http://sources.redhat.com/http://www.redhat.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/
Need help Accessing a NAN
Under Linux I do: include math.h ... reciprocal=NAN; When I try to compile this under cygwin, gcc complains that NAN is undefined. Under cygwin, man nan, tells me about a function named nan(), also using math.h. When I try to use it, gcc complains about an implicit declaration of nan(). I am attaching relevant portions of the Makefile I am using to the end of this message. Help would be appreciated. Norman Shapiro 798 Barron Avenue Palo Alto CA 94306-3109 (650) 565-8215 [EMAIL PROTECTED] libDir=../Run jdk=/cygdrive/c/jdk1.3.1_01/ all:\ $(libDir)/sine.dll \ $(libDir)/regret.dll\ $(libDir)/quad.dll \ $(libDir)/arith.dll \ $(libDir)/fast.dll \ $(libDir)/slow.dll \ GDBFLAGS = -g -ggdb CPPFLAGS= -m486 -Wall -Wpointer-arith -pipe \ -I/usr/X11R6/include\ -g \ -O \ -Wbad-function-cast \ -Wstrict-prototypes \ -Wmissing-prototypes\ -Wmissing-declarations \ -Werror \ -D_ISOC9X_SOURCE\ -Wnested-externs\ -I $(jdk)/include \ -I $(jdk)/include/linux \ -I $(jdk)/include/genunix \ -I /usr/include/g++-3 \ $(GDBFLAGS)\ $(libDir)/%.dll: %.cpp Makefile gcc \ $(CPPFLAGS) \ -mno-cygwin \ -I$(jdk)/include\ -I$(jdk)/include/win32 \ -Wl,--add-stdcall-alias \ -shared \ -o\ $@ $ -- 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: Compiling apps to Mingw32 with cygwin
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Earnie Boyd Sent: Monday, January 14, 2002 5:43 AM To: Robert Collins Cc: Jon Leichter; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Compiling apps to Mingw32 with cygwin You need to narrow your thinking to GCC and binutils the processes of consequence. You only need to specify the triplet because config.guess guesses wrong based on the value of `uname -s'. The cygwin binutils as named will produce executables that use MSVCRT.DLL instead of CYGWIN1.DLL without having to do anything special with their names or output. So, my statement stands based on what happens with GCC, you're switching the build environment. Earnie, According to GNU documenation, the following utilities are a part of binutils: ar, nm, objcopy, objdump, ranlib, readelf, size, strings, strip, c++filt, cxxfilt, nlmconv, windres, dlltool Which of these utilities produces executables that use MSVCRT.DLL? I don't think any of them do. The binutils package that distributes with Cygwin (which is what I use) are Cygwin binaries; they are dependent on CYGWIN1.DLL. They're also all quite happy to operate on MinGW binaries. GCC, of course, is a suite of tools (the only set, I believe) that generates MinGW binaries (if, of course, the -mno-cygwin switch is specified). All Cygwin GCC tools are STILL Cygwin binaries themselves; they all depend on CYGWIN1.DLL. I tend to agree with Robert's point of view. It seems to me that the build environment is Cygwin. In my mind, the only compelling reason NOT to use Cygwin as the build value is because (with an up-to-date autoconf), the configure script would NOT test executables if it were set to Cygwin. This condition may or may not hurt the project builder. Thus, it still comes down to whichever build value works best for the project builder. 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: rebase for setup (curl)
One more follow-up: I'm not sure what I did, however I tried it while logged in as an administrative user on my Win2K box (where all this started). It built re-basable. So, I tried again while logged in as a non-admin (same test as I ran nearer the start of this thread). But this time, it builds re-basable! Don't have any idea at all why it didn't work before but now it does. Not sure if I care, unless it happens again. I will make every effort to verify re-basability before releasing new versions, just in case this crops up again... Thanks for your help, --Kevin -Original Message- From: Roth, Kevin P. Sent: Thursday, January 10, 2002 10:18 PM On 8 Jan 2002, at 13:26, Jason Tishler wrote: All of the above appear to be non-relocatable: $ file *.dll cygcurl-2.dll: MS Windows PE Intel 80386 console DLL not relocatable How did you manage to accomplish this? Well, I'm no closer to understanding why it didn't work on my Win2k box at work. However, at home on my WinXP-pro box, it builds re-basable with no difference in how I did it. The only thing I can think of is that on my Win2k box, I don't usually log in as an administrator; on my WinXP box, I also don't, but I did while I ran this test... I'll give it a try as an administrative account on Win2k and see if that makes any difference - if so I'll let you all know. Of course, you can expect my next curl package update to be built on my WinXP box ;-) They're testing a new release now, so it should be within a couple weeks. Also, if testing for rebase-ability is simple, could you let me know how? I'd be curious... http://www.tishler.net/jason/software/rebase/rebase.exe.bz2 The following is a sample command line: rebase -d -b 0x6800 cygcurl-2-*.dll -- 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/
$B$*855$$G$9$+(B
$B2K$D$V$7$K$I$&$>(B http://www.mailland.tv -- 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: Proposed Mailing List Page Reorg
-Original Message- From: Soren Andersen [mailto:[EMAIL PROTECTED]] So what I am addressing is a perceived (on my part) need for Soren, this is *discussing* it, if you wish to address it, then contribute a patch - to the web site, the FAQ - wherever you think it should go. I don't say this to cut short the discussion, but because no-one has disagreed in any substantial way with what you are saying, and no-one has steppted forth to do it 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: Documenting heap_chunk_in_mb
I saw that you were twisting in the wind with setting the registry setting. I found out how, so I thought I would share. In older releases, such as b19, the registery setting was a DWORD setting called HKEY_CURRENT_USER/Software/Cygnus Solutions/CYGWIN.DLL setup/b15.0/heap_chunk_in_mb, in the 1.3.3 release of cygwin, it is called HKEY_CURRENT_USER/Software/Cygnus Solutions/Cygwin/heap_chunk_in_mb. If you set a value of 4 in cygwin 1.3.3, quit out of all cygwin tools, and then launch bash, it will give an error but otherwise start up, indicating you are changing the right registry setting. You can then modify it to what value you want, pick a value no less than 160, but no greater than around 1300. I'm on NT 4.0. Hopefully, someone will document this, if it isn't already. I just checked, and I don't see any documentation. For completeness, why, why would someone need to use this? Many cygwin's have a limitation of how much heap they can use before malloc will fail. Older releases will complain with commit_and_inc: VirtualAlloc failed type messages. Newer releases won't say much, but the application will usually complain about being out of memory. Over the years, people have just bumped up the base amount of memory that cygwin will reserve for heap allocations (see shared.cc, around heap_chunk_in_mb) without fixing the `real' problem. Current sources just `fix' the heap at 256MB. Slightly older cygwin's just allocated 128MB of heap. If a user needs more, then they either have to have a fixed cygwin1.dll, or set the registry setting. A better long term fix would be to alter the malloc/sbrk implementation for cygwin to be able to use multiple chunks of address space and then allocate them on demand. The more stack space people reserve to their cygwin applications, the less space that is available for heap. Hope this information helps. -- 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: Proposed Mailing List Page Reorg
On 14 Jan 2002 at 21:32, Robert Collins wrote: contribute patches. Contribute the links *you know* (come on' after more than a years use you must have collected a few useful links). Don't worry about whether they are the best links, that's what open source doco is for! Well, yes, exactly! Collectively this List's readers must possess in one form or another a prodigious pile of reference knowledge about where to look for answers. If we pool our knowledge we will achieve the several benefits of both lowering the noise level on the List (perhaps) and making it more interesting, and also of helping others (and probably ourselves) to more quickly target rich sources for areas where enriched knowledge is required. If *you* don't, and noone else *does*, then nothing will happen, and in 6 months Chris will say I've been cogitating... Sounds pretty frightening! ;-) I am picturing Spike on Buffy the Vampire Slayer (American TV show, sorry for the non-global reference) emerging from the shadows with that malevolent smirk on his face, saying I've been cogitating.. ;-[ Soren Andersen -- 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: Proposed Mailing List Page Reorg
On 15 Jan 2002 at 10:41, Robert Collins wrote: Soren, this is *discussing* it, if you wish to address it, then contribute a patch - to the web site, the FAQ - wherever you think it should go. I'll get to work on it, for sure. I don't say this to cut short the discussion, but because no-one has disagreed in any substantial way with what you are saying, and no-one has steppted forth to do it Oops! I must be slipping ... if I'm not getting somebody to strongly disagree with me ...heh heh Best regards, Soren Andersen -- 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: Documenting heap_chunk_in_mb
Mike, Not at all. I don't give up easily, and I definitely found out what I needed to know and the registry setting worked as it was supposed to. In fact, the message you found was not about me having trouble increasing the Cygwin heap allocation, but rather about my need for help in adding the information to the Cygwin documents. I needed to increase the memory allocation to be able to run significant XSB programs (XSB is a Prolog interpreter: http://xsb.sourceforge.net/, if you're interested. Actually, now that I think of it, the memory increase was not for XSB itself, but was necessary to allow full gcc optimization of one of the XSB C-language source modules that contains a very large switch statement. I did not, however, get any answers about the mechanics of the documentation process, so my offer to help fill in this particular lacuna went essentially unclaimed. So it goes... Randy At 15:44 2002-01-14, you wrote: I saw that you were twisting in the wind with setting the registry setting. I found out how, so I thought I would share. In older releases, such as b19, the registery setting was a DWORD setting called HKEY_CURRENT_USER/Software/Cygnus Solutions/CYGWIN.DLL setup/b15.0/heap_chunk_in_mb, in the 1.3.3 release of cygwin, it is called HKEY_CURRENT_USER/Software/Cygnus Solutions/Cygwin/heap_chunk_in_mb. If you set a value of 4 in cygwin 1.3.3, quit out of all cygwin tools, and then launch bash, it will give an error but otherwise start up, indicating you are changing the right registry setting. You can then modify it to what value you want, pick a value no less than 160, but no greater than around 1300. I'm on NT 4.0. Hopefully, someone will document this, if it isn't already. I just checked, and I don't see any documentation. For completeness, why, why would someone need to use this? Many cygwin's have a limitation of how much heap they can use before malloc will fail. Older releases will complain with commit_and_inc: VirtualAlloc failed type messages. Newer releases won't say much, but the application will usually complain about being out of memory. Over the years, people have just bumped up the base amount of memory that cygwin will reserve for heap allocations (see shared.cc, around heap_chunk_in_mb) without fixing the `real' problem. Current sources just `fix' the heap at 256MB. Slightly older cygwin's just allocated 128MB of heap. If a user needs more, then they either have to have a fixed cygwin1.dll, or set the registry setting. A better long term fix would be to alter the malloc/sbrk implementation for cygwin to be able to use multiple chunks of address space and then allocate them on demand. The more stack space people reserve to their cygwin applications, the less space that is available for heap. Hope this information helps. -- 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: Need help Accessing a NAN
[EMAIL PROTECTED] writes:
Under Linux I do:
include math.h
...
reciprocal=NAN;
When I try to compile this under cygwin, gcc complains that NAN is undefined.
Under cygwin, man nan, tells me about a function named nan(), also using math.h.
When I try to use it, gcc complains about an implicit declaration of nan().
I solved this problem myself. Albeit very inelegantly
inline double nan()
{
# ifdef NAN
return NAN;
#else
double x=0.0;
return 0/x;
#endif
}
Norman Shapiro
798 Barron Avenue
Palo Alto CA 94306-3109
(650) 565-8215
[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/
openssh issue with UID's over 65535
I have an issue with openssh and UID's over 65535. Similar things were discussed a bit back, but this is slightly different. Seems that sshd will die when a user with a UID too high logs in. The root cause of this is cygwin's use of an unsigned short for uid_t, instead of an integer. As the UID goes through the ssh server, session.c calls get_last_login_time (sshlogin.c) with an integer variable. When it hits get_last_login_time, however, it's squashed into a uid_t, which is too small for it. The uid changes and problems occur. I'm guessing it wouldn't be too swift to just change the definition in types.h. That oughta break lotsa stuff. Is there some clear path to getting uid_t changed to an int, or is there a different/better fix for this? Mark -- 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: libtool-devel and kde2
1) This discussion should be on-list. I've copied this to the cygwin mailing list. 2) Ummm...you're not USING libtool-devel. You have deliberately overriden the auto-version detection, and are using /usr/autotool/stable/* for both stable and devel projects. (You set the environment variable AUTO_DEVEL=/usr/autotool/stable) Ralf Habacker wrote: now I have made some tries with the new libtool devel-20010531-rc5. Nope, you're using libtool stable 1.4.2 I have build an app using a shared lib, which depends on another lib and the dependency code works well. Congratulations for your good work. I think I will note this on the kde-cygwin website. While working with it, I noticed some problems. This may depend on a libtool and autoconf/automake relation, which I don't know currently, but let me tell. $ cygcheck -c | grep auto autoconf2.52-5 autoconf-devel 2.52-4 autoconf-stable 2.13-4 automake1.5a-1 automake-devel 1.5-5 automake-stable 1.4p5-5 Environment AUTO_DEVEL=/usr/autotool/stable 1. configure tries to identify the cygwin environment and this fails in some case depending on the initial setting of the CC=cc var. I've never run into this. It always seems to find gcc for me. However, libtool doesn't handle overriding CC very well -- cf. recent discussion concerning wrapper scripts and 'gcc -mno-cygiwn'. Leave CC unset within your environment when using libtool. $ ./configure creating cache ./config.cache checking for Cygwin environment... no checking for mingw32 environment... no checking how to run the C preprocessor... grep: conftest.out: No such file or directory ^^^ this depends on using cc instead of gcc cc -E checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes The only way to solve this problem seems to be exporting CC=gcc before configuring. Any ideas ? 2. I have problems configuring language specific support with libtool.Unfortunally the kde2 project is configured with the Multiple Language Branch-libtool which creates language specific ltcf-c.sh and ltcf-cxx.sh files. I'm confused. Are you relibtoolizing the project, or just running configure; make? If you aren't relibtoolizing, then you're not using the system libtool stuff AT ALL. You're merely using the scripts that the upstream maintainer copied into the package before you got ahold of it. If you are relibtoolizing, then it shouldn't matter what version of libtool the upstream maintainer used -- you're replacing all of that. Finally, you are NOT using the devel version. You are using 1.4.2 -- pre-MultipleLanguageBranch. The *actual* devel version is based on the 20010531 CVS, which was just after the MLB was merged back to the trunk. Therefore, the *actual* devel version should support MLB (although I have not tested it -- and neither have you). So using the AC_PROG_CXX in configure.in needs ltconfig for creating a valid configure, which seems not be supported by your libtool. No, it doesn't. As of libtool-1.4 (released April 2001), ltconfig is not used. http://mail.gnu.org/pipermail/libtool/2001-April/004780.html So, if it's wanting ltconfig, then it was libtoolized with something pre-1.4. I can only guess that your packages were libtoolized with a non-standard libtool taken from the MultiLanguage branch, prior to the MLB merge (may 2001) AND prior to the ltconfig elimination (Sept 2000). There seem to be a HOST of contradictions in your post... The kdelibs distribution contains such a file in the admin dir, but because the relating ltcf-cxx.sh files does not know anything about the cygwin patch, the cxx configuration does not created proper dll's. In other words, libtool tries to start impgen and so one. Yes, because apparently your package was libtoolized LONG before any of those changes made it in. On http://fink.sourceforge.net/doc/porting/libtool.php I found some hints relating to this topic and there is described, that libtool 1.4 does not support ltconfig. It's not that it doesn't support it -- it is not needed. All of its functionality has been moved into libtool.m4: http://mail.gnu.org/pipermail/libtool-patches/2000-September/07.html Gotta go -- don't have time now to respond to the rest of the post... --Chuck With a test project I'm using the following workaround in configure.in. CXX=g++ AC_SUBST(CXX) b to avoid some problems, but this is no solution for the kde2 port. So my question is, how do I create valid cxx configurations ? 3. libtoolizing with --ltdl - problems to find the aux-dir (may be an autoconf problem) I have made a test project with a libltdl subdir and an admin dir, which contains administration file as used by kde. The problem is, that
RE: Proposed Mailing List Page Reorg Has Been Reorged
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Collins -Original Message- From: Soren Andersen [mailto:[EMAIL PROTECTED]] So what I am addressing is a perceived (on my part) need for Soren, this is *discussing* it, if you wish to address it, then contribute a patch - to the web site, the FAQ - wherever you think it should go. I don't say this to cut short the discussion, but because no-one has disagreed in any substantial way with what you are saying, and no-one has steppted forth to do it Uh, guys: http://cygwin.com/lists.html. Pretty well done, whoever did it. And it's been up since at least the crack of noon. Let this be a lesson to everyone to: 1. RTFM 2. STFML and TFWS 3. WTFPMA[1] the next time a newless cluebie stumbles in here and for some reason the urge to bite his head off rears its ugly head. [1] Watch The Fricken Potty Mouth Abbreviations. -- Gary R. Van Sickle Brewer. Patriot. -- 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: Proposed Mailing List Page Reorg Has Been Reorged
- Original Message - From: Gary R. Van Sickle [EMAIL PROTECTED] Uh, guys: http://cygwin.com/lists.html. Cool - Soren, you're off the hook :}. Pretty well done, whoever did it. And it's been up since at least the crack of noon. Yes, CVS will tell if you're interested. I haven't looked but my hunch is Chris. Let this be a lesson to everyone to: 1. RTFM 2. STFML and TFWS TFSW? Also, WTFWPFC! 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/
