RE: Setup: A suggestion
[snip] > A resizeable window - it's far too small. A patch to make the chooser window larger (though not resizable) is awaiting approval/committal. -- 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: [avail for test] libtool-devel-20030121-1
Hi Charles, I've taken a deeper look into the libtool sources and found a hint relating to the way other os do this checking, for example libtool.m4.in # AC_DEPLIBS_CHECK_METHOD pass_all gnu*) irix5* | irix6* | nonstopux*) linux*) (most hosts) osf3* | osf4* | osf5*) sco3.2v5*) solaris*) sysv5OpenUNIX8* | sysv5UnixWare7* | sysv5uw[[78]]* | unixware7* | sysv4*uw2*) aix4* | aix5*) beos) file_magic == bsdi4*) pw32*) darwin* | rhapsody*) freebsd*) hpux10.20* | hpux11*) newos6*) openbsd*) sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*) match_pattern netbsd*) unknown nto-qnx) cygwin* | mingw* ) lt_cv_deplibs_check_method='pass_all' # RH cygwin* | mingw* ) lt_cv_deplibs_check_method='file_magic' # CW Also in case you tell me that this is to late, see this for information purpose. I can see from this, that major unix platforms use 'pass_all', so there couldn't be so much issues. Ralf -- 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: 'hostname' now returns lower case
* Lynn Wilson (03-02-08 05:53 +0100) > I'm now running cygwin 1.3.19-1. I've recently noticed that a bash script that > previously worked is failing. The problem is that the 'hostname' command used > to return an upper case machine name. It now returns a lower case name. > > Which is correct? Read the thread "why is hostname(1) output in UPPERCASE?" from last month. Thorsten -- Content-Type: text/explicit; charset=ISO-8859-666 (Parental Advisory) Content-Transfer-Warning: message contains innuendos not suited for children under the age of 18 -- 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: MySQL for Cygwin?
I have sucessfully compiled mySQL (server and client utils) from the sourceforge.net tarball without significant problems. However, since I only actually use the CLI client, I cannot comment on whether the server is suitable for general use. The CLI client works beautifully, though (via TCP/IP to all machines I've tried). And I assume the Cygwin Apache module for mysql is based on libmysql and works the same way - via TCP/IP. R. On Sexta, Fev 7, 2003, at 19:13 Europe/Lisbon, Andrew DeFaria wrote: I was wondering if MySQL was ported to Cygwin. I went to http://cygwin.com/packages/ and typed in mysql and was surprised to see things like exim listed! I also saw Apache mod stuff for MySQL as well as PostgressSQL. What I didn't see is MySQL. I'm wondering how exactly, for instance, the Apache mod stuff for MySQL hooks up with MySQL when there isn't a package for MySQL for Cygwin?!? Pointers appreciated. -- 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/
NFS (was: The cygwin mailing lists are...)
Erm... Correct me if I'm wrong, but wouldn't an NFS client have to manipulate mount points as well? I can see that working for Cygwin binaries (since everything related to the filesystem namespace goes through Cygwin), but it wouldn't work for Win32 binaries, since it's not a full network redirector (in the Win32 subsystem parlance, IIRC). Still, It's interesting to ponder. I understand the Sun RPC stuff works now, right? R. On Sexta, Fev 7, 2003, at 23:12 Europe/Lisbon, Robb, Sam wrote: P.S.: anyone know of a good (free) NFS client for Windows XP, btw? That's the only thing he's missing so far. I have to point out that all I'm working on right now is the server end of things. If you know of an existing NFS client, though, you might be able to get it working under cygwin now. -Samrobb -- 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/
group names in /etc/passwd, ssh root login & more
Hallo, the cygwin user guide says its a feature that groups can be the owner of files. can somebody tell me why this is so when you can set the group attributes accordingly? also in linux you have a group "root" and a user "root". if both occur in your /etc/passwd file sshd won't allow "root" to login. :( only workaround i have is calling the "group root" admin instead of root. i find this very disturbing... any comments? Ciao Uwe mailto:[EMAIL PROTECTED] -- 'Das ist mein voller Ernst', sagte die Frau, als sie ihren Mann die Treppe hinaufpoltern hoerte. -- 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: group names in /etc/passwd, ssh root login & more
Uwe Mayer wrote: > Hallo, > > the cygwin user guide says its a feature that groups can be the owner > of files. can somebody tell me why this is so when you can set the > group attributes accordingly? Because that's how Windows works. Max. -- 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: testing accessibility to sources.redhat.com
Christopher Faylor wrote: > > On Fri, Feb 07, 2003 at 08:44:47PM +, Don Sharp wrote: > > > > > >Elfyn McBratney wrote: > >> > >> > This is a somewhat off topic item. > >> > I have been trying for the last three weeks to update my cygwin > >> > installation with setup.exe. Unfortunately I can't establish a connection. > >> > >> Just a bit ;-) > >> > >> > traceroute (from my linux firewall) and tracert from my NT box both show > >> > that the trace reaches a router somewhere in the USA and then falls down > >> > a black hole. MY ISP says it's not his problem because he's passed the > >> packets > >> > onward. Has anyone else, (particularly customers of blueyonder.co.uk), > >> > had any trouble reaching sources.redhat.com? Until recently I have had no > >> > difficulties updating. > >> > >> Well I use blueyonder broadband, BT ADSL and B... Freeserve dial-up. > >> I have no problems connecting from either service to s.r.c . > >> > > > >Thanks for letting me know it works for you. > > Out of curiousity, what IP address are you seeing for sources.redhat.com? The > server moved a few weeks ago. The IP address should be: 66.187.233.205 . > The difficulty has arisen since the change to your new IP address. My ISP's DNS knows the right IP but my packets disappear down a black hole somewhere in the USA. MY ISP's help desk acknowledge that they can't reach s.r.c either but say they can't do anything about it. Traces from other ISP's in the UK work fine and even blueyonder's professional (business) provider can make the route. However it seems that for me any packets to a 66.x.x.x address fall down a black hole. Cheers Don Sharp -- 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: Latest cygwin always crashing with Postgres
Seth, Please post instead of sending private email. On Fri, Feb 07, 2003 at 07:14:52PM -0500, Seth Rubin wrote: > I'm running win XP (home) with cygwin. A few months ago I had cygwin > and postgres working fine on this machine. Today I had problems (the > IPC communication wasn't happening even though ipc-daemon was > running), so before I did anything I upgraded my cygwin to the latest > version (1.3.19-1) and along with that came postgres 7.3.1 . I also > got the new cygipc (1.13-2) and installed it. > > Since doing this I have not been able to get postgresql to work. It > performs an initdb fine, the ipc-daemon starts fine, but any attempt > to connect with createdb or psql causes postgres to stack-dump and > exit. > > Any advice appreciated. I'm even open to trying to debug it, if you > can give me some idea how to do that in the winxp world. I run using Cygwin CVS a lot, so I have never actually used Cygwin 1.3.19-1. However, I have not experienced the above behavior. My suggestion is to try the latest snapshot: http://cygwin.com/snapshots/ Note that this means to just replace cygwin1.dll not all of the files in the cygwin package. Please report your findings back to the list. If I don't hear from you (via the list), then I will try PostgreSQL under 1.3.19-1 on Monday. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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/
[ANNOUNCEMENT] Updated: tcsh-6.12.00-2
I've updated the version of tcsh to 6.12.00-2. This version is an update to the official version 6.12.00 with all Cygwin specific changes of the 6.11.00-5 version merged in. If you do have problems with this version of insight it would probably be best to send them to the insight mailing list at "insight at sources dot redhat dot com". Then the insight maintainers can help rectify them. I read that mailing list, too, of course. To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. If you have general questions or comments, please send them to the Cygwin mailing list at: "cygwin at cygwin dot com". I would appreciate it if you would use this mailing list rather than emailing me directly. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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/
[ANNOUNCEMENT] Updated: file-3.39-1
I've updated the version of file to 3.39-1. This version is an update to the official version 3.39. If you do have problems with this version of insight it would probably be best to send them to the insight mailing list at "insight at sources dot redhat dot com". Then the insight maintainers can help rectify them. I read that mailing list, too, of course. To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. If you have general questions or comments, please send them to the Cygwin mailing list at: "cygwin at cygwin dot com". I would appreciate it if you would use this mailing list rather than emailing me directly. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: [ANNOUNCEMENT] Updated: file-3.39-1
Corinna Vinschen wrote: > I've updated the version of file to 3.39-1. > If you do have problems with this version of insight it would probably ^^^ Copy/paste! ;-) (& tcsh too). Max. -- 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/
[ANNOUNCEMENT] Updated: mingw-runtime-2.4-1
This is a multi-part message in MIME format. --000102040107000502010108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I've uploaded a new version of the mingw runtime. The ChangeLog entries are attached. Earnie. -Installation Instructions- To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. Note that we do not allow downloads from sources.redhat.com (aka cygwin.com) due to bandwidth limitations. This means that you will need to find a mirror which has this update. In the US, ftp://mirrors.rcn.net/mirrors/sources.redhat.com/cygwin/ is a reliable high bandwidth connection. In Germany, ftp://ftp.uni-erlangen.de/pub/pc/gnuwin32/cygwin/mirrors/cygnus/ is usually pretty good. In the UK, http://programming.ccp14.ac.uk/ftp-mirror/programming/cygwin/pub/cygwin/ is usually up-to-date within 48 hours. If one of the above doesn't have the latest version of this package then you can either wait for the site to be updated or find another mirror. If you have questions or comments, please send them to the Cygwin mailing list at: [EMAIL PROTECTED] . I would appreciate it if you would use this mailing list rather than emailing me directly. This includes ideas and comments about the setup utility or Cygwin in general. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. I implore you to READ this information before sending email about how you "tried everything" to unsubscribe. In 100% of the cases where people were unable to unsubscribe, the problem was that they hadn't actually read and comprehended the unsubscribe instructions. If you need to unsubscribe from cygwin-announce or any other mailing list, reading the instructions at the above URL is guaranteed to provide you with the info that you need. --000102040107000502010108 Content-Type: text/plain; name="Changes.mingw" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="Changes.mingw" 2003-02-08 Earnie Boyd <[EMAIL PROTECTED]> * include/stdlib.h: Make words after #endif a comment. 2003-02-07 Danny Smith <[EMAIL PROTECTED]> * include/locale.h: Include stddef.h for definition of NULL. 2003-01-26 Danny Smith <[EMAIL PROTECTED]> * include/math.h (tgamma): Correct typo in comment. 2003-01-26 Danny Smith <[EMAIL PROTECTED]> * mingwex/mingw-fseek.c (INLINE): Remove define. (__mingw_is_win9x): Remove static inline function. (_mingw_fwrite): Use _osver instead of __mingw_is_win9x. 2003-01-11 Danny Smith <[EMAIL PROTECTED]> * mingwex/math/llround.c: Correct function name and change return value to long long. 2003-01-07 Danny Smith <[EMAIL PROTECTED]> * include/ctype.h (__isascii): Don't cast arg to unsigned. (iswascii): Likewise. Correct mask. * include/wctype.h (iswascii): Don't cast arg to unsigned. Correct mask 2003-01-03 Danny Smith <[EMAIL PROTECTED]> * include/stdlib.h (_osver, _winver, _winmajor, _winminor): Declare as direct imports from dll if __DECLSPEC_SUPPORTED. 2003-01-01 Danny Smith <[EMAIL PROTECTED]> * pseudo-reloc.c (do_pseudo_reloc): Make static. * pseudo-reloc-list.c: New file. * crt1.c (_pei386_runtime_relocator): Declare. (__mingw_CRTStartup): Call it. * dllcrt1.c (_pei386_runtime_relocator): Declare. (DllMainCRTStartup): Call it. * Makefile.in: Add pseudo-reloc.o pseude-reloc-list.o to libmingw32.a. 2003-01-01 Egor Duda <[EMAIL PROTECTED]> * pseudo-reloc.c: New file. 2002-12-20 Earnie Boyd <[EMAIL PROTECTED]> * include/_mingw.h: Increment version to 2.4. Makefile.in: Ditto. 2002-12-12 Earnie Boyd <[EMAIL PROTECTED]> * include/malloc.h (_alloca): Add definition. (alloca): Ditto. 2002-12-08 Danny Smith <[EMAIL PROTECTED]> * mingwex/math/s_erf.c: New file. * mingwex/math/sf_erf.c: New file. * mingwex/Makefile.in (MATH_DISTFILES): Add new files. (MATH_OBJS): Add new objects. * include/math.h (erf[f]): Add prototypes. (erfc[f]): Add prototypes. 2002-12-07 Danny Smith <[EMAIL PROTECTED]> * include/math.h: Add traditional/XOPEN math constants. 2002-11-27 Danny Smith <[EMAIL PROTECTED]> * mingwex/math/lgamma.c: New
Re: [ANNOUNCEMENT] Updated: mingw-runtime-2.4-1
Could you guys get getopt (getopt.h) defined? Thanks. Earnie Boyd wrote: This is a multi-part message in MIME format. --000102040107000502010108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I've uploaded a new version of the mingw runtime. The ChangeLog entries are attached. Earnie. -Installation Instructions- To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. Note that we do not allow downloads from sources.redhat.com (aka cygwin.com) due to bandwidth limitations. This means that you will need to find a mirror which has this update. In the US, ftp://mirrors.rcn.net/mirrors/sources.redhat.com/cygwin/ is a reliable high bandwidth connection. In Germany, ftp://ftp.uni-erlangen.de/pub/pc/gnuwin32/cygwin/mirrors/cygnus/ is usually pretty good. In the UK, http://programming.ccp14.ac.uk/ftp-mirror/programming/cygwin/pub/cygwin/ is usually up-to-date within 48 hours. If one of the above doesn't have the latest version of this package then you can either wait for the site to be updated or find another mirror. If you have questions or comments, please send them to the Cygwin mailing list at: [EMAIL PROTECTED] . I would appreciate it if you would use this mailing list rather than emailing me directly. This includes ideas and comments about the setup utility or Cygwin in general. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. I implore you to READ this information before sending email about how you "tried everything" to unsubscribe. In 100% of the cases where people were unable to unsubscribe, the problem was that they hadn't actually read and comprehended the unsubscribe instructions. If you need to unsubscribe from cygwin-announce or any other mailing list, reading the instructions at the above URL is guaranteed to provide you with the info that you need. --000102040107000502010108 Content-Type: text/plain; name="Changes.mingw" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="Changes.mingw" 2003-02-08 Earnie Boyd <[EMAIL PROTECTED]> * include/stdlib.h: Make words after #endif a comment. 2003-02-07 Danny Smith <[EMAIL PROTECTED]> * include/locale.h: Include stddef.h for definition of NULL. 2003-01-26 Danny Smith <[EMAIL PROTECTED]> * include/math.h (tgamma): Correct typo in comment. 2003-01-26 Danny Smith <[EMAIL PROTECTED]> * mingwex/mingw-fseek.c (INLINE): Remove define. (__mingw_is_win9x): Remove static inline function. (_mingw_fwrite): Use _osver instead of __mingw_is_win9x. 2003-01-11 Danny Smith <[EMAIL PROTECTED]> * mingwex/math/llround.c: Correct function name and change return value to long long. 2003-01-07 Danny Smith <[EMAIL PROTECTED]> * include/ctype.h (__isascii): Don't cast arg to unsigned. (iswascii): Likewise. Correct mask. * include/wctype.h (iswascii): Don't cast arg to unsigned. Correct mask 2003-01-03 Danny Smith <[EMAIL PROTECTED]> * include/stdlib.h (_osver, _winver, _winmajor, _winminor): Declare as direct imports from dll if __DECLSPEC_SUPPORTED. 2003-01-01 Danny Smith <[EMAIL PROTECTED]> * pseudo-reloc.c (do_pseudo_reloc): Make static. * pseudo-reloc-list.c: New file. * crt1.c (_pei386_runtime_relocator): Declare. (__mingw_CRTStartup): Call it. * dllcrt1.c (_pei386_runtime_relocator): Declare. (DllMainCRTStartup): Call it. * Makefile.in: Add pseudo-reloc.o pseude-reloc-list.o to libmingw32.a. 2003-01-01 Egor Duda <[EMAIL PROTECTED]> * pseudo-reloc.c: New file. 2002-12-20 Earnie Boyd <[EMAIL PROTECTED]> * include/_mingw.h: Increment version to 2.4. Makefile.in: Ditto. 2002-12-12 Earnie Boyd <[EMAIL PROTECTED]> * include/malloc.h (_alloca): Add definition. (alloca): Ditto. 2002-12-08 Danny Smith <[EMAIL PROTECTED]> * mingwex/math/s_erf.c: New file. * mingwex/math/sf_erf.c: New file. * mingwex/Makefile.in (MATH_DISTFILES): Add new files. (MATH_OBJS): Add new objects. * include/math.h (erf[f]): Add prototypes. (erfc[f]): Add prototypes. 2002-12-07 Danny Smith <[EMAIL PROTECTED]> * include/math.h: Add traditional/XOPEN math constants. 2002-11-27 Danny Smith <[EMAIL PROTECTED]> * mingwex/math/lgamma.c: New file. * mingwex/math/lgammaf.c: New file. * mingwex/math/lgammal.c: New file. * mingwex/math/tgamma.c: New file. * mingwex/math/tgammaf.c: New file. * mingwex/math/tgammal.
Re: [ANNOUNCEMENT] Updated: mingw-runtime-2.4-1
Andrew DeFaria wrote: > Could you guys get getopt (getopt.h) defined? Been there, discussed that: http://sources.redhat.com/ml/cygwin/2002-11/msg01456.html Max. -- 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: NFS (was: The cygwin mailing lists are...)
> Still, It's interesting to ponder. I understand the Sun RPC stuff works > now, right? Correct. -Samrobb
accept() seg faults using non-global address for buffer or socket structure
I've looked at every mailing list and FAQ for limitations on the Cygwin
accept() I can't find this one.
The following program illustrates the problem, simply moving the struct
sockaddr_in sin, and char buf definition lines to be local variable of
the main will cause the accept to fail with a "bad address" error. It
seg faults in the library under gdb. connect works fine on local
variables. Is this a bug or did I miss something? The program simple
echos what the client types back to it.
The problem still exists on the update I downloaded from cygwin.com
today.
-
/**/
/* Program echoserver.c */
//
#include
#include
#include
#include
#include
#define SERVER_PORT 8085
#define MAX_PENDING 5
#define MAX_LINE 256
struct sockaddr_in sin; // making these local to main causes a "bad
address" return from the perror after the accept!
char buf[MAX_LINE]; // It gets a seg fault somewhere in the library.
int main()
{
int len;
int s, new_s;
/* build address data structure */
bzero((char *)&sin, sizeof(sin));
sin.sin_family = AF_INET;
sin.sin_addr.s_addr = INADDR_ANY;
sin.sin_port = htons(SERVER_PORT);
/* setup passive open */
if((s = socket(PF_INET, SOCK_STREAM, 0)) < 0)
{
perror("Simplex-talk: socket");
exit (1);
}
if ((bind(s, (struct sockaddr *)&sin, sizeof(sin))) < 0)
{
perror("Simplex - talk bind");
exit(1);
}
listen(s, MAX_PENDING);
printf("Echo is listening on port %u\n",SERVER_PORT);
/* wait for connection, then receive, print, and send text message
back to client*/
while (1)
{
if ((new_s = accept(s, (struct sockaddr *)&sin, &len)) < 0)
{
perror("simplex-talk: accept");
exit(1);
}
printf("Server connected %x\n", new_s);
send(new_s,"--- Echo Server - \n",29,0);
while( (len = recv(new_s, buf, sizeof(buf), 0)) >0)
{ printf("got:<%s>\n",buf);
send(new_s, buf, len,0);
}
close(new_s);
printf("Server connection %d closed\n",new_s);
}
}
--
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/
Suspicious sshd log messages (sshd works)
Hi,
Never thought I'd be asking questions about sshd, but here we go: I've
finally gotten around to setting up an ssh server on my machine (Win2k
SP2, using openssh-3.5p1-3, cygwin1.dll compiled from CVS yesterday).
I can just hear the groans of ssh experts, so, before I go into details,
*it seems to work*. I'm able to log in via "ssh igor@localhost".
Now that that's out of the way... I've set up the sshd service using
/bin/ssh-host-config, enabling privilege separation (with the user "sshd"
and all that). I then manually re-run cygrunsrv as follows
$ cygrunsrv -I sshd -d "CYGWIN sshd" -p /usr/sbin/sshd -a "-De" -e
"CYGWIN=check_case:strict ntsec notitle binmode nosmbntsec notty"
to get logging to /var/log/sshd.log. The CYGWIN value above is the one I
use for the shell as well. Looking at the log, I see very suspicious
messages:
"Failed to disconnect from controlling tty." upon login, and
"syslogin_perform_logout: logout() returned an error" upon logout.
The sessions seem to work otherwise. My question is: should I be worried
about these messages? If yes, what should I do to get rid of them?
I'm not sure what other info would be relevant. Just in case, the output
of "cygcheck -svr" is attached. I can also send the relevant logs if
needed. Thanks,
Igor
P.S. Running sshd with -Dddde didn't produce any useful info. Also, the
value of UsePrivilegeSeparation in /etc/sshd_config doesn't seem to make
any difference for this.
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
-- /usr/games/fortune
Cygwin Win95/NT Configuration Diagnostics
Current System Time: Sat Feb 08 14:42:55 2003
Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 2
Path: C:\cygwin\home\igor\bin
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\usr\local\games
C:\cygwin\usr\X11R6\bin
c:\ActivePerl\bin
c:\MikTeX\miktex\bin
c:\WINNT\system32
c:\WINNT
c:\WINNT\system32\wbem
c:\Program Files\IBM\Trace Facility
c:\Program Files\Personal Communications
c:\Notes
c:\Utilities
c:\Program Files\ThinkPad\Utilities
c:\cygwin\bin
SysDir: C:\WINNT\System32
WinDir: C:\WINNT
CYGWIN = `check_case:strict ntsec notitle binmode nosmbntsec notty'
HOME = `C:\cygwin\home\igor'
MAKE_MODE = `unix'
PWD = `/tmp'
USER = `igor'
ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\igor\Application Data'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `PECHTCHA'
COMSPEC = `C:\WINNT\system32\cmd.exe'
CVSREAD = `true'
CVS_RSH = `/bin/ssh'
HOMEDRIVE = `C:'
HOMEPATH = `\'
HOSTNAME = `pechtcha'
LOGONSERVER = `\\PECHTCHA'
MANPATH =
`/usr/man:/usr/local/man:/usr/autotool/devel/man:/usr/contrib/jikes/man::/usr/ssl/man'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/home/igor'
OS2LIBPATH = `C:\WINNT\system32\os2\dll;'
OS = `Windows_NT'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PCOMM_ROOT = `C:\Program Files\Personal Communications'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 8 Stepping 6, GenuineIntel'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0806'
PROGRAMFILES = `C:\Program Files'
PROMPT = `$P$G'
PS1 = `\[[\033[32m${HOSTNAME}\033[0m:\033[33m\w\033[0m]\] '
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINNT'
TEMP = `C:\cygwin\tmp'
TERM = `cygwin'
TMP = `C:\cygwin\tmp'
USERDOMAIN = `PECHTCHA'
USERNAME = `igor'
USERPROFILE = `C:\Documents and Settings\igor'
WINDIR = `C:\WINNT'
_ = `/usr/src/cygwin-cvs/build/i686-pc-cygwin/winsup/utils/cygcheck'
HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
(default) = `/cygdrive'
cygdrive flags = 0x0022
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/export/home/igor
(default) = `\\samba.watson.ibm.com\igor'
flags = 0x0002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/mnt/c
(default) = `c:'
flags = 0x0002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/contrib/java
(default) = `C:\Program Files\IBM\Java13'
flags = 0x
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start
Menu\Programs\Cygnus Solutions
(default) = (unsupported type)
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\
Re: accept() seg faults using non-global address for buffer or socket structure
On Fri, Feb 07, 2003 at 10:34:54PM -0700, J. J. Ekstrom wrote: > I've looked at every mailing list and FAQ for limitations on the Cygwin > accept() I can't find this one. > [...] > if ((new_s = accept(s, (struct sockaddr *)&sin, &len)) < 0) Cockpit error. Try initializing len before calling accept(2). 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/
[ANNOUNCEMENT] tcsh-6.12.00-2 and file-3.39-1 announcements
The announcements in the subject both contained the following section: If you do have problems with this version of insight it would probably be best to send them to the insight mailing list at "insight at sources dot redhat dot com". Then the insight maintainers can help rectify them. I read that mailing list, too, of course. This section slipped in by (copy-paste) mistake. Please just ignore it. Send error messages to the mailing list [EMAIL PROTECTED] as usual. Thanks. -- 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: [ANNOUNCEMENT] Updated: zsh-4.0.6-3
On Fri, 7 Feb 2003 [EMAIL PROTECTED] wrote: > Not sure whether it's worth mentioning, but here it is: > zprofile and zshell.zsh have DOS-style line-endings. > Should be changed to unix format. Oh heck! My source patch got generated as a DOS text file, so when I did a clean rebuild to generate the packages, it generated everything in DOS-style! It shouldn't cause any problems (ie: zprofile & zshell.zsh should run without problems), but I'll clean it up for the next release. Tanks! > Kind regards, > Bernd -- Peter A. Castro <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]> "Cats are just autistic Dogs" -- Dr. Tony Attwood -- 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: zsh-4.0.6-3
On Fri, 7 Feb 2003, Dr. Volker Zell wrote: > > "BStrohhaecker" == BStrohhaecker <[EMAIL PROTECTED]> writes: > > BStrohhaecker> Not sure whether it's worth mentioning, but here it is: > BStrohhaecker> zprofile and zshell.zsh have DOS-style line-endings. > BStrohhaecker> Should be changed to unix format. > > Also /bin/mkzsh > > BStrohhaecker> Kind regards, > BStrohhaecker> Bernd Yep, and the README and several other files. Like I said in other email, it shouldn't effect execution. If it cause breakage, let me know. Otherwise, I'll correct it in the next release. > Ciao > Volker -- Peter A. Castro <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]> "Cats are just autistic Dogs" -- Dr. Tony Attwood -- 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/
1.3.19: fork() strange memory leak under W2K
Hello! Some time ago, when I was using at home 1.3.18 version of CygWin under Windows 2000 Workstation + SP3, I discovered that every command execution lead to some memory leak. It's especially noticeably when I try to run large scripts (like "configure") - the memory loading (as viewed in Task Manager) grow to its physical size and next I get message like this: 0 [main] sh 35620 sync_with_child: child 35636(0xDC) died before initialization with status code 0x80 6847 [main] sh 35620 sync_with_child: *** child state waiting for longjmp ./../ltconfig: fork: Resource temporarily unavailable After this, any process can't be started without rebooting (or killing other process). Recently, I upgraded my system to Windows 2000 Server + SP3 (with total precleanup) and CygWin 1.3.19, but problem is there as before. :( I made small test program which loops for 1000 times: --8<-- #!/bin/sh ctr=1 while test `expr "$ctr"` -lt 1000; do ctr=`expr $ctr + 1` # ps > /dev/null done --8<-- The result: --8<-- $ ./test 0 [main] sh 1136 sync_with_child: child 35976(0x134) died before initialization with status code 0x80 1976 [main] sh 1136 sync_with_child: *** child state waiting for longjmp ./test: fork: Resource temporarily unavailable --8<-- After this, the memory leak average is 28 MBytes. When I uncomment line "ps > /dev/null" in this example, memory leak grow to 42 MBytes. Changing "ps" command in uncommented line on any external command not affect average memory leak. All looks like every fork() lead to leak about 13 KBytes of physical memory. All utilities don't indicate that memory leak exist in user space, that I decide that lost memory must be located in kernel space. It's very strange, but all this works nice at my work on computer with Windows 2000 Workstation + SP3! My home computer hardware is AMD Duron 800 MHz, Abit KT7A Motherboard, 256 MB RAM; at work Celeron 800 MHz, Acorp i815 Motherboard, 128 MB RAM. The difference is also in the filesystems: FAT32 at home and NTFS at work. I found similar messages in cygwin mailing list archive, but without any response. By the way, same problem exist in MinGW minimalistic system (MSYS). Is there anybody who can say any considerations about this problem? The "cygcheck" program out is attached to this message. Regards, Victor. cygcheck.out 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/
Help with xargs and output redirection.
Hi,
I've been working on a problem and havent found a way out yet. The
problem is as follows:
I have a list of files in a folder. I want to run a perl script on each of
them and redirect the output to the filename with a suffix (ie if there are
5 files initially then after the script has run, there should be 10 files -
5 original files and 5 output files)
I tried
ls --color=none *.cls|xargs -i basename {}|xargs -i perl
~/Unix/Perl/MyScript.pl \{\}.cls "> {}_Prof.cls"
but this doesnt seem to work...
Any help appreciated...please copy to my id.
Thanks and regards,
Raghu
--
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: Help with xargs and output redirection.
At 05:23 PM 2/8/2003, Rajagopalan, Raghu (CCL) wrote:
>Hi,
> I've been working on a problem and havent found a way out yet. The
>problem is as follows:
>
>I have a list of files in a folder. I want to run a perl script on each of
>them and redirect the output to the filename with a suffix (ie if there are
>5 files initially then after the script has run, there should be 10 files -
>5 original files and 5 output files)
>
>I tried
>
>ls --color=none *.cls|xargs -i basename {}|xargs -i perl
>~/Unix/Perl/MyScript.pl \{\}.cls "> {}_Prof.cls"
>
>but this doesnt seem to work...
>
>Any help appreciated...please copy to my id.
Is this a Cygwin specific issue?
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: Help with xargs and output redirection.
No - not really.
-Original Message-
From: Larry Hall (RFK Partners, Inc) [mailto:[EMAIL PROTECTED]]
Sent: Saturday, February 08, 2003 5:26 PM
To: Rajagopalan, Raghu (CCL); '[EMAIL PROTECTED]'
Subject: Re: Help with xargs and output redirection.
At 05:23 PM 2/8/2003, Rajagopalan, Raghu (CCL) wrote:
>Hi,
> I've been working on a problem and havent found a way out yet. The
>problem is as follows:
>
>I have a list of files in a folder. I want to run a perl script on each of
>them and redirect the output to the filename with a suffix (ie if there are
>5 files initially then after the script has run, there should be 10 files -
>5 original files and 5 output files)
>
>I tried
>
>ls --color=none *.cls|xargs -i basename {}|xargs -i perl
>~/Unix/Perl/MyScript.pl \{\}.cls "> {}_Prof.cls"
>
>but this doesnt seem to work...
>
>Any help appreciated...please copy to my id.
Is this a Cygwin specific issue?
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: 1.3.19: fork() strange memory leak under W2K
Works for me on Win2000Pro+SP3/PIII. > -Original Message- > From: Victor Antonovich [mailto:[EMAIL PROTECTED]] > Sent: Saturday, February 08, 2003 5:18 PM > To: [EMAIL PROTECTED] > Subject: 1.3.19: fork() strange memory leak under W2K > > > Hello! > > Some time ago, when I was using at home 1.3.18 version of > CygWin under Windows 2000 Workstation + SP3, I > discovered that every command execution lead to some memory > leak. It's especially noticeably when I try to run large > scripts (like "configure") - the memory loading (as viewed > in Task Manager) grow to its physical size and next I > get message like this: > > 0 [main] sh 35620 sync_with_child: child 35636(0xDC) > died before initialization with status code 0x80 >6847 [main] sh 35620 sync_with_child: *** child state > waiting for longjmp > ./../ltconfig: fork: Resource temporarily unavailable > > After this, any process can't be started without rebooting > (or killing other process). > > Recently, I upgraded my system to Windows 2000 Server + > SP3 (with total precleanup) and CygWin 1.3.19, but problem is > there as before. :( > > I made small test program which loops for 1000 times: > --8<-- > #!/bin/sh > ctr=1 > while test `expr "$ctr"` -lt 1000; do > ctr=`expr $ctr + 1` > # ps > /dev/null > done > --8<-- > > The result: > --8<-- > $ ./test > 0 [main] sh 1136 sync_with_child: child 35976(0x134) > died before initialization with status code 0x80 >1976 [main] sh 1136 sync_with_child: *** child state > waiting for longjmp > ./test: fork: Resource temporarily unavailable > --8<-- > > After this, the memory leak average is 28 MBytes. When I > uncomment line "ps > /dev/null" in this example, memory > leak grow to 42 MBytes. Changing "ps" command in uncommented > line on any external command not affect average memory leak. > All looks like every fork() lead to leak about 13 KBytes of > physical memory. > > All utilities don't indicate that memory leak exist in > user space, that I decide that lost memory must be located in > kernel space. > > It's very strange, but all this works nice at my work on > computer with Windows 2000 Workstation + SP3! My home > computer hardware is AMD Duron 800 MHz, Abit KT7A > Motherboard, 256 MB RAM; at work Celeron 800 MHz, Acorp i815 > Motherboard, 128 MB RAM. The difference is also in the > filesystems: FAT32 at home and NTFS at work. > > I found similar messages in cygwin mailing list archive, > but without any response. By the way, same problem exist > in MinGW minimalistic system (MSYS). Is there anybody who > can say any considerations about this problem? The "cygcheck" > program out is attached to this message. > > Regards, > Victor. > -- 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: 1.3.19: fork() strange memory leak under W2K
> Some time ago, when I was using at home 1.3.18 version of
> CygWin under Windows 2000 Workstation + SP3, I
> discovered that every command execution lead to some memory
> leak. It's especially noticeably when I try to run large
> scripts (like "configure") - the memory loading (as viewed
> in Task Manager) grow to its physical size and next I
> get message like this:
>
> 0 [main] sh 35620 sync_with_child: child 35636(0xDC)
> died before initialization with status code 0x80
>6847 [main] sh 35620 sync_with_child: *** child state
> waiting for longjmp
> ./../ltconfig: fork: Resource temporarily unavailable
>
> After this, any process can't be started without rebooting
> (or killing other process).
>
> Recently, I upgraded my system to Windows 2000 Server +
> SP3 (with total precleanup) and CygWin 1.3.19, but problem is
> there as before. :(
>
> [...]
>
> It's very strange, but all this works nice at my work on
> computer with Windows 2000 Workstation + SP3! My home
> computer hardware is AMD Duron 800 MHz, Abit KT7A
> Motherboard, 256 MB RAM; at work Celeron 800 MHz, Acorp i815
> Motherboard, 128 MB RAM. The difference is also in the
> filesystems: FAT32 at home and NTFS at work.
>
> [...]
Sorry for the "me too" on this, but well Me too ;-)
I am unable to test this on a FAT32 partition as I don't have one on my or
any other system I work with. Perhaps you could provide strace output? Igor
gave some very good pointers ("Re: rcs ci and co hang") on this list a few
days ago, although it's not the same issue, you could use some of the
instructions to gather the strace output and send some/it to the list.
If it does reach an outrageous size, or you're not to sure what it means, I
don't mind if you send it to me off-list and I'll take a gander (compressed
ofcourse ;-)...
Regards,
Elfyn McBratney
[EMAIL PROTECTED]
www.exposure.org.uk
--
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: [avail for test] libtool-devel-20030121-1
From 'info libtool':
`pass_all'
will pass everything without any checking. This may work on
platforms in which code is position-independent by default and
inter-library dependencies are properly supported by the dynamic
linker, for example, on DEC OSF/1 3 and 4.
From ltmain.sh:
echo "*** Warning: Linking the shared library $output against the"
echo "*** static library $deplib is not portable!"
and
if test "$alldeplibs" = yes &&
{ test "$deplibs_check_method" = pass_all ||
{ test "$build_libtool_libs" = yes &&
test -n "$library_names"; }; }; then
# We only need to search for static libraries
continue
fi
which seems to imply that when building a shlib, we won't add the
dependencies -lfoo -lbar to the link command, if libfoo and libbar are
shared libs. But on cygwin/windows, all dependencies must be satisfied
at link time...unlike ELF.
In our case "position independent" is technically true for all object
files -- -fpic does nothing. However, it is STILL possible that one
would compile code one way for inclusion within a shared library (e.g.
-DBUILDING_DLL) and differently when making a static library. There are
still extant cases in current cygwin libraries where the DLL and the .a
are *not* interchangable, since the client code must be compiled with
-DBUILDING_STATIC or some such. A relic of the "old way" when we had to
define __declspec(xx). So static libs and shared libs are not
necessarily drop-in replacements for each other.
So, interlibrary dependencies are not automatic.
cygwin* | mingw* ) lt_cv_deplibs_check_method='pass_all' # RH
cygwin* | mingw* ) lt_cv_deplibs_check_method='file_magic' # CW
Which is not to say that it won't work to do it your way -- IF and only
IF you are (a) linking only to new-style, non-declspec()-using
libraries, or (b) are linking only to libraries built (new-style) as
part of your package. E.g. KDE.
In the future, it might be possible to use 'pass_all' on cygwin
(assuming the point about 'dropping -lfoo -lbar' mentioned above doesn't
apply) -- but I doubt that we'll ever get rid of some of the special cases.
Worse, using pass_all means that a lot of different (read: untested on
cygwin) codepaths are used, for all of the esoteric features of libtool
like staticlinked -dlopen'ed modules, or dynamically linked modules that
depend on other sharedlibs that are part of the same package, etc etc.
As complex as KDE is, I doubt it really exercises ALL of the possibile
permutations and uses of libtool.
I presume that you have run the entire libtool test suite with your
proposed change, and it passed all tests except for build_relink2 and
quote? If not, then, well...I don't have time to do your homework, and
the current mechanism has had a three month shakedown period. I expect
libtool-1.5 within *days*.
Also in case you tell me that this is to late, see this for information purpose.
Understood, but...
I can see from this, that major unix platforms use 'pass_all', so there couldn't
be so much issues.
Ha ha ha ha ha ha hee hee hee hee. Oh, it is to laugh.
Ralf, cygwin is not unix. cygwin is not linux. cygwin is not solaris.
cygwin is not irix. cygwin is cygwin. Our runtime loader is crap.
We don't have ld.so.conf. We don't have ld.so. We don't use ELF format
for our shared libraries or object code. We have Microsoft's
bastardized implementation of a runtime loader, that has led to an
industry curse-word: DLL HELL. We have PE/COFF format object code.
cygwin is different. Just because it works one way on linux -- and
*may* work the same way, in a narrow range of usages expected by KDE, on
cygwin, doesn't mean that cygwin and linux/solaris/irix/etc are
interchangable.
I note that once again, rather than trying to help me speed up the
function you complained about, by testing my various proposals, you are
instead chasing down rabbit trails and wandering in the weeds -- and not
presenting evidence that you HAVE, in fact, actually tested your own
ideas, much less mine. (actually, I do assume that you have tested your
ideas, but you haven't *told* me that you have done so.)
--Chuck
--
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: [avail for test] libtool-devel-20030121-1
> Ralf -- please drop my 'final' script into one of your generated > libtools and run your tests (what? rebuilding KDE?) on it, and let me > know what you think. (Oh, and since (a) 'file' execution speed is > invariant with target size, and (b) we match *DLL* and *executable* > separately, if you are linking directly to DLLs -- as I believe Ralf's > KDE build does -- then my version is almost as fast (<1% difference) as > Ralf's "check the name of the file only" version) > Chuck, this script does not work with original libtool 1.4e, which is provided with kde. It hangs on the last line, see below: + newdeplibs= -L/usr/lib/w32api + expr -lbz2 : -l\(.*\) + name=bz2 + test bz2 != + test bz2 != 0 + test Xyes = Xyes + test -n -lbz2 + eval $echo "lib$name" + echo libbz2 + libname=libbz2 + ls /usr/lib/w32api/libbz2[.-]* + potential_libs= + ls /usr/lib/libbz2.a /usr/lib/libbz2.dll.a + potential_libs=/usr/lib/libbz2.a /usr/lib/libbz2.dll.a + ls -lLd /usr/lib/libbz2.a + grep -> + potlib=/usr/lib/libbz2.a + test -h /usr/lib/libbz2.a + eval win32_libid "$potlib" + /usr/bin/sed 10q + grep -E ^x86 archive import|^x86 DLL Then I've taken a recent libtool from www.cygwin.com, build my profiler lib with this (cvs dir tools/profiler from http://kde-cygwin.sf.net) and copied this libtool into the kde source tree. The results for makeing for example kdecore: pass_all: 40 sec from make start until the compile command line comes up. file_magic (win32_libid): 50 sec from make start until the ar(!) command line comes up. The problem I've got with this is that I can't build a shared library. Instead I've got some errors. 1. *** Warning: linker path does not have real file for library -lutil. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libutil and none of the candidates passed a file format test *** using a file magic. Last file checked: /usr/lib/libutil.a *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. /usr/lib/libutil.a is a nonlibtool static archive, which isn't catched by your script. This results into a linker fail with an "undefined reference" error, because a function of this lib is needed. The only way I see to fix it is to add static archives to deplibs_check_method: deplibs_check_method="file_magic ^x86 archive import|^x86 DLL|^x86 archive static" but 1b. this can be reached with a much easier way using the 'file' command: deplibs_check_method="file_magic DLL|archive" file_magic_cmd="file" This needs equal time as "pass_all" (40 sec from make start until the link command) If you need executables too use deplibs_check_method="file_magic executable|DLL|archive" Chuck, what kind of advantage do you see in win32_libid against this. win32_libid makes this stuff more complicated as it is (see 1.), so I vote for skipping the win32_libid command complety and using the 'file' command. It seems obsolate to me. I'm sorry, that you may be frustrated about the work which is already done, we can learn from this: Do not make things complexer as they are. :-) Ralf -- 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: [avail for test] libtool-devel-20030121-1
> From 'info libtool':
>
>`pass_all'
> will pass everything without any checking. This may work on
> platforms in which code is position-independent by default and
> inter-library dependencies are properly supported by the dynamic
> linker, for example, on DEC OSF/1 3 and 4.
>
> From ltmain.sh:
>
> echo "*** Warning: Linking the shared library $output against the"
> echo "*** static library $deplib is not portable!"
>
> and
>
>if test "$alldeplibs" = yes &&
> { test "$deplibs_check_method" = pass_all ||
> { test "$build_libtool_libs" = yes &&
> test -n "$library_names"; }; }; then
> # We only need to search for static libraries
> continue
>fi
>
> which seems to imply that when building a shlib, we won't add the
> dependencies -lfoo -lbar to the link command, if libfoo and libbar are
> shared libs. But on cygwin/windows, all dependencies must be satisfied
> at link time...unlike ELF.
>
> In our case "position independent" is technically true for all object
> files -- -fpic does nothing. However, it is STILL possible that one
> would compile code one way for inclusion within a shared library (e.g.
> -DBUILDING_DLL) and differently when making a static library. There are
> still extant cases in current cygwin libraries where the DLL and the .a
> are *not* interchangable, since the client code must be compiled with
> -DBUILDING_STATIC or some such. A relic of the "old way" when we had to
> define __declspec(xx). So static libs and shared libs are not
> necessarily drop-in replacements for each other.
>
Thanks for this pointer. It seems to me, that you are much more deeper in the
libtool stuff as I am.
> So, interlibrary dependencies are not automatic.
>
> > cygwin* | mingw* ) lt_cv_deplibs_check_method='pass_all' # RH
> > cygwin* | mingw* ) lt_cv_deplibs_check_method='file_magic' # CW
>
> Which is not to say that it won't work to do it your way -- IF and only
> IF you are (a) linking only to new-style, non-declspec()-using
> libraries, or (b) are linking only to libraries built (new-style) as
> part of your package. E.g. KDE.
>
> In the future, it might be possible to use 'pass_all' on cygwin
> (assuming the point about 'dropping -lfoo -lbar' mentioned above doesn't
> apply) -- but I doubt that we'll ever get rid of some of the special cases.
>
For the answer see my next mail, which describes a way solving this all without
pass_all. :-)
> Worse, using pass_all means that a lot of different (read: untested on
> cygwin) codepaths are used, for all of the esoteric features of libtool
> like staticlinked -dlopen'ed modules, or dynamically linked modules that
> depend on other sharedlibs that are part of the same package, etc etc.
> As complex as KDE is, I doubt it really exercises ALL of the possibile
> permutations and uses of libtool.
>
> I presume that you have run the entire libtool test suite with your
> proposed change, and it passed all tests except for build_relink2 and
> quote? If not, then, well...I don't have time to do your homework, and
> the current mechanism has had a three month shakedown period. I expect
> libtool-1.5 within *days*.
>
> > Also in case you tell me that this is to late, see this for
> information purpose.
>
> Understood, but...
>
> > I can see from this, that major unix platforms use 'pass_all', so
> there couldn't
> > be so much issues.
>
> Ha ha ha ha ha ha hee hee hee hee. Oh, it is to laugh.
>
> Ralf, cygwin is not unix. cygwin is not linux. cygwin is not solaris.
> cygwin is not irix. cygwin is cygwin. Our runtime loader is crap.
> We don't have ld.so.conf. We don't have ld.so. We don't use ELF format
> for our shared libraries or object code. We have Microsoft's
> bastardized implementation of a runtime loader, that has led to an
> industry curse-word: DLL HELL. We have PE/COFF format object code.
>
> cygwin is different. Just because it works one way on linux -- and
> *may* work the same way, in a narrow range of usages expected by KDE, on
> cygwin, doesn't mean that cygwin and linux/solaris/irix/etc are
> interchangable.
>
> I note that once again, rather than trying to help me speed up the
> function you complained about, by testing my various proposals, you are
> instead chasing down rabbit trails and wandering in the weeds -- and not
> presenting evidence that you HAVE, in fact, actually tested your own
> ideas, much less mine. (actually, I do assume that you have tested your
> ideas, but you haven't *told* me that you have done so.)
>
I can only say it again. See the next mail.
Ralf
--
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/
1.3.19: fetchmail's "authentication failed" message corrupted
This afternoon, the following arrived in my mail spool (I've inserted it
directly from the spool):
=
>From Iain Tuddenham Sat Feb 8 13:46:51 2003
Date: Sat, 08 Feb 2003 13:46:51 + (GMT)
Subject: fetchmail authentication failed on [EMAIL PROTECTED]
Fetchmail could not get mail from [EMAIL PROTECTED]
The attempt to get authorization failed.
Since we have already succeeded in getting authorization for this
connection, this is probably another failure mode (such as busy server)
that fetchmail cannot distinguish because the server didn't send a useful
error message.
However, if you HAVE changed your account details since starting the
fetchmail daemon, you need to stop the daemon, change your configuration
of fetchmail, and then restart the daemon.
The fetchmail daemon will continue running and attempt töÙ"and shortly after,
fetchmail sent
me another message (uncorrupted) to say that normal service was resumed -
my issue is the binary gubbins.
My .fetchmailrc includes
mda "procmail -d '%T'; notify"
(where notify is a little script to ring a bell).
I'm using:
WinXP Pro 5.1.2600 Service Pack 1 Build 2600
cygwin-1.3.19-1
fetchmail-6.2.0-3
procmail-3.22-7
Output from "cygcheck -s -v -r" attached as per http://cygwin.com/bugs.html.
I've looked in the fetchmail.exe binary, and the message is uncorrupted
there. And the binary gubbins I received in the message doesn't appear in
fetchmail.exe. I notice that the binary gubbins includes the string
"MakeSelfRelative", so I did:
=
LILAC:~$ find / -exec grep --with-filename MakeSelfRelative {} \;
Binary file /bin/cygwin1.dll matches
grep: /etc/ssh_host_dsa_key: Permission denied
grep: /etc/ssh_host_key: Permission denied
grep: /etc/ssh_host_rsa_key: Permission denied
grep: /tmp/.d389.1689c9: Permission denied
Binary file /usr/bin/cygwin1.dll matches
D:\cygwin\bin\find.exe: *** WFSO timed out for after longjmp.
/var/spool/mail/Iain Tuddenham:The fetchmail daemon will continue running and attempt
t ý"ÒAR
AAÈM
R
AQ
ÈM
Hþ"R
R
Ù"·1õwöÙ"Ý"\A\ÝwpÙ"¨Ù"õwÝwPÚ"Å2õwÝwöÙ"ðÙ"ðÙ"öÙ"/3õwl0üwú2õw,·
a8è"ÿÿgthSid¨$4¸$4àýÔóâwÔQ°#40ÝwMakeSelfRelativeSDorDaclDua@Ú"î>õw`Û"üÿÿÿ´é"8è"Ú"«öw8è"dÚ"xÚ"`Ú"pÚ"hÚ"|Ú"´é"8è"
è"
éÛ"dPé"[öw8è"´é"é"¥0Ýw8è"´é"é"/
a8è"´é"é"øÚ"E÷wdd$ѸP7Ú×ÖC2ì$ѸP7Ú×ÖC2.\nuljõwPF$xGìýØÙ"
$Ù"ØÜ"õw(6$Nõw$jõw¸Ü"÷wÈÕöwjõwçw$xG$tçwàýàýÐPF$xG$ Ü"@
$CÜÜ"Ùa°å$Ü"@Ý"÷wxÝ"$^aÝ"©Aa06$ÄÝ"õw $Nõwx$`axÝ"PÝ"äDaxÝ"|^a
LILAC:~$
=
(where I've cut out "No such file or directory" lines for soft links).
This is the only "authentication failed" message I've had since I started
using Cygwin to receive my mail, and I can't think of a way of forcing
another (the IMAP server is public) to see whther the corruption recurs.
It may be relevant that using the same software versions but using non-SSL
POP instead of IMAP, I've had emails corrupted because ~1000 characters
were lost by the time they reached my spool. (I switched to IMAP too
recently to know whether the loss will happen with it.)
Another possible clue is that an attempt to save a message in Pine from a
non-spool mail folder to the same folder (in order to move it to the end
of the folder) always results in
[Unexpected changes to folder (try restarting): ]
- I've never had this problem with Pine on Sun 4, Solaris 2 or Red Hat
Linux. A clue not because Pine has to do with email, but because it
exhibits a Cygwin-only file-writing/locking problem.
A third clue may be that I use the otherwise excellent AllChars macro
utility (http://allchars.zwolnet.com/index.html), which has catalysed bugs
in other Windows software in the past (e.g.
http://forums.digiguide.com/topic.asp?id=9541).
I'd be grateful for any light anyone can shed!
Iain Tuddenham.
Cygwin Win95/NT Configuration Diagnostics
Current System Time: Sun Feb 09 01:05:38 2003
Windows XP Professional Ver 5.1 Build 2600 Service Pack 1
Path: D:\cygwin\home\Iain Tuddenham\bin
D:\cyg
Re: [avail for test] libtool-devel-20030121-1
Ralf Habacker wrote: > Chuck, this script does not work with original libtool 1.4e 1.4e isn't a specific version. It just means "some cvs checkout after the 1.4d release" > file_magic (win32_libid): 50 sec from make start until the ar(!) > command line comes up. The problem I've got with this is that I can't > build a shared library. Instead I've got some errors. > > 1. > *** Warning: linker path does not have real file for library -lutil. > *** I have the capability to make that library automatically link in > when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have > *** because I did check the linker path looking for a file starting > *** with libutil and none of the candidates passed a file format test > *** using a file magic. Last file checked: /usr/lib/libutil.a > *** The inter-library dependencies that have been dropped here will be > *** automatically added whenever a program is linked with this library > *** or is declared to -dlopen it. > /usr/lib/libutil.a is a nonlibtool static archive, which isn't > catched by your script. This results into a linker fail with an > "undefined reference" error, because a function of this lib is needed. > > The only way I see to fix it is to add static archives to > deplibs_check_method: deplibs_check_method="file_magic ^x86 archive > import|^x86 DLL|^x86 archive static" This seems like a good time to mention that I ran into this problem building gtk+ (or glib), I forget. It wanted -luuid, but -luuid is a static archive, which libtool doesn't currently like. I had to hack libtool as Ralf mentions above to get it to work. Max. -- 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: 1.3.19: fetchmail's "authentication failed" message corrupted
Today at 1:31am, Iain Tuddenham wrote: | This afternoon, the following arrived in my mail spool (I've inserted it | directly from the spool) But sadly in my posting, Pine threw away most of the binary and the the following few lines for good measure - this time I've attached the corrupt mail from the spool. | The fetchmail daemon will continue running and attempt töÙ"and shortly after, |fetchmail sent | me another message (uncorrupted) to say that normal service was resumed - | my issue is the binary gubbins. Should have been: I'm happy to believe the bit I can read, and shortly after, fetchmail sent me another message (uncorrupted) to say that normal service was resumed - my issue was the binary gubbins. Iain Tuddenham. bit 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: [avail for test] libtool-devel-20030121-1
> 1.4e isn't a specific version. It just means "some cvs checkout after the > 1.4d release" but this could be a long period: :-) The recent devel libtool tells: $ libtool --version ltmain.sh (GNU libtool) 1.4e (1.1175 2003/01/01 01:57:46) ltmain of recent kde from anoncvs.kde.org: VERSION=1.4e TIMESTAMP=" (1.1090 2002/02/07 19:54:36)" Ralf -- 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: 1.3.19: fetchmail's "authentication failed" message corrupted
Sorry - nothing to do with Cygwin - known problem with fetchmail: http://lists.ccil.org/pipermail/fetchmail-friends/2003-January/003007.html (Google didn't find that page for me when I searched before posting here). Iain Tuddenham. -- 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: 1.3.19: fetchmail's "authentication failed" message corrupted
Sorry - me again... Today at 1:31am, Iain Tuddenham wrote: | My .fetchmailrc includes | mda "procmail -d '%T'; notify" | (where notify is a little script to ring a bell). Having broadcast that to the world, I've just noticed what a bad idea it is: "procmail -d '%T'; notify" returns always notify's status code of 0, so fetchmail never becomes aware of any procmail failure. mda "procmail -d '%T' && notify" fixes that (and also differs in that it doesn't ring if the mail isn't delivered). Iain Tuddenham. -- 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: 1.3.19: fetchmail's "authentication failed" message corrupted
> Sorry - me again... > > Today at 1:31am, Iain Tuddenham wrote: > > | My .fetchmailrc includes > | mda "procmail -d '%T'; notify" > | (where notify is a little script to ring a bell). > > Having broadcast that to the world, I've just noticed what a bad idea it > is: > "procmail -d '%T'; notify" > returns always notify's status code of 0, so fetchmail never becomes aware > of any procmail failure. > > mda "procmail -d '%T' && notify" > fixes that (and also differs in that it doesn't ring if the mail isn't > delivered). WOW! If only everyone were able to answer their own questions ;-) Regards, Elfyn McBratney [EMAIL PROTECTED] www.exposure.org.uk -- 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/
[ANNOUNCEMENT] Updated: cygwin-1.3.20-1
I've made a new version of the Cygwin DLL and associated utilities available for download. As usual, a list of what has changed is below. To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. If you have questions or comments, please send them to the Cygwin mailing list at: [EMAIL PROTECTED] . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. Christopher Faylor Red Hat, Inc. Changes since 1.3.19-1: - Fix problem with mmap where 2X space was allocated for MAP_PRIVATE. (Corinna Vinschen) - Set up "resort to mmap" threshold in malloc to 16M. (Christopher Faylor) - Fix problem with nonexistent passwd entry causing corrupted user name. (Pierre Humblet) - Create security attributes so that only the user can modify a symlink. (Corinna Vinschen) - Fix behavior of chown when repeating a call. (Pierre Humblet) - Allow arbitrary uids on Win95. (Pierre Humblet) - Don't consider WSAEMSGSIZE to be an error in recvfrom. (Corinna Vinschen) - Fix setting of errno from tcsetattr. (Christopher Faylor) - Add more comprehensive tcsetattr error checking. (Troy Curtiss) - *Really* allow setting of heap_chunk_size_in_mb in HKLM. (Jason Tishler) - Various v*printf fixes. (Jason Tishler, Jonathan Larmour, Chuck Wilson) - Implement "POSIXLY_INCORRECT_GETOPT" environment variable. (Christopher Faylor) - On successful execution set connection state of returned socket to CONNECTED. (Corinna Vinschen) - Reset the scroll region if the window size changes. (Christopher Faylor) - Implement setreuid32, setreuid, setregid32, setregid. (Jason Tishler, Pierre Humblet) - Implement nanosleep. (Jason Tishler) - Fix usleep. (Jason Tishler) - Fix "cygpath problem" where certain long paths had garbage characters. (Christopher Faylor) - Fix "cygcheck -c" output alignment. (Igor Pechtchanski) - Add a few more utilities to cygcheck output. (Christopher Faylor) -- 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: [avail for test] libtool-devel-20030121-1
Max Bowsher wrote:
1.4e isn't a specific version. It just means "some cvs checkout after the
1.4d release"
Right. But when? And on which branch? 1.4-branch CVS, or HEAD CVS
(which is to say, pre-1.5)? Granted, libtool's CVS organization and
branch naming could be better, but AFAIK KDE still uses a 1.4.x-style
"1.4e" from the 1.4 branch, and not a 1.5-style "1.4e" from the HEAD branch.
This seems like a good time to mention that I ran into this problem building
gtk+ (or glib), I forget. It wanted -luuid, but -luuid is a static archive,
which libtool doesn't currently like. I had to hack libtool as Ralf mentions
above to get it to work.
ARGH. That defeats the whole purpose of the *POLICY* change in libtool.
I do NOT want to be in the business of supporting a forked version of
libtool that disagrees with mainline on a *fundamental* policy issue.
** you can't build shared libraries that depend on static libraries,
when using a "modern" libtool (e.g. HEAD CVS, pre-1.5) **
the only exception to this rule are the compiler runtimes, such as
libgcc, libg++, libsupc++, libstdc++, libg2c, etc.
If you have a problem with the policy, the place to fix it is NOT to
hack up libtool. Instead, get shared versions of your dependencies.
Here are all of the w32api libs that currently build as static archives,
and are not simply import libs for Win32 dlls, and do not build shared:
libdxguid.a
liblargeint.a
libscrnsave.a
libscrnsavw.a
libuuid.a
libdinput.a
e.g. the EXTRA_LIBS in winsup/w32api/Makefile.in
EXTRA_LIBS=libuuid.a libscrnsave.a libscrnsavw.a libdxguid.a liblargeint.a
Now, scratch your itch: you have a problem with libuuid.a; figure out
how to build it as an dynamic library (hint:
gcc -shared -Wl,--export-all -Wl,--out-implib=libuuid.dll.a -o
cyguuid-0.dll uuid.o
works) but you'll have to link your client using
--enable-runtime-pseudo-reloc. Eventually this will become the default
for ld on cygwin I hope, but isn't yet -- and currently it is hard to
pass compiler and linker flags like this thru libtool.
I'm not sure what the best workaround is right now; perhaps it is time
to push for --enable-runtime-pseudo-reloc as the default on cygwin ( but
not mingw )?
--Chuck
P.S. the problem must have been in gtk, because I didn't have that
problem compiling glib-2.2.0.
P.P.S. cursory inspection shows that
largeint.c is the complete contents of liblargeint.a, and includes
"bad" data types -- if you build this as a DLL, you'll need to use
--pseudo-relocs to link against it.
dxguid.c is the complete contents of libxguid.a. --pseudo-relocs needed.
ditto dinput.c, libdinput.a
scrnsave.c is the complete contents of BOTH libscrnsave.a AND
libscrnsavw.a. However, I believe that all public symbols in scrnsave.c
are "good" data types; this should be easily dll-izable.
shell32.c contains "bad" data types, but it is not the entire contents
of libshell32.a. libshell32.a is created as an import lib for the
MS-provide shell32.dll, but then shell32.o (created from shell32.c) is
appended. So, libshell32.a is a "hybrid" like libcygwin.a -- but it
will be detected as an import lib. So there's no need to "dllize" this.
('course, philosophically, I dunno if this structure is a good idea.
Every program linked against -lshell32 will get its own private copy
of the data provided by shell32.c -- what if it changes? But making
those objects shared is bad -- because they are "bad" data types,
leading to the --psuedo-reloc problem)
kernel32.c provides functions only, and is appended to libkernel32.a.
No probs here.
--
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: cygwin-1.3.20-1
Thanks for getting this out Chris -) I had a few problems with the cygpath grabage problem and now it'll be fixed (fingers x'd) Sorry if this isn't the usual bitch after a new release ;-) Regards, Elfyn McBratney [EMAIL PROTECTED] www.exposure.org.uk -- 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: cygwin-1.3.20-1
On Sun, Feb 09, 2003 at 04:55:19AM -, Elfyn McBratney wrote: >Thanks for getting this out Chris -) > >I had a few problems with the cygpath grabage problem and now it'll be fixed >(fingers x'd) Hmm. Why didn't you try a snapshot? >Sorry if this isn't the usual bitch after a new release ;-) That's ok. Just wait. There will be a "I had a problem in 1.3.17 and it is still not working in 1.3.20, so I am switching back to B20" soon enough. 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: [avail for test] libtool-devel-20030121-1
Ralf Habacker wrote: 1.4e isn't a specific version. It just means "some cvs checkout after the 1.4d release" but this could be a long period: :-) The recent devel libtool tells: $ libtool --version ltmain.sh (GNU libtool) 1.4e (1.1175 2003/01/01 01:57:46) ltmain of recent kde from anoncvs.kde.org: VERSION=1.4e TIMESTAMP=" (1.1090 2002/02/07 19:54:36)" So, it's from CVS HEAD -- but doesn't include these cygwin changes (duplicates indicate multiple same-day commits): 2002-02-09 Gary V. Vaughan <[EMAIL PROTECTED]> From Robert Collins <[EMAIL PROTECTED]> < * > 2002-05-30 Charles Wilson <[EMAIL PROTECTED]> 2002-05-31 Charles Wilson <[EMAIL PROTECTED]> 2002-10-15 Charles Wilson <[EMAIL PROTECTED]> 2002-10-30 Charles Wilson <[EMAIL PROTECTED]> < ** > 2002-11-03 Charles Wilson <[EMAIL PROTECTED]> 2002-11-03 Charles Wilson <[EMAIL PROTECTED]> 2002-11-18 Charles Wilson <[EMAIL PROTECTED]> 2002-12-30 Charles Wilson <[EMAIL PROTECTED]> 2002-12-30 Charles Wilson <[EMAIL PROTECTED]> 2003-01-28 Charles Wilson <[EMAIL PROTECTED]> < * > This is when the auto-import support was first added. < ** > this is when the shell function win32_libid() was first introduced. And you wonder why simply dropping a new *version* of that shell function doesn't work in KDE? You need to relibtoolize the whole tree with a more recent version of libtool, and THEN you can drop in my replacement test. But, see my reply to your other message. --Chuck -- 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: cygwin-1.3.20-1
> >Thanks for getting this out Chris -) > > > >I had a few problems with the cygpath grabage problem and now it'll be fixed > >(fingers x'd) > > Hmm. Why didn't you try a snapshot? Im running from a CVS-build at home but at work I didn't use a snap as I heard on the devel grape vine that 1.3.20 was due soon so I thought I'd wait. > > >Sorry if this isn't the usual bitch after a new release ;-) > > That's ok. Just wait. There will be a "I had a problem in 1.3.17 and > it is still not working in 1.3.20, so I am switching back to B20" soon > enough. LOL!!! That say's it all ;-) Regards, Elfyn McBratney [EMAIL PROTECTED] www.exposure.org.uk -- 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/
Btw
I think this is the first cygwin release that has reached "20" since B20. I hope that's a good sign. cgf (now I've jinxed everything) -- 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: Btw
> I think this is the first cygwin release that has reached "20" since > B20. I hope that's a good sign. Does that mean that instead of "1.3.20 is mashed...I'm going back to B20" it'll be "3.9.450 is mullered I'm rolling back to 1.3.20"? ;-) > cgf > (now I've jinxed everything) You, Jixn things...Never ::-) Regards, Elfyn McBratney [EMAIL PROTECTED] www.exposure.org.uk -- 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: [avail for test] libtool-devel-20030121-1
Ralf Habacker wrote: Ralf -- please drop my 'final' script into one of your generated libtools and run your tests (what? rebuilding KDE?) on it, and let me know what you think. (Oh, and since (a) 'file' execution speed is invariant with target size, and (b) we match *DLL* and *executable* separately, if you are linking directly to DLLs -- as I believe Ralf's KDE build does -- then my version is almost as fast (<1% difference) as Ralf's "check the name of the file only" version) Chuck, this script does not work with original libtool 1.4e, which is provided with kde. It hangs on the last line, see below: + grep -E ^x86 archive import|^x86 DLL "grep" hangs? That's truly bizarre. But, you'd need to relibtoolize the whole KDE tree with a modern version of libtool, as I describe in the other message. This particular test you have done is not helpful (but that's my fault -- I'm sorry I suggested "kde" as a test base. I had thought you were *already* relibtoolizing with modern libtool; I did not realize you were building KDE using the KDE-supplied, 1 year old version of libtool.) Then I've taken a recent libtool from www.cygwin.com, build my profiler lib with this (cvs dir tools/profiler from http://kde-cygwin.sf.net) and copied this libtool into the kde source tree. Now that's better, but...not quite. See, there have also been changes in libtool.m4 -- which means that after you run aclocal and autoconf, your configure script is different. It sets different variables, it sets the same variables to possibly different values, etc etc. You really have to re-libtoolize the *actual* tree you are building. The results for makeing for example kdecore: pass_all: 40 sec from make start until the compile command line comes up. file_magic (win32_libid): 50 sec from make start until the ar(!) command line comes up. The problem I've got with this is that I can't build a shared library. Instead I've got some errors. I believe this is because of the libtool.m4 --> configure script changes that you did not pick up, using your method of snarfing a different project's prebuilt libtool. The only way I see to fix it is to add static archives to deplibs_check_method: deplibs_check_method="file_magic ^x86 archive import|^x86 DLL|^x86 archive static" ARGH. This defeats the whole purpose of the policy change -- and it is a policy change driven by the libtool development. I don't want to support a forked version of libtool that differs from mainline on a basic policy issue. Not gonna happen. See my reply to Max. but 1b. this can be reached with a much easier way using the 'file' command: deplibs_check_method="file_magic DLL|archive" file_magic_cmd="file"> This needs equal time as "pass_all" (40 sec from make start until the link command) Again, you're just saying "pass_all" by another name. You avoid the (untested) codepaths within libtool this way, but you're still reverting the official libtool policy. And if you think about it long enough, you'll probably agree that the libtool folks' decision to prevent dynlibs depending on statlibs is a GOOD thing. Chuck, what kind of advantage do you see in win32_libid against this. win32_libid makes this stuff more complicated as it is (see 1.), so I vote for skipping the win32_libid command complety and using the 'file' command. It seems obsolate to me. I'm sorry, that you may be frustrated about the work which is already done, we can learn from this: Do not make things complexer as they are. :-) "For every complex problem there is an answer that is clear, simple, and wrong." -H.L. Mencken The big slowdown in win32_libid() is using objdump and nm to help determine that a given "foo.a" file is (1) an archive, (2) an archive of x86 objects, and (3a) an archive of x86 IMPORT objects, or (3b) and archive of x86 STATIC objects. You are trying to argue that we don't really need to distinguish between (3a) and (3b) -- so just drop the whole $objdump and $nm thing. BUT THAT IS NOT POSSIBLE -- unless we want to VIOLATE the policy: Thou shalt not create dynamic libraries that have static dependencies. Ain't gonna happen. Find me a faster way to distinguish between x86 import libs and x86 static libs (and random-other-architecture libs of any sort), and I'll thank you. But telling me that I must support a fundamental philosophical and not merely technical fork of libtool for the foreseable future is NOT an option. As I see it, you have two problems: 1) my detection code is too slow for your taste, and 2) that very detection sometimes causes your build to fail, because you are trying to build dynlibs with static dependencies. So, you have two reasons to try to get win32_libid() OUT, or replace file_magic with pass_all, or whatever. Unfortunately, (2) is NOT my problem. You want to build dynamic libraries? Make sure all of your dependencies are dynamic. You want win32_libid() to go faster? Great, me too -- but don't opt
Re: Btw
On Sun, Feb 09, 2003 at 05:11:46AM -, Elfyn McBratney wrote: >> I think this is the first cygwin release that has reached "20" since >> B20. I hope that's a good sign. > >Does that mean that instead of "1.3.20 is mashed...I'm going back to B20" >it'll be "3.9.450 is mullered I'm rolling back to 1.3.20"? ;-) Something like that. Or, maybe when people start talking about B20 we can say: "You mean 1.3.20, right?" "Uh, right, I think." "Ok. You should definitely drop back to *20, then." At least that will get people into this millenium. Hmm. I think I'll have to build one massive .exe file with the whole cygwin distribution in it for this subterfuge to work. "Um, I don't think it took 18 hours for B20 to load before." 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: Btw
> Something like that. Or, maybe when people start talking about B20 we can > say: Totally OT but MySQL distribute B19...Perhaps someone should send them a mail telling them to upgrade to the bees-knees in cygwin (Ya know what I mean...B20 ;-) > > "You mean 1.3.20, right?" > > "Uh, right, I think." > > "Ok. You should definitely drop back to *20, then." > > At least that will get people into this millenium. > > Hmm. I think I'll have to build one massive .exe file with the whole > cygwin distribution in it for this subterfuge to work. > > "Um, I don't think it took 18 hours for B20 to load before." > > cgf Regards, Elfyn McBratney [EMAIL PROTECTED] www.exposure.org.uk -- 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] tcsh-6.12.00-2 and file-3.39-1 announcements
I'm having problems with this version of tcsh: it is doing some weird things with newlines. Here is a transcript of exactly what happens, with comments: wilson@XP ~ # first prompt on startup $ cat > .tcshrc # dump into .tcshrc set prompt = FOO # ctrl-D wilson@XP ~ # next prompt $ exec tcsh # let's give it a try FOO^M# where did the ^M come from? This problem did not exist in the previous version. My .bashrc and .bash_profile are empty, so I have no clue what's going on. Thanks, - Wilson __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.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/
