Re: Blocking accept() broken?

[Mailing List]

This is about as much as I can cut it down:
/***/

#include   
#include
#include
#include
#include
#include
#include
#include


int main()
{
/* variable declarations */
int connfd, listenfd, flags;
socklen_t clilen;
struct sockaddr *cliaddr;
struct sockaddr_in mysock;

/* Create socket file descriptor */
listenfd = socket(AF_INET, SOCK_STREAM, 0);

/* Set up socket details */
bzero(&mysock, sizeof(mysock));
mysock.sin_family = AF_INET;
mysock.sin_addr.s_addr = htonl(INADDR_ANY);
mysock.sin_port = htons(12201);

/* Bind file descriptor to our socket */
bind(listenfd, (struct sockaddr *) &mysock, sizeof(mysock));

/* And make our socket listen for incomming conncetions */
listen(listenfd, 20);

/* Set our listen socket blocking */
flags = fcntl(listenfd, F_GETFL, 0);
flags = flags & ~FNDELAY;  /* Turn blocking on */
fcntl(listenfd, F_SETFL, flags);

/* Infinite loop waiting for connections */
for(;;)
{
connfd = accept(listenfd, (struct sockaddr *) cliaddr, &clilen);
printf("If it were blocking, we shouldn't get here!\n");


/* Here would be a pthread_create to handle the incomming connection */

}

return 0;
}

/***/

The main point to focus on is the accept within the infinite for loop,
and the fact that it gets past that and prints out the message
continuously

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

Re: Blocking accept() broken?

[Christopher Faylor]

On Thu, Sep 23, 2004 at 03:05:11PM +1000, Mailing List wrote:
>G'day
>
>In Linux, if I call accept(socket_fd, );  it will block until
>there is a connection attempt to that socket.
>
>In Cygwin, even after writing code to ensure it is blocking*, it acts
>in a non-blocking manner.   I've looked around and can find no
>explaination for this, so I'm just wondering if anyone has any
>possible solution?
>
>Thanks
>
>
>* The code I used to force blocking was:
>
>/* Set our listen socket blocking */
>   flags = fcntl(listenfd, F_GETFL, 0);
>   flags = flags & ~FNDELAY;  /* Turn blocking on */
>   fcntl(listenfd, F_SETFL, flags);

Could you provide a simple, compilable/linkable, working test case?

cgf

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

Blocking accept() broken?

[Mailing List]

G'day

In Linux, if I call accept(socket_fd, );  it will block until
there is a connection attempt to that socket.

In Cygwin, even after writing code to ensure it is blocking*, it acts
in a non-blocking manner.   I've looked around and can find no
explaination for this, so I'm just wondering if anyone has any
possible solution?

Thanks


* The code I used to force blocking was:

/* Set our listen socket blocking */
flags = fcntl(listenfd, F_GETFL, 0);
flags = flags & ~FNDELAY;  /* Turn blocking on */
fcntl(listenfd, F_SETFL, flags);

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

clamav: libclamav as shared library

[Yaakov Selkowitz]

clamav maintainer,
First, thank you for contributing this project to the distro, and 
getting clamd working properly (something I've had trouble doing 
myself).  I do have one request, however -- and I know it's not a big 
deal -- if you could build libclamav as a shared library.

This can be done by adding -no-undefined to libclamav_la_LDFLAGS in 
libclamav/Makefile.am, then run "autoreconf -i -f -v".  This will 
increase the size of the patch, but it's really worth it to have shared 
libs, as many programs and bindings will benefit.  Both shared and 
static libraries will be built by default; I usually add 
--disable-static to the configure flags in this case, as I usually find 
that static libs just take up space.

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

Re: New packge: lighttpd-1.3.0

[Brian Dessent]

"Gerrit P. Haase" wrote:
> 
> Hello Brian,
> 
> > FYI what I'm doing basically amounts to:
> 
> [...]
> 
> I run basically the same set on php-5, I don't get a libphp at all,
> all objects are compiled into php.exe, no library around here:-(
> 
> I have a flag here:
> --enable-embed=TYPE   EXPERIMENTAL: Enable building of embedded SAPI library
>   TYPE is either 'shared' or 'static'. TYPE=shared
> 
> is this new in php-5?  Lets see what happens when I define it.

No, it's the same in php4, and I haven't had to touch it.

Are you using one of --with-apxs or --with-apache?  The former requires
Apache to be installed and the apxs binary in the path or specified
location, and the latter requires an Apache source tree that's been
configured.  If neither is found or gives an error then it won't try to
build as an apache module, which looks like what's happening in your
case -- getting the CLI only.

Brian

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

Re: can not find cygcrypt-0.dll

[Brian Dessent]

Yu-Cheng Chou wrote:

> I installed the latest cygwin (1.5.11.1) on a windows 2000 machine, and
> tried to start the sshd service, but an error message occurred saying
> that cygcrypt-0.dll can not be found in PATH. The thing is that cygcrypt-
> 0.dll does not exist in the system.
> Any idea to fix it?

cygcrypt-0.dll comes in the "crypt" package, section "Libs".  Install it
from setup.

Normally, setup takes care of all dependencies for you, but looking at
setup.ini I don't see that openssh or any of its dependencies includes
crypt on their "requires" line so this may just be a simple packaging
bug.  I could be missing something though.

Brian

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

Re: can not find cygcrypt-0.dll

[Gerrit P. Haase]

Hallo Yu-Cheng,

Am Donnerstag, 23. September 2004 um 03:35 schriebst du:


> Hi,

> I installed the latest cygwin (1.5.11.1) on a windows 2000 machine, and
> tried to start the sshd service, but an error message occurred saying
> that cygcrypt-0.dll can not be found in PATH. The thing is that cygcrypt-
> 0.dll does not exist in the system.
> Any idea to fix it?
  
Install the crypt package.


Read this:

> Problem reports:   http://cygwin.com/problems.html
> Documentation: http://cygwin.com/docs.html
> FAQ:   http://cygwin.com/faq/



Gerrit
-- 
=^..^=



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

Re: New packge: lighttpd-1.3.0

[Gerrit P. Haase]

Hello Brian,


> FYI what I'm doing basically amounts to:

[...]

I run basically the same set on php-5, I don't get a libphp at all,
all objects are compiled into php.exe, no library around here:-(

I have a flag here:
--enable-embed=TYPE   EXPERIMENTAL: Enable building of embedded SAPI library
  TYPE is either 'shared' or 'static'. TYPE=shared

is this new in php-5?  Lets see what happens when I define it.


Gerrit
-- 
=^..^=



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

can not find cygcrypt-0.dll

[Yu-Cheng Chou]

Hi,

I installed the latest cygwin (1.5.11.1) on a windows 2000 machine, and
tried to start the sshd service, but an error message occurred saying
that cygcrypt-0.dll can not be found in PATH. The thing is that cygcrypt-
0.dll does not exist in the system.
Any idea to fix it?
  

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

RE: CYGWIN + APCHE + Net::SMTP

[Prakash Khemani]

> Are other CGIs are working?  

Yes - the other CGIs seem to be working fine.

Thanks,
Prakash

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
> Of Gerrit P. Haase
> Sent: Wednesday, September 22, 2004 4:14 PM
> To: [EMAIL PROTECTED]
> Subject: Re: CYGWIN + APCHE + Net::SMTP
> 
> Hallo Prakash,
> 
> Am Mittwoch, 22. September 2004 um 23:49 schriebst du:
> 
> > I have a simple perl mail program mail.pl (pasted at the end of this
> > mail). In the cygwin environment it is able to send mail out when I
run
> > it from the command line.
> 
> > I also have apache2 running in my cygwin environment. When I run
mail.pl
> > as a CGI script it is not able to connect to the the smtp server.
The
> > Socket connection is failing (as I noticed after putting some error
> > prints in SMTP.pm).
> 
> Are other CGIs are working?  The last time I tried to build Apache2
> the CGI was broken completely (it worked ok the same day with Apache1,
> so for sure not a Cygwin or Windows issue).
> 
> Gerrit
> --
> =^..^=
> 
> 
> 
> --
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:   http://cygwin.com/problems.html
> Documentation: http://cygwin.com/docs.html
> FAQ:   http://cygwin.com/faq/


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

Re: New packge: lighttpd-1.3.0

[Brian Dessent]

"Gerrit P. Haase" wrote:
> 
> Hello Brian,
> 
> >> I hate this package since I tried to build it the first time.
> 
> > Part of the problem here is that "We don't support building under
> > Cygwin" is the official line from php-dev.
> 
> Sigh;)
> 
> > I've got php-4.3.8 working fine as a DSO with Apache (a single 3.1M
> > chgphp4.dll.)  This works for whatever modules/extensions are statically
> > included, but obviously that's not quite acceptable.  If you
> > "--enable-foo=shared" you get a foo.a file in the modules dir, but this
> > is not a win32 executable and so it cannot be dlopen()'d.  I'm still
> > working on how to get these extension modules working, when I do I'll
> > ITP the whole batch.
> 
> If it works on Linux to get .so shared modules, why should it not work
> on Cygwin to get the modules the same way?
> 
> I have already half the way through, I'll hopefully get a shared
> library now and then I'll try to get the modules shared too.

FYI what I'm doing basically amounts to:

autoreconf  --verbose --force
./configure --prefix=/usr --with-layout=GNU --libexecdir=/usr/lib/apache
--sysconfdir=/etc/php4 --with-config-file-path=/etc/php4 \
   --infodir=/usr/share/info --mandir=/usr/share/man
--with-apxs=/usr/sbin/apxs \
   --disable-ipv6 --disable-debug --without-pear --disable-cli
--enable-sockets \
   --with-mysql --with-zlib --with-bz2 2>configure.stderr |tee
configure.stdout && \
make 2>make.stderr |tee make.stdout 
cd libs
../../mkdll.sh libphp4.la -L . -lphp4 -lcrypt -lminires -lintl -lz -lbz2
/usr/bin/libhttpd.dll
strip cygphp4.dll
apxs -i -a -n php4 cygphp4.dll

...which seems to work fine - doesn't even require a rebase.

However, if I do any "--with-foo=shared" then I get *.a in the ./modules
dir, which if copied to the extensions_dir (/usr/lib/php/20020429)
cannot be loaded if enabled in php.ini.  They are archive files, not
dlls, so naturally you get an error when you try to dlopen() them.

I've tried using a similar mkdll.sh invocation on these *.a files and it
produces *.dll, but they do not load either.  For packaging's sake it
would be really nice to get these loadable modules working, otherwise
you're stuck having to compile php with a fixed set of options.

Brian

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

RE: ./configure in any package fails to create Makefile

[Mark Aufflick]

WAS: 

Tried that :( this is getting demoralising.

Here are the env variables i set:

$history |egrep '(=|export)'
  394  export CONFIG_DIRS=
  395  export CONFIG_FILES=
  428  
PATH=/usr/bin:/usr/local/bin:/usr/X11R6/bin:/opt/gnome/bin:/opt/kde2/bin
  429 
MANPATH=/usr/man:/usr/local/man:/usr/X11R6/man:/opt/gnome/man:/opt/kde2/share/man
  430  INFOPATH='/usr/info;/usr/local/info;/opt/gnome/info'
  431  KDEDIR=/opt/kde2
  432  export PATH MANPATH INFOPATH KDEDIR
  437  export HOME=/home/maufflic

./configure completes fine, but creates no Makefile. It creates all the
header files (config.h etc.) though.

This happens the same with or without cygwin patches applied to the
source.

In a fit of giving up I installed Window Maker - only to find i needeed
to recompile libtiff with LZW.

Interestingly, libtiff uses a non-standard configure, and this configures
and makes fine.

So it is purely a problem with GNU configure...

On 1/1/1970, "Dave Korn" <[EMAIL PROTECTED]> wrote:

>> -Original Message-
>> From: cygwin-owner On Behalf Of Igor Pechtchanski
>> Sent: 22 September 2004 07:17
>
>> On Wed, 22 Sep 2004, Mark Aufflick wrote:
>>
>> > ./configure in any package gives "error: cannot find input
>> file: \WINDOWS\oracle.ini" error
>
>> At a guess, something you installed earlier created an environment
>> variable with a name that either configure or something called by
>> configure uses.  You could try simply "env | grep oracle.ini".
>
>  Or there is some executable in the $PATH that has the same name as one of
>the tests or executables that configure depends on.  Try setting a really
>minimal path with
>
>export
>PATH=/bin:${SYSTEMROOT}/system32:${SYSTEMROOT}:${SYSTEMROOT}/system32/wbem
>
>and then run configure and see if it helps.
>
>cheers,
>  DaveK
>--
>Can't think of a witty .sigline today
>
>
>
>
>--
>Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>Problem reports:   http://cygwin.com/problems.html
>Documentation: http://cygwin.com/docs.html
>FAQ:   http://cygwin.com/faq/
>
>
>
> Personal Web Hosting from $5/monthwww.platformnetworks.net
> Forward undetected SPAM to:   [EMAIL PROTECTED]
>
>

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

Re: New packge: lighttpd-1.3.0

[Igor Pechtchanski]

On Thu, 23 Sep 2004, Gerrit P. Haase wrote:

> Hello Brian,
>
> >> I hate this package since I tried to build it the first time.
>
> > Part of the problem here is that "We don't support building under
> > Cygwin" is the official line from php-dev.
>
> Sigh;)
>
> > I've got php-4.3.8 working fine as a DSO with Apache (a single 3.1M
> > chgphp4.dll.)  This works for whatever modules/extensions are statically
> > included, but obviously that's not quite acceptable.  If you
> > "--enable-foo=shared" you get a foo.a file in the modules dir, but this
> > is not a win32 executable and so it cannot be dlopen()'d.  I'm still
> > working on how to get these extension modules working, when I do I'll
> > ITP the whole batch.
>
> If it works on Linux to get .so shared modules, why should it not work
> on Cygwin to get the modules the same way?

It turns out that it does (I just got through the same pains with O'Caml,
which, BTW, will support dynamic loading as soon as I release the updated
package).  You can even name the libraries ".so" with no loss of function
(fewer changes to Makefiles), but I've only tested on WinXP.  The biggest
problem with Cygwin's shared modules is that any unresolved dependencies
have to be resolved at build time, so you end up with .so's depending on
other .so's, which have to be in the PATH.

> I have already half the way through, I'll hopefully get a shared
> library now and then I'll try to get the modules shared too.

I'd be glad to share my experiences of the O'Caml build (which also had an
added problem that it relied on .so's being able to load symbols from the
application that loaded them, a la Linux).  It turns out that, as long as
the dependencies can be found in the PATH and all the symbols are moved to
shared libraries, it wasn't that painful after all.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing."  -- Dr. Jubal Harshaw

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

Re: New packge: lighttpd-1.3.0

[Gerrit P. Haase]

Hello Brian,

>> I hate this package since I tried to build it the first time.

> Part of the problem here is that "We don't support building under
> Cygwin" is the official line from php-dev.

Sigh;)

> I've got php-4.3.8 working fine as a DSO with Apache (a single 3.1M
> chgphp4.dll.)  This works for whatever modules/extensions are statically
> included, but obviously that's not quite acceptable.  If you
> "--enable-foo=shared" you get a foo.a file in the modules dir, but this
> is not a win32 executable and so it cannot be dlopen()'d.  I'm still
> working on how to get these extension modules working, when I do I'll
> ITP the whole batch.

If it works on Linux to get .so shared modules, why should it not work
on Cygwin to get the modules the same way?

I have already half the way through, I'll hopefully get a shared
library now and then I'll try to get the modules shared too.


Gerrit
-- 
=^..^=



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

Re: CYGWIN + APCHE + Net::SMTP

[Gerrit P. Haase]

Hallo Prakash,

Am Mittwoch, 22. September 2004 um 23:49 schriebst du:

> I have a simple perl mail program mail.pl (pasted at the end of this
> mail). In the cygwin environment it is able to send mail out when I run
> it from the command line.

> I also have apache2 running in my cygwin environment. When I run mail.pl
> as a CGI script it is not able to connect to the the smtp server. The
> Socket connection is failing (as I noticed after putting some error
> prints in SMTP.pm).

Are other CGIs are working?  The last time I tried to build Apache2
the CGI was broken completely (it worked ok the same day with Apache1,
so for sure not a Cygwin or Windows issue).

Gerrit
-- 
=^..^=



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

[ANNOUNCEMENT] Updated: grace-5.1.17-1

[Volker Quetschke]

grace-5.1.17-1 has been uploaded to the Cygwin net distribution.

DESCRIPTION:

Grace is a WYSIWYG tool to make two-dimensional plots of numerical data.
It runs under various (if not all) flavors of Unix with X11 and M*tif
(LessTif or Motif). Its capabilities are roughly similar to GUI-based
programs like Sigmaplot or Microcal Origin plus script-based tools like
Gnuplot or Genplot. Its strength lies in the fact that it combines the
convenience of a graphical user interface with the power of a scripting
language which enables it to do sophisticated calculations or perform
automated tasks."

NEWS:
=
New upstream release, see

for a detailed list of changes.


INSTALLATION:
=
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.


QUESTIONS:
==
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.

If you want to make a point or ask a question, the Cygwin mailing list
is the appropriate place.  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.


-- 
PGP/GPG key  (ID: 0x9F8A785D)  available  from  wwwkeys.de.pgp.net
key-fingerprint 550D F17E B082 A3E9 F913  9E53 3D35 C9BA 9F8A 785D


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

RE: CYGWIN + APCHE + Net::SMTP

[Prakash Khemani]

A similar problem occurs when I use /usr/sbin/ssmtp instead of Perl's
Net::SMTP.

I am able to send mail using /usr/sbin/ssmtp from the cygin shell cmd
line.

But when ssmtp is invoked from a perl script inside Apache2's CGI
environment (sunning on Windows XP and cygwin) - I get the following
error


ssmtp: Cannot open mail.eng.netscaler.com:25

So, I guess the question is why am I not able to open socket connections
in a process that is spawned by Apache (running in the Cygwin
environment)?

Thanks,
Prakash

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
> Of Prakash Khemani
> Sent: Wednesday, September 22, 2004 3:30 PM
> To: [EMAIL PROTECTED]
> Subject: Re: CYGWIN + APCHE + Net::SMTP
> 
> Mail.pl works fine in the sysbash shell.
> 
> Thanks,
> Prakash
> 
> --
> Prakash Khemani wrote:
> >
> > I have a simple perl mail program mail.pl (pasted at the end of this
> > mail). In the cygwin environment it is able to send mail out when I
> run
> > it from the command line.
> >
> > I also have apache2 running in my cygwin environment. When I run
> mail.pl
> > as a CGI script it is not able to connect to the the smtp server.
The
> > Socket connection is failing (as I noticed after putting some error
> > prints in SMTP.pm).
> >
> > The apache server is running as SYSTEM user. In the command line I
run
> > it with user Khemani's permissions.
> 
> I've seen this before and IIRC it was due to some kind of account
> restrictions imposed on the SYSTEM account in later versions of
> windows.  Get a command prompt as the SYSTEM account and try running
the
> script from it -- if it fails that will rule out the whole Apache side
> of things.  To do this google these archives for "sysbash" or just use
> the "now /interactive" command by hand.
> 
> If this is the case then you will probably have to either grant SYSTEM
> those revoked privileges or run Apache as one of the other system
> accounts, such as "NETWORK SERVICE" (which is new in XP and later.)
> 
> 
> --
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:   http://cygwin.com/problems.html
> Documentation: http://cygwin.com/docs.html
> FAQ:   http://cygwin.com/faq/


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

Re: New packge: lighttpd-1.3.0

[Brian Dessent]

"Gerrit P. Haase" wrote:

> if you ask me, the PHP build system is broken.
> 
> I tried to build 5.0.1, I'm getting no lipphp, no shared modules,
> libdb is not found...  If you specify an extension and the relevant
> dependency is not available the configure exits, it is terrible, this
> sucks really.
> 
> How do I need to configure to get a shared library?  Shared modules?
> Why isn't there a howto about this in the source dist included?  Who
> is responsible for this broken system?
> 
> If I call `make libphp5.la` I get a static archive, no DLL, it is
> weird...
> 
> I hate this package since I tried to build it the first time.

Part of the problem here is that "We don't support building under
Cygwin" is the official line from php-dev.

I've got php-4.3.8 working fine as a DSO with Apache (a single 3.1M
chgphp4.dll.)  This works for whatever modules/extensions are statically
included, but obviously that's not quite acceptable.  If you
"--enable-foo=shared" you get a foo.a file in the modules dir, but this
is not a win32 executable and so it cannot be dlopen()'d.  I'm still
working on how to get these extension modules working, when I do I'll
ITP the whole batch.

Brian

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

Re: problem with cygwin box (termcap?)

[Christopher Faylor]

On Wed, Sep 22, 2004 at 02:58:20PM -0700, Brian Dessent wrote:
>David Arnstein wrote:
>
>> I launch a cygwin "box" (command window) on my Windows 2000 machine.
>> I run ssh to connect to a shell account running a variant of BSD Unix.
>> 
>> Whenever I use the program "less" on that shell account, it complains
>> "WARNING: terminal is not fully functional."
>> Another user has stated that tin (the news reader) complains
>> "tin: Terminal must have clear to end-of-screen (cd)
>> I suspect that these issues are related.  Can the termcap entry for
>> cygwin be improved?  Or is this truly a limitation of the cygwin box?
>
>You could also just use rxvt instead of of a cmd.exe window, which
>should result in $TERM being set to "rxvt" which should be recognised
>everywhere.  If for whatever reason you must use cmd.exe then follow the
>advice already in the thread to add the "cygwin" terminal info to the
>database on the remote end.

Also, the "ansi" or "vt100" TERM types may work acceptably on the remote
system depending on what the application is trying to do.

cgf

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

Re: Lot of undefined symbols at link time, even with -l option on good libraries

[Cliff Hones]

Larry Hall wrote:
> At 01:14 PM 9/22/2004, you wrote:
> 
>>>-Original Message-
>>>From: Frédéric ORMANCEY
>>>Sent: 22 September 2004 18:07
>>
>>>I did it, but it don't work !
>>
>> Ah, ok, that was not clear from your last message!
>>
>>
>>>The --enable-stdcall-fixup option suppress one warning on top 
>>>of linker output trace :
>>>AVERTISSEMENT: résolution de _GetModuleHandleA par un 
>>>lien vers [EMAIL PROTECTED]
>>>and unfortunatly leave ALL other errors with no effect on it.
>>
>> I see.  Hmm.  That's very strange; it should affect all the errors - that
>>is, if they're all the same kind of error.  OTOH it could be that you've
>>gotten the calling conventions wrong with the other pragmas, so that's why
>>--enable-stdcall-fixup doesn't work for them; there must be some different
>>reason why the errors are caused, since they behave differently.
>>
>> You might care to experiment with the "--enable-auto-import" and, failing
>>that, "--enable-extra-pe-debug" options as well.
> 
> Or Frédéric could try specifying the link symbol he wants in the pragma
> as suggested by an earlier poster (sorry, the thread is broken in the 
> archives and I didn't put any effort into wading through the messages 
> to trace it all back to that message).

That was me - but it seems Dave Korn's post broke the thread.  But isn't
it easy enough to sort messages on subject?

Anyway, I tried a noddy example, as follows...

[EMAIL PROTECTED] ~
$ cat imp.adb
procedure imp is
  procedure Doit(A : integer; B : boolean; C : character);
  pragma Import (Stdcall, Doit, "FormatMessageA");
begin
  Doit(1, true, 'x');
end;

[EMAIL PROTECTED] ~
$ gnat compile imp.adb
gcc -c imp.adb

[EMAIL PROTECTED] ~
$ nm imp.o
 b .bss
 d .data
 t .text
 U [EMAIL PROTECTED]
 T __ada_imp

So Gnat is generating a stdcall-style linker symbol with @12 (the
parameter block size) correctly appended.  If Frédéric is not seeing
this with stdcall, it is probably an indication that the specification
used for Doit is wrong - ie it hasn't been defined to take any parameters.

If you change the pragma line to
pragma Import (Stdcall, Doit, Link_Name => "FormatMessageA");
the symbol is generated as
 U [EMAIL PROTECTED]

so you can generate it without the leading underscore, but with the
stdcall postfix, if you wish.

[Note - the above is just an example - the *real* FormatMessageA should
take 7 words (28 bytes) of parameters, and the Ada spec should match the
kernel32 definition.]


-- Cliff


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

Re: CYGWIN + APCHE + Net::SMTP

[Prakash Khemani]

Mail.pl works fine in the sysbash shell.

Thanks,
Prakash

--
Prakash Khemani wrote:
> 
> I have a simple perl mail program mail.pl (pasted at the end of this
> mail). In the cygwin environment it is able to send mail out when I
run
> it from the command line.
> 
> I also have apache2 running in my cygwin environment. When I run
mail.pl
> as a CGI script it is not able to connect to the the smtp server. The
> Socket connection is failing (as I noticed after putting some error
> prints in SMTP.pm).
> 
> The apache server is running as SYSTEM user. In the command line I run
> it with user Khemani's permissions.

I've seen this before and IIRC it was due to some kind of account
restrictions imposed on the SYSTEM account in later versions of
windows.  Get a command prompt as the SYSTEM account and try running the
script from it -- if it fails that will rule out the whole Apache side
of things.  To do this google these archives for "sysbash" or just use
the "now /interactive" command by hand.

If this is the case then you will probably have to either grant SYSTEM
those revoked privileges or run Apache as one of the other system
accounts, such as "NETWORK SERVICE" (which is new in XP and later.)


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

Re: CYGWIN + APCHE + Net::SMTP

[Brian Dessent]

Prakash Khemani wrote:
> 
> I have a simple perl mail program mail.pl (pasted at the end of this
> mail). In the cygwin environment it is able to send mail out when I run
> it from the command line.
> 
> I also have apache2 running in my cygwin environment. When I run mail.pl
> as a CGI script it is not able to connect to the the smtp server. The
> Socket connection is failing (as I noticed after putting some error
> prints in SMTP.pm).
> 
> The apache server is running as SYSTEM user. In the command line I run
> it with user Khemani's permissions.

I've seen this before and IIRC it was due to some kind of account
restrictions imposed on the SYSTEM account in later versions of
windows.  Get a command prompt as the SYSTEM account and try running the
script from it -- if it fails that will rule out the whole Apache side
of things.  To do this google these archives for "sysbash" or just use
the "now /interactive" command by hand.

If this is the case then you will probably have to either grant SYSTEM
those revoked privileges or run Apache as one of the other system
accounts, such as "NETWORK SERVICE" (which is new in XP and later.)

Brian

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

Re: problem with cygwin box (termcap?)

[Brian Dessent]

David Arnstein wrote:

> I launch a cygwin "box" (command window) on my Windows 2000 machine.
> I run ssh to connect to a shell account running a variant of BSD Unix.
> 
> Whenever I use the program "less" on that shell account, it complains
> "WARNING: terminal is not fully functional."
> Another user has stated that tin (the news reader) complains
> "tin: Terminal must have clear to end-of-screen (cd)
> I suspect that these issues are related.  Can the termcap entry for
> cygwin be improved?  Or is this truly a limitation of the cygwin box?

You could also just use rxvt instead of of a cmd.exe window, which
should result in $TERM being set to "rxvt" which should be recognised
everywhere.  If for whatever reason you must use cmd.exe then follow the
advice already in the thread to add the "cygwin" terminal info to the
database on the remote end.

Brian

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

CYGWIN + APCHE + Net::SMTP

[Prakash Khemani]

I have a simple perl mail program mail.pl (pasted at the end of this
mail). In the cygwin environment it is able to send mail out when I run
it from the command line.

I also have apache2 running in my cygwin environment. When I run mail.pl
as a CGI script it is not able to connect to the the smtp server. The
Socket connection is failing (as I noticed after putting some error
prints in SMTP.pm).

The apache server is running as SYSTEM user. In the command line I run
it with user Khemani's permissions.

What could be going wrong?

Thanks,
Prakash

#!/usr/bin/perl
## mail.pl

print "Content-Type: text/plain\r\n\r\n";

$mailHost = "10.10.0.91";
$helloHost = "mydesktop.eng.netscaler.com";

$from = '[EMAIL PROTECTED]';
@to = ('[EMAIL PROTECTED]');
$smtp = Net::SMTP->new( $mailHost, Hello => $helloHost );
if ($smtp) {
$smtp->mail($from);
$smtp->to(@to, { SkipBad => 1 } );
$smtp->data("ABCD");
$smtp->dataend();
if ($smtp->ok()) {
print "OK\n"; ## comes here at cmd line
} else {
print "Not OK\n";
}
} else {
print "Not Connected\n"; ## comes here as CGI
}

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

Re: cygwin, libtool, gdb: dll not found

[Jan Nieuwenhuizen]

Charles Wilson writes:

> I dunno, Jan -- I'm not sure the problem you are seeing is related --
> because older gcc's didn't put const items into .rdata anyway.  But,
> there were a number of other fixes in libtool-1.5.10(cygwin),

Oh, well, I'll have a go with your latest release.

> Give it a shot, but I don't think the .rdata issue is causing your
> problem.

Is there a way to actually see what's going wrong?

Jan.

-- 
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien   | http://www.lilypond.org

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

Re: cygwin, libtool, dlpreopen, and .rdata

[Charles Wilson]

Shankar Unni wrote:
Brian Ford wrote:
Yes, I see.  I hope Danny Smith might weigh in here?
http://sources.redhat.com/ml/binutils/2004-02/msg3.html

I would argue that this is gcc's responsibility. If a const structure 
variable contains *any* code or data addresses, it's not safe to put it 
in .rdata (or .rodata, whatever the platform calls it), because of 
relocation issues.

So rather than detect a "DLL import", I'd say *any* function addresses 
Actually, *function* addresses are fine; they don't get relocated (at 
least, not by the runtime-pseudo-reloc gobbledygook).  It's only the 
addresses of DATA items exported by DLLs that get relocated in this way.

AND, they get relocated IF AND ONLY IF you are linking to a DLL.  If you 
link to a static library, no runtime relocation is necessary because the 
linker resolves all of the addresses in question at link time.  And if 
(really the same issue as a static lib) the addresses in question come 
from a standalone .o (e.g. an extern data item in your own app, not one 
supplied by a library at all) then why shouldn't it be const -- and put 
in .rdata?

But how is gcc supposed to know that you're going to link to a DLL? 
(The same question applies to creating the trampolines for DATA exports 
in the first place, and that took some seriously hairy code and over a 
year to get it right, and stabilized).

Yeah, you could play it safe and just say "In x86, any structure or 
variable that is initialized with the address of any variable (but not 
function), should go into .data, not .rdata" -- and lose the benefits of 
const==.rdata for those structures.  But that "punishes" many common 
cases in the interests of making a few rare cases work properly.

Sometimes the answer really is "Don't do that.": don't declare structs 
const if they contain addresses of data coming from an external library.

in a const initializer should cause the variable to go into a regular 
.data section, without any complicated decision-making by binutils.

(Note: this is not the same problem that Danny talks about in that 
message - that usage was legitimate, and there was no attempt to have a 
const initialized variable with a data address.)
Correct.
--
Chuck
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Avail for test: libtool-1.5.10-1

[Dalibor Topic]

Charles Wilson wrote:
A new version of libtool is on the mirrors.  It's a routine update to 
the latest upstream release, but also includes a number of fixes:

FYI, all of these changes have been ported to CVS HEAD libtool, and 
accepted by the maintainers.  However, CVS HEAD libtool is still in 
fairly rough shape with respect to cygwin, and still fails 19 tests even 
with these changes.  I hope to begin resolving those issues soon (e.g. 
before libtool-2 hits the street).
Thanks! You rock!
cheers,
dalibor topic,
who now has to kick kaffe back into shape on cygwin :)
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: cygwin, libtool, dlpreopen, and .rdata

[Charles Wilson]

Gerrit P. Haase wrote:

Note, I found this problem in libtool-1.5.x, but it exists in HEAD, too.
 The following patch is against HEAD...

I'll try if it works ok with this solution.
Unless you have a reason to use CVS HEAD libtool, first try the 1.5.10-1 
release I just put on the mirrors.  CVS HEAD libtool is still flaky on 
cygwin even with these patches.

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

Re: cygwin, libtool, gdb: dll not found

[Charles Wilson]

Jan Nieuwenhuizen wrote:
Charles Wilson writes:

[cygwin list: I'm CC'ing this so that it goes into the archives, but
it's pretty technical about the innards of libtool...]

Great.  This addresses my yet unanswered problem that holds back guile 1.7.1
http://www.cygwin.com/ml/cygwin/2004-09/msg00883.html
I dunno, Jan -- I'm not sure the problem you are seeing is related -- 
because older gcc's didn't put const items into .rdata anyway.  But, 
there were a number of other fixes in libtool-1.5.10(cygwin), both mine, 
and the ordinary 1.5.6--1.5.8--1.5.10 march of progress.

Give it a shot, but I don't think the .rdata issue is causing your problem.
--
Chuck
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Using cygwin's GnuPG with enigmail

[Yaakov Selkowitz]

Ismael wrote:
Can this be safely done? Or would I have any drawback?
Sorry but searching the mailing list archives, I get in return any 
message signed using enigmal, so this is of no use. :)
Well I was doing this for quite a while, but I just upgraded to TB 0.8 
and the current version of Enigmail and I just get errors.  It could be 
something with my configuration though, so give it a try.

Yaakov

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

Re: problem with cygwin box (termcap?)

[Christopher Faylor]

On Wed, Sep 22, 2004 at 03:56:54PM -0400, David Arnstein wrote:
>I launch a cygwin "box" (command window) on my Windows 2000 machine.
>I run ssh to connect to a shell account running a variant of BSD Unix.
>
>Whenever I use the program "less" on that shell account, it complains
>   "WARNING: terminal is not fully functional."  
>Another user has stated that tin (the news reader) complains 
>   "tin: Terminal must have clear to end-of-screen (cd)
>I suspect that these issues are related.  Can the termcap entry for
>cygwin be improved?  Or is this truly a limitation of the cygwin box?

Cygwin's terminal emulation is not at fault.  It works fine locally,
after all.

I sincerely doubt that either of those programs uses termcap.

You need to set up a terminfo entry for cygwin on the remote system.
You can use the "infocmp" program to dump the entry and the "tic"
program on the remote computer to incorporate it.  There may be
a way to set this up on the remote computer without being root,
too, but I'll leave that to you to research.

cgf

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

Avail for test: libtool-1.5.10-1

[Charles Wilson]

A new version of libtool is on the mirrors.  It's a routine update to 
the latest upstream release, but also includes a number of fixes:

1) Gerrit's .rdata fix (with some additions)
2) testsuite corrections
3) backports of CVS HEAD patches to ltdl.[h,c] by Gary Vaughan:
   28-gary-canonicalise-__WINDOWS__.patch
   29-gary-cygwin-tweak-loaders.patch
4) rollup of all ealier cygwin-libtool patches
This version of libtool, using the latest gcc (3.3.3-3 AND 3.4.1-1) and 
the most recent binutils (20040725-2) passes all but two of the libtool 
self-tests (and those two are longstanding issues that shouldn't affect 
"real" users).  Hopefully this release will address some of the problems 
that folks have been reporting recently.

Please test.
FYI, all of these changes have been ported to CVS HEAD libtool, and 
accepted by the maintainers.  However, CVS HEAD libtool is still in 
fairly rough shape with respect to cygwin, and still fails 19 tests even 
with these changes.  I hope to begin resolving those issues soon (e.g. 
before libtool-2 hits the street).

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

Re: Bash returns incorrect process status

[Christopher Faylor]

On Wed, Sep 22, 2004 at 12:31:34PM -0400, Ronald Landheer-Cieslak wrote:
>Dolton Tony AB wrote:
>>I've noticed that bash doesn't get issued too often.
>It doesn't for three reasons:
>1. the maintainer for Cygwin (that would be me) is very busy
>2. The current version of Bash is very, very stable
>3. I'm hesitant (reluctant, even) to let a new release of Bash go out
>   the door without proper testing, even if it does fix a bug reported
>   on this list every-so-often - i.e. I don't jump on every patch to
>   apply it tout-de-suite and send out a new release: there's too much
>   that depends on Bash.. That, and reason #1..

These are all excellent reasons (especially 2 and 3), FWIW.  Bash is
such a crucial part of the release that it pays to be cautious.

cgf

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

Re: cygwin, libtool, dlpreopen, and .rdata

[Charles Wilson]

Brian Ford wrote:
On Wed, 22 Sep 2004, Charles Wilson wrote:

[cygwin list: I'm CC'ing this so that it goes into the archives, but
it's pretty technical about the innards of libtool...]

This doesn't seem libtool related at all to me (other than it's a gcc bug
that affects libtool).
Oh, except for the fact that there's a libtool patch included in the 
email.  Besides, it's not really a gcc bug; it's a new feature, that 
does exactly what it should do -- except that it shouldn't be used in te 
way that libtool is forcing it to be used.  const "variables" exported 
from a DLL absolutely should go in .rdata[1].  Const "variables" in an 
application absolutely should go in .rdata.  No problems; and many benefits.

It's when an application declares a variable const, which is supposed to 
hold the address of a DATA item imported from a DLL, that is the problem 
-- because, thanks to the behind-the-scenes runtime-reloc stuff, *it 
isn't really const*.  In that case, it should not be declared const.

Libtool creates a little file that declares a const "variable" which 
holds an address that falls under the definition above.  Libtool 
shouldn't do that -- at least until gcc/ld get a WHOLE lot smarter (and 
precognitive, too!)


With newer gcc's (cygwin version numbers 3.3.3-3, 3.4.1-1, but not
3.3.1-3), const variables are placed in an .rdata section.  This causes
problems when those variables contain references to OTHER vars that are
imported from a dll -- because the runtime relocation machinery can't
fixup the address, since the variable holding the address is const --
and is in .rdata!

Yes, I see.  I hope Danny Smith might weigh in here?
http://sources.redhat.com/ml/binutils/2004-02/msg3.html
[1] DATA items imported into an app, when the DATA item itself is in the 
DLL's .rdata section, is what is addressed by Danny's binutils patch. 
The problem I'm pointing out is the opposite, and concerns the *pointer* 
that should hold the address of the DLL's DATA item.  That pointer is in 
the application, and is declared const -- and therefore goes into the 
*application's* .rdata section.   Where the runtime-reloc machinery 
can't update it.

--
Chuck

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

Re: problem with cygwin box (termcap?)

[David Arnstein]

Larry Hall wrote:
What terminal are you using?  'cygwin'?  That's the default.  It's 
unlikely that your BSD box knows it if you haven't told it about it.  Do
so or try a related terminal type.
Yes.  My environment variable TERM is set to "cygwin" on the BSD Unix 
shell account.  The BSD Unix shell account uses the "cygwin" termcap 
entry that is found in the /etc/termcap file published by cygwin.com.
--
David Arnstein
[EMAIL PROTECTED]

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

Re: problem with cygwin box (termcap?)

[Larry Hall]

At 03:56 PM 9/22/2004, you wrote:
>I launch a cygwin "box" (command window) on my Windows 2000 machine.
>I run ssh to connect to a shell account running a variant of BSD Unix.
>
>Whenever I use the program "less" on that shell account, it complains
>"WARNING: terminal is not fully functional."  
>Another user has stated that tin (the news reader) complains 
>"tin: Terminal must have clear to end-of-screen (cd)
>I suspect that these issues are related.  Can the termcap entry for
>cygwin be improved?  Or is this truly a limitation of the cygwin box?


What terminal are you using?  'cygwin'?  That's the default.  It's 
unlikely that your BSD box knows it if you haven't told it about it.  Do
so or try a related terminal type.



--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


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

problem with cygwin box (termcap?)

[David Arnstein]

I launch a cygwin "box" (command window) on my Windows 2000 machine.
I run ssh to connect to a shell account running a variant of BSD Unix.

Whenever I use the program "less" on that shell account, it complains
"WARNING: terminal is not fully functional."  
Another user has stated that tin (the news reader) complains 
"tin: Terminal must have clear to end-of-screen (cd)
I suspect that these issues are related.  Can the termcap entry for
cygwin be improved?  Or is this truly a limitation of the cygwin box?

Thanks for any ideas.
-- 
David Arnstein   
[EMAIL PROTECTED]  

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

Re: New packge: lighttpd-1.3.0

[Gerrit P. Haase]

Hallo Reini,

if you ask me, the PHP build system is broken.

I tried to build 5.0.1, I'm getting no lipphp, no shared modules,
libdb is not found...  If you specify an extension and the relevant
dependency is not available the configure exits, it is terrible, this
sucks really.

How do I need to configure to get a shared library?  Shared modules?
Why isn't there a howto about this in the source dist included?  Who
is responsible for this broken system?

If I call `make libphp5.la` I get a static archive, no DLL, it is
weird...

I hate this package since I tried to build it the first time.


Am Mittwoch, 22. September 2004 um 17:38 schriebst du:

>> Should we build statically?

> no. that's about 17MB for each php.exe or dll :)

My executable is 8 MB stripped.


> you want pdflib and pspell also?
> see my list. pdflib is non-free I think.

I don't know, pdflib-lite is available as source, isn't the license
OSI approved?  I don't have aspell installed, but if it is available
as shared module, why not?

> I'd need xdebug also, maybe apd.
> best would be to add all the modules which are supported and in the 
> nightly snaps.


>> That would be OK if all the extensions are built as modules, but building
>> everything into one php executable would make it pretty big, wouldn't it?

> the extensions are just shared interfaces to the existing dll.
> only mysql and some esoteric ones, which are not in the usual setup are
> static.

Why don't I get a shared libphp?  How to configure it to get it with
shared modules?


Gerrit
-- 
=^..^=



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

Re: setup.log in /var/log/

[Igor Pechtchanski]

On Wed, 22 Sep 2004, Angelo Graziosi (D. Zanello) wrote:

> Hi,
> I have noted that in /var/log/ there are setup.log and setup.log.full.
>
> setup.log contains the description of all my CYGWIN packages installation
> from the first installation (Jun 2003): it is a file of 250 MB! Can I
> remove these files without corrupt the CYGWIN installation?

Yes.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing."  -- Dr. Jubal Harshaw

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

[ANNOUNCEMENT] Updated: OpenSSH-3.9p1-2

[Corinna Vinschen]

I've just updated the version of OpenSSH to 3.9p1-2.

This is a Cygwin specific bugfix release.

- /usr/bin/ssh-host-config has a fix for the problem that adding
  the sshd_server account to the Administrators group fails on 2K3.

- The login problem which manifests it self in the syslog entry
  "permanently_set_uid: was able to restore old [e]gid" should be
  solved, too.

NOTE NOTE NOTE:

If you're still using Cygwin 1.5.10 or earlier, you *must* add the -r
option when starting the sshd daemon, if you want to use privilege
separation.  Either that, or disable privilege separation in
/etc/sshd_config by setting

  UsePrivilegeSeparation no

This does not happen when running under Cygwin 1.5.11 or later.


To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

[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
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Latest snapshot with XP SP2 and unison and cvs

[Karl M]

Hi Dave...
Sorry, I thought I covered all details, but...
The firewall is off...I am behind a real firewall.
The hanging can be averted by not using XP SP2 or by using a down rev 
cygwin1.dll

Thanks,
...Karl

From: "Dave Korn" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: RE: Latest snapshot with XP SP2 and unison and cvs
Date: Wed, 22 Sep 2004 17:48:51 +0100
> -Original Message-
> From: cygwin-owner On Behalf Of Karl M
> Sent: 22 September 2004 16:19
> Hi All...
> It appears to be a client problem. An XP SP2 server is fine,
> but the XP SP2
> client (with the latest cygwin1.dll or snapshots I tried) hangs.
> >>On Sep 18 12:23, Karl M wrote:
> >> > Hi All...
> >> >
> >> > I just updated an xp machine to sp2 and unison-2.9.1 (the win32
> >>version)
> >> > using ssh (cygwin) started hanging.
  Wait a minute.  You're saying it was all working fine, and then you put
sp2 on and it stopped working?  IOW, nothing about cygwin changed?  Then 
the
problem is probably because of the SP2 firewall, isn't it?

  NB. If you wish to test this theory by switching the firewall off, you'd
probably better disconnect both machines from the network and wire them
directly together with a crossover cable..
cheers,
  DaveK
--
Can't think of a witty .sigline today
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/
_
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

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

RE: Lot of undefined symbols at link time, even with -l option on good libraries

[Larry Hall]

At 01:14 PM 9/22/2004, you wrote:
>> -Original Message-
>> From: Frédéric ORMANCEY
>> Sent: 22 September 2004 18:07
>
>> I did it, but it don't work !
> 
>  Ah, ok, that was not clear from your last message!
>
>> The --enable-stdcall-fixup option suppress one warning on top 
>> of linker output trace :
>> AVERTISSEMENT: résolution de _GetModuleHandleA par un 
>> lien vers [EMAIL PROTECTED]
>> and unfortunatly leave ALL other errors with no effect on it.
>
>  I see.  Hmm.  That's very strange; it should affect all the errors - that
>is, if they're all the same kind of error.  OTOH it could be that you've
>gotten the calling conventions wrong with the other pragmas, so that's why
>--enable-stdcall-fixup doesn't work for them; there must be some different
>reason why the errors are caused, since they behave differently.
>
>  You might care to experiment with the "--enable-auto-import" and, failing
>that, "--enable-extra-pe-debug" options as well.


Or Frédéric could try specifying the link symbol he wants in the pragma
as suggested by an earlier poster (sorry, the thread is broken in the 
archives and I didn't put any effort into wading through the messages 
to trace it all back to that message).



--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


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

g++-3.4.1 / CVS small cygwin cross compiler problems

[Jan Nieuwenhuizen]

Due to libtool/gcc related problems I tried building a cross compiler
linux->cygwin.  The C compiler works fine, but the c++ compiler has
linux->three small problems

  * libstdc++-v3/crossconfig.m4 is missing an entry for cygwin
  * libstdc++-v3/configure.ac defines GCC_NO_EXECUTABLES,
which in turn forbids linking checks (why?), which breaks
during configuring
  * there's a compile error wrt fseeko64 and ftello64 (that's why
cygwin is CC'd), see error log

Using the patch below, the cross compiler builds fine, but I'm quite
sure there are better fixes.

Jan.


--- libstdc++-v3/crossconfig.m4~2004-09-21 23:11:24 +0200
+++ libstdc++-v3/crossconfig.m4 2004-09-21 23:19:34 +0200
@@ -138,7 +138,7 @@
;;
 esac
 ;;
-  *-linux* | *-uclinux* | *-gnu* | *-kfreebsd*-gnu | *-knetbsd*-gnu)
+  *-linux* | *-uclinux* | *-gnu* | *-kfreebsd*-gnu | *-knetbsd*-gnu|*-cygwin*)
 AC_CHECK_HEADERS([nan.h ieeefp.h endian.h sys/isa_defs.h \
   machine/endian.h machine/param.h sys/machine.h sys/types.h \
   fp.h float.h endian.h inttypes.h locale.h float.h stdint.h])
@@ -135,7 +151,7 @@
 # For LFS.
 AC_DEFINE(HAVE_INT64_T)
 case "$target" in
-  *-uclinux*)
+  *-uclinux*|*-cygwin*)
 # Don't enable LFS with uClibc
 ;;
   *)
--- libstdc++-v3/configure.ac~  2004-09-22 10:08:58 +0200
+++ libstdc++-v3/configure.ac   2004-09-22 10:07:48 +0200
@@ -42,7 +42,8 @@
 if test "$build" != "$host"; then
   # We are being configured with some form of cross compiler.
   GLIBCXX_IS_NATIVE=false
-  GCC_NO_EXECUTABLES
+  # no executables means no linking, nowadays? --jcn
+  # GCC_NO_EXECUTABLES
 else
   GLIBCXX_IS_NATIVE=true
 fi
@@ -140,7 +140,8 @@
   GLIBCXX_CHECK_INT64_T
 
   # For LFS support.
-  GLIBCXX_CHECK_LFS
+  # breaks Cygwin build --jcn
+  # GLIBCXX_CHECK_LFS
 
   AC_LC_MESSAGES
 


/var/tmp/deb/gcc-i686-cygwin-3.4.1/build/gcc/xgcc -shared-libgcc 
-B/var/tmp/deb/gcc-i686-cygwin-3.4.1/build/gcc/ -nostdinc++ 
-L/var/tmp/deb/gcc-i686-cygwin-3.4.1/build/i686-cygwin/libstdc++-v3/src 
-L/var/tmp/deb/gcc-i686-cygwin-3.4.1/build/i686-cygwin/libstdc++-v3/src/.libs 
-B/usr/i686-cygwin/bin/ -B/usr/i686-cygwin/lib/ -isystem /usr/i686-cygwin/include 
-isystem /usr/i686-cygwin/sys-include 
-I/var/tmp/deb/gcc-i686-cygwin-3.4.1/build/i686-cygwin/libstdc++-v3/include/i686-cygwin
 -I/var/tmp/deb/gcc-i686-cygwin-3.4.1/build/i686-cygwin/libstdc++-v3/include 
-I/var/tmp/deb/gcc-i686-cygwin-3.4.1/src/libstdc++-v3/libsupc++ -DATTRIBUTE_NORETURN= 
-DATTRIBUTE_UNUSED= -I/cygwin/usr/include/w32api -L/cygwin/usr/lib/w32api -g -O2 
-fno-implicit-templates -Wall -W -Wwrite-strings -Wcast-qual 
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections -c 
../../../../src/libstdc++-v3/src/globals_io.cc -o globals_io.o
../../../../src/libstdc++-v3/src/globals_io.cc:1: warning: -ffunction-sections may 
affect debugging on some targets
In file included from 
/var/tmp/deb/gcc-i686-cygwin-3.4.1/build/i686-cygwin/libstdc++-v3/include/i686-cygwin/bits/gthr.h:96,
 from ../../../../src/libstdc++-v3/src/globals_io.cc:29:
/cygwin/usr/include/pthread.h:181: warning: weak declaration of 'int 
pthread_once(pthread_once_t*, void (*)())' not supported
/cygwin/usr/include/pthread.h:145: warning: weak declaration of 'int 
pthread_key_create(__pthread_key_t**, void (*)(void*))' not supported
/cygwin/usr/include/pthread.h:146: warning: weak declaration of 'int 
pthread_key_delete(__pthread_key_t*)' not supported
/cygwin/usr/include/pthread.h:143: warning: weak declaration of 'void* 
pthread_getspecific(__pthread_key_t*)' not supported
/cygwin/usr/include/pthread.h:192: warning: weak declaration of 'int 
pthread_setspecific(__pthread_key_t*, const void*)' not supported
/cygwin/usr/include/pthread.h:138: warning: weak declaration of 'int 
pthread_create(__pthread_t**, __pthread_attr_t* const*, void*(*)(void*), void*)' not 
supported
/cygwin/usr/include/pthread.h:152: warning: weak declaration of 'int 
pthread_mutex_lock(__pthread_mutex_t**)' not supported
/cygwin/usr/include/pthread.h:154: warning: weak declaration of 'int 
pthread_mutex_trylock(__pthread_mutex_t**)' not supported
/cygwin/usr/include/pthread.h:155: warning: weak declaration of 'int 
pthread_mutex_unlock(__pthread_mutex_t**)' not supported
In file included from ../../../../src/libstdc++-v3/src/globals_io.cc:34:
/var/tmp/deb/gcc-i686-cygwin-3.4.1/build/i686-cygwin/libstdc++-v3/include/ext/stdio_sync_filebuf.h:
 In member function `virtual std::streampos __gnu_cxx::stdio_sync_filebuf<_CharT, 
_Traits>::seekoff(std::streamoff, std::_Ios_Seekdir, std::_Ios_Openmode)':
/var/tmp/deb/gcc-i686-cygwin-3.4.1/build/i686-cygwin/libstdc++-v3/include/ext/stdio_sync_filebuf.h:170:
 error: there are no arguments to `fseeko64' that depend on a template parameter, so a 
declaration of `fseeko64' must be available
/var/tmp/deb/gcc-i686-cygwin-3.4.1/build/i686-cygwin/libstdc++-v3/include/ext/stdio_sync_filebuf.h:170:
 error: (if you u

RE: Lot of undefined symbols at link time, even with -l option on good libraries

[Dave Korn]

> -Original Message-
> From: Frédéric ORMANCEY
> Sent: 22 September 2004 18:07

> I did it, but it don't work !
 
  Ah, ok, that was not clear from your last message!

> The --enable-stdcall-fixup option suppress one warning on top 
> of linker output trace :
> AVERTISSEMENT: résolution de _GetModuleHandleA par un 
> lien vers [EMAIL PROTECTED]
> and unfortunatly leave ALL other errors with no effect on it.

  I see.  Hmm.  That's very strange; it should affect all the errors - that
is, if they're all the same kind of error.  OTOH it could be that you've
gotten the calling conventions wrong with the other pragmas, so that's why
--enable-stdcall-fixup doesn't work for them; there must be some different
reason why the errors are caused, since they behave differently.

  You might care to experiment with the "--enable-auto-import" and, failing
that, "--enable-extra-pe-debug" options as well.

cheers, 
  DaveK
-- 
Can't think of a witty .sigline today


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

Re: cygwin, libtool, dlpreopen, and .rdata

[Shankar Unni]

Brian Ford wrote:
Yes, I see.  I hope Danny Smith might weigh in here?
http://sources.redhat.com/ml/binutils/2004-02/msg3.html
I would argue that this is gcc's responsibility. If a const structure 
variable contains *any* code or data addresses, it's not safe to put it 
in .rdata (or .rodata, whatever the platform calls it), because of 
relocation issues.

So rather than detect a "DLL import", I'd say *any* function addresses 
in a const initializer should cause the variable to go into a regular 
.data section, without any complicated decision-making by binutils.

(Note: this is not the same problem that Danny talks about in that 
message - that usage was legitimate, and there was no attempt to have a 
const initialized variable with a data address.)

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

[Fwd: Re: Lot of undefined symbols at link time, even with -l option on good libraries]

[Frédéric ORMANCEY]

I did it, but it don't work !
The --enable-stdcall-fixup option suppress one warning on top of linker 
output trace :
   AVERTISSEMENT: résolution de _GetModuleHandleA par un lien vers 
[EMAIL PROTECTED]
and unfortunatly leave ALL other errors with no effect on it.

Dave Korn a écrit :
-Original Message-
From: cygwin-owner On Behalf Of Frédéric ORMANCEY
Sent: 22 September 2004 13:31
   

 

problem seems coming from trailing @nn in library symbols.
cygwin linker don't know how to translate a reference like 
_FormatMessageA to [EMAIL PROTECTED]
the calling convention ( C, Stdcall, C++, ... ) has effect only on 
underscore preceeding symbol name, not on @nn notation.

It seems there is no solutions to this problem, I will 
abandon cygwin to 
build my Ada application under windows :-(
   

 You didn't read that letter that you were replying to very well:
 

default for Windows).  If you cannot get Ada to ask for the 
 

proper symbol, 
   

you could try using the '--enable-stdcall-fixup' option (for 
 

'ld') to 
   

attempt to massage away the problem.  
 

 It doesn't seem from your reply that you have actually tried this.  Note
that to pass the option through to the linker from the compiler you would
need to add "-Wl," before it, but if you have a separate link stage in your
makefile that invokes the linker directly that would not be necessary.
   cheers, 
 DaveK
 

--
*_Frédéric  ORMANCEY_*
Atos Origin Systems Integration  

/rue Ampère - BP 475  
31315 Labège Cedex/

/Tel// /: 05 61 39 75 21
/Fax /: 05 61 39 16 65 
[EMAIL PROTECTED] 
www.si.fr.atosorigin.com

===
Ce message électronique est confidentiel. Il peut contenir des 
informations protégées par le secret professionnel, le secret de 
fabrication ou autres règles légales. Si vous recevez ce message par 
erreur, il vous est interdit de le reproduire ou de le distribuer en 
tout ou partie, ou de le divulguer de quelque manière que ce soit à 
quelque personne que ce soit. Nous vous prions de bien vouloir en 
informer Atos Origin, par téléphone ou par retour d'e-mail puis de 
détruire le message et toutes copies de votre système informatique.
Le contenu de ce message ne reflète pas nécessairement ni les opinions 
d'Atos Origin ni celles des membres de son groupe. Bien que l'émetteur 
de ce message ait fait tout son possible pour maintenir son système 
informatique sans virus, il ne peut garantir que cette transmission ne 
comporte aucun virus et il ne pourra être tenu pour responsable de 
quelque dommage que ce soit résultant de la transmission d'un virus.
===


--
*_Frédéric  ORMANCEY_*
Atos Origin Systems Integration  

/rue Ampère - BP 475  
31315 Labège Cedex/

/Tel// /: 05 61 39 75 21
/Fax /: 05 61 39 16 65 
[EMAIL PROTECTED] 
www.si.fr.atosorigin.com

===
Ce message électronique est confidentiel. Il peut contenir des 
informations protégées par le secret professionnel, le secret de 
fabrication ou autres règles légales. Si vous recevez ce message par 
erreur, il vous est interdit de le reproduire ou de le distribuer en 
tout ou partie, ou de le divulguer de quelque manière que ce soit à 
quelque personne que ce soit. Nous vous prions de bien vouloir en 
informer Atos Origin, par téléphone ou par retour d'e-mail puis de 
détruire le message et toutes copies de votre système informatique.
Le contenu de ce message ne reflète pas nécessairement ni les opinions 
d'Atos Origin ni celles des membres de son groupe. Bien que l'émetteur 
de ce message ait fait tout son possible pour maintenir son système 
informatique sans virus, il ne peut garantir que cette transmission ne 
comporte aucun virus et il ne pourra être tenu pour responsable de 
quelque dommage que ce soit résultant de la transmission d'un virus.
===


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

Re: Latest snapshot with XP SP2 and unison and cvs

[Corinna Vinschen]

On Sep 22 17:48, Dave Korn wrote:
> > -Original Message-
> > From: cygwin-owner On Behalf Of Karl M
> > Sent: 22 September 2004 16:19
> 
> > Hi All...
> 
> > It appears to be a client problem. An XP SP2 server is fine, 
> > but the XP SP2 
> > client (with the latest cygwin1.dll or snapshots I tried) hangs.
> 
> > >>On Sep 18 12:23, Karl M wrote:
> > >> > Hi All...
> > >> >
> > >> > I just updated an xp machine to sp2 and unison-2.9.1 (the win32 
> > >>version)
> > >> > using ssh (cygwin) started hanging. 
> 
>   Wait a minute.  You're saying it was all working fine, and then you put
> sp2 on and it stopped working?  IOW, nothing about cygwin changed?  Then the
> problem is probably because of the SP2 firewall, isn't it?

I thought the same, but it's not the firewall.  I tested this a few
minutes ago.  The change in behaviour is apparently related to the
changes in the pipe code made on 2004-09-02.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:[EMAIL PROTECTED]
Red Hat, Inc.

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

RE: Latest snapshot with XP SP2 and unison and cvs

[Dave Korn]

> -Original Message-
> From: cygwin-owner On Behalf Of Karl M
> Sent: 22 September 2004 16:19

> Hi All...

> It appears to be a client problem. An XP SP2 server is fine, 
> but the XP SP2 
> client (with the latest cygwin1.dll or snapshots I tried) hangs.

> >>On Sep 18 12:23, Karl M wrote:
> >> > Hi All...
> >> >
> >> > I just updated an xp machine to sp2 and unison-2.9.1 (the win32 
> >>version)
> >> > using ssh (cygwin) started hanging. 

  Wait a minute.  You're saying it was all working fine, and then you put
sp2 on and it stopped working?  IOW, nothing about cygwin changed?  Then the
problem is probably because of the SP2 firewall, isn't it?

  NB. If you wish to test this theory by switching the firewall off, you'd
probably better disconnect both machines from the network and wire them
directly together with a crossover cable..

cheers, 
  DaveK
-- 
Can't think of a witty .sigline today


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

Re: Bash returns incorrect process status

[Ronald Landheer-Cieslak]

Dolton Tony AB wrote:
I've noticed that bash doesn't get issued too often.
It doesn't for three reasons:
1. the maintainer for Cygwin (that would be me) is very busy
2. The current version of Bash is very, very stable
3. I'm hesitant (reluctant, even) to let a new release of Bash go out
   the door without proper testing, even if it does fix a bug reported
   on this list every-so-often - i.e. I don't jump on every patch to
   apply it tout-de-suite and send out a new release: there's too much
   that depends on Bash.. That, and reason #1..
As soon as I have the time, I will test and release a new Bash-2 with 
the two patches I have for it now: one that fixes a problem that occured 
in a snapshot a while back and shouldn't even bother the every-day Bash 
user at the moment but is worth a fix anyway (and for which a patch was 
kindly provided by Corinna) and one that came out of this very thread.

As for Bash-3: until I have the time to test it properly (==thouroughly) 
there won't be a release of it yet and when it comes, it will be a test 
version.

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

Re: New packge: lighttpd-1.3.0

[Reini Urban]

[EMAIL PROTECTED] schrieb:
I think what is required is a separate php package - making it work
with a web server (apache or lighttpd) is just a configuration
issue. 
Yes, but you cannot build PHP with fastcgi and Apache support at the
same time, so there should be several packages, runtime for every
webserver available (currently only lighttpd) plus one common
package (devel stuff).
no, you can and you ususally do.
you build it for every web server SAPI (apache1, apache2, fastcgi) and 
for the cli also.
php/configure --help

Can you expand a little on that? Do you mean something like:
php-common
php-cgi
php-apache
php-devel
Etc. ?
no:
apache-php (which as main php package has pear, cgi and the cli also),
lighttpd-php (just the php dll, if someone cares to maintain that)
Can cgi php use the same modules as mod_php? 
it is normally built in one step.
which extensions it uses is defined in php.ini
> Should we build statically?
no. that's about 17MB for each php.exe or dll :)
I imagine most of the problems arise when trying to decide on a
standard set of modules to be included with the "standard" php
package. Or is it possible to package php modules separately, e.g.
the postgres, ssl, imap, etc.?
Just include everything possible seems to be ok;)  There should be all
important modules which are really needed, e.g. database modules for
mysql and pgsql, sqlite and others, all graphic stuff possible (GD,
JPEG, PNG, ...), cryptographic stuff like openssl, mhash, ...,
compression, pear, XML/XSLT, pdflib, PSPELL?  Well you see, one cannot
say which extension is important and which isn't, just try to use
every available extension seems to be ok IMO.
you want pdflib and pspell also?
see my list. pdflib is non-free I think.
I'd need xdebug also, maybe apd.
best would be to add all the modules which are supported and in the 
nightly snaps.

That would be OK if all the extensions are built as modules, but building
everything into one php executable would make it pretty big, wouldn't it?
the extensions are just shared interfaces to the existing dll.
only mysql and some esoteric ones, which are not in the usual setup are 
static.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

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

Re: cygwin, libtool, dlpreopen, and .rdata

[Reini Urban]

Gerrit P. Haase schrieb:
But it can't, because .rdata is non-writable.  However, this is a 
*runtime* error; the *link* succeeds.  But when you run the app, you get
a popup window declaring:

"The application failed to initialize properly (0xc005). Click on OK
to terminate the application."

Ahh, this is the reason why I cannot get GConf running in
first place.  Thank you Charles for this information!!!
This was also the reason for the clamav beta failure (0.80rc2)
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Latest snapshot with XP SP2 and unison and cvs

[Karl M]

Hi All...
I have a testcase. It uses unison-2.9.1.exe available from 
http://www.cis.upenn.edu/~bcpierce/home.html
(from here go to unison, downloads, current stable version, and select 
unison.win32-gtkui.exe)

On a machine with XP, SP2, this test hangs and with XP or 2000 it executes 
to completion.

The recipie is as follows (assuming you have openssh client and server set 
up):

download unison
rename the executable to unison.exe and place it somewhere on your PATH.
in a cmd (not bash) shell type
unison C:/ ssh://localhost/C:/ -testserver -rshargs "-v -v -v"
thats it. Unison will use the ssh client to run a copy of itself and talk to 
it for the test. This does not work from a bash shell...never has. But...you 
can run it from strace cmd inside a bash shell to get strace output. Up 
until XP SP2 and the latest cygwin, I have been using it this way for years 
without a hitch.

On XP SP2 the results are 100% repeatable. It hangs in the same place every 
time.

I have run sshd in debug mode and found nothing unusual there.
It appears to be a client problem. An XP SP2 server is fine, but the XP SP2 
client (with the latest cygwin1.dll or snapshots I tried) hangs.

Thanks,
...Karl

From: "Karl M" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Latest snapshot with XP SP2 and unison and cvs
Date: Mon, 20 Sep 2004 15:31:23 -0700
Hi All...
What can I do that would be usefull? I'm not sure how to tell where things 
are hanging, because unison-2.9.1 is a win32 program that invokes a cygwin 
ssh client.

I did confirm that it is a ssh client side issue. That is, an XP SP2 
machine is fine as the server, but not as the client.

If I turn on the -v -v -v in ssh, the last thing I get is from a 
channel_input_window_adjust call.


From: Corinna Vinschen <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Latest snapshot with XP SP2 and unison and cvs
Date: Mon, 20 Sep 2004 11:20:14 +0200
On Sep 18 12:23, Karl M wrote:
> Hi All...
>
> I just updated an xp machine to sp2 and unison-2.9.1 (the win32 
version)
> using ssh (cygwin) started hanging. I have done a clean install of 
cygwin
> and am running with the 16sep snapshot. cvs (cygwin) works fine with 
ssh.
> unison hangs with ssh.
>
> Because win32 unison will not run under bash, I opened a cygwin bash
> window, did an strace of cmd
> and then ran unison. The strace is attached.
>
> Any thoughts?

No.  I don't see any change in Cygwin between 1.5.10 and 1.5.11 which
could result in a new behaviour on sockets.  The strace is useless.
Corinna
--
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:[EMAIL PROTECTED]
Red Hat, Inc.
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/
_
Is your PC infected? Get a FREE online computer virus scan from McAfee® 
Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/
_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

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

Re: cygwin, libtool, dlpreopen, and .rdata

[Brian Ford]

On Wed, 22 Sep 2004, Charles Wilson wrote:

> [cygwin list: I'm CC'ing this so that it goes into the archives, but
> it's pretty technical about the innards of libtool...]

This doesn't seem libtool related at all to me (other than it's a gcc bug
that affects libtool).

> With newer gcc's (cygwin version numbers 3.3.3-3, 3.4.1-1, but not
> 3.3.1-3), const variables are placed in an .rdata section.  This causes
> problems when those variables contain references to OTHER vars that are
> imported from a dll -- because the runtime relocation machinery can't
> fixup the address, since the variable holding the address is const --
> and is in .rdata!

Yes, I see.  I hope Danny Smith might weigh in here?

http://sources.redhat.com/ml/binutils/2004-02/msg3.html

> Concrete example: the demo test program from libtool itself.  When
> building helldl, libtool creates the following virtual lookup table:
>
> helldl.exeS.c (important bits only):
> *
> /* External symbol declarations for the compiler. */
> extern int foo;
> extern int hello;
> extern int nothing;
>
> /* The mapping between symbol names and symbols. */
> const struct {
>const char *name;
>lt_ptr address;
> }
> lt_preloaded_symbols[] =
> {
>{"libhello.a", (lt_ptr) 0},
>{"hello", (lt_ptr) &hello},
>{"foo", (lt_ptr) &foo},
>{"nothing", (lt_ptr) ¬hing},
>{0, (lt_ptr) 0}
> };
> *
>
> Because lt_preloaded_symbols[] is an array of const structs, it is
> placed in .rdata.  However, the "nothing" symbol is a DATA export from
> cyghello-2.dll -- so the runtime psuedo-reloc machinery needs to fixup
> the address stored in "lt_preloaded_symbols[3].address" to point to the
> actual, relocated memory location of the "nothing" variable.
>
> But it can't, because .rdata is non-writable.  However, this is a
> *runtime* error; the *link* succeeds.  But when you run the app, you get
> a popup window declaring:
>
> "The application failed to initialize properly (0xc005). Click on OK
> to terminate the application."
>
> Note that
>   (1) the "nothing" relocation works fine for "normal" links; hell.exe
> works ok, and imports "nothing" correctly.
>
>   (2) the lt_preloaded_symbol[] object works fine, as long as it doesn't
> contain references to DATA items imported from DLL's: staticly linked
> helldl.exe works ok, and dynamically linked helldl.exe works IF
> "nothing" is expunged from the application code (manually removed from
> helldl.exeS.c, and from dlmain.c)
>
>   (3) even with newer compilers, if lt_preloaded_symbol[] is in .data
> (by changing its definition from "const struct" to "struct") then
> everything works fine.  Note that you only need to do this in
> helldl.exeS.c; the application (dlmain.c, in this case) can still
> declare 'extern const struct ').
>
> *
> I see two solutions: a short term libtool-focused workaround, and a
> longer term general solution.
>
> The short term workaround is to simply change lt_preloaded_symbol[]'s
> constness in the *.exeS.c file, so that it goes in the .data section.
> Mabye this could be done for cygwin/mingw only (but application code can
> remain unchanged, declaring 'extern const struct ...').  But that won't
> fix any OTHER problems out there which put the address of DLL DATA
> imports into const variables.
>
> The long term solution is...er...hard.  Somehow, ld/(gcc?) should be
> modified to detect that a dllreloc is being put into an .rdata, and move
> the entire enclosing variable into .data.  This is difficult:
> lt_preloaded_symbol[3].address can be flagged easily, but how can the
> linker figure out that the whole lt_preloaded_symbol variable should be
> moved from .rdata to .data?  And didn't the compiler put the symbol into
> .rdata in the first place -- so maybe gcc is the one who should detect
> this?  But gcc doesn't know how the link will be performed: it doesn't
> know that "nothing" is a DATA import from a DLL, but "foo" is a function
> import from a DLL!  (Worse, you might link to a STATIC library and not a
> DLL at all, so lt_preloaded_symbol could STAY in .rdata in that case.)
>
> This might be one of those "doctor, it hurts when I do this/OK, don't do
> that" situations.
>
> Note, I found this problem in libtool-1.5.x, but it exists in HEAD, too.
>   The following patch is against HEAD...
>
> --
> Chuck

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained pilot...

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

RE: Request for change to /etc/profile

[Larry Hall]

At 05:28 AM 9/22/2004, you wrote:
>Hi,
>
>I've got a sort-of-related issue with the location of the home directory.
>
>On my work laptop, my home directory is on a network share (mapped as a H:
>drive) and "My Documents" is on their too. This is made available offline using
>the ... "Make Available Offline" feature of WinXP.
>
>When I'm connected to the network all is well and cygwin correctly finds my home
>directory, However, if I'm not connected to the network, cygwin just starts in
>root (/). My home directory is there on the machine, but cygwin doesn't find it.
>
>Is there any chance that this could be fixed?


Depends on what's going on in your environment I guess.  Take a look at
'/etc/profile' and you'll see how "HOME" is set.  From that, one can 
surmise that you don't set "HOME" in your Windows environment (good! :-) ),
that your user doesn't exist in your '/etc/passwd' file, and that 
"HOMEDRIVE" and "HOMEPATH" don't exist.  So you're left with "/".  You'll
need to investigate these areas and why they differ between "on-line" and 
"off-line" use.


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


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

Re: setup.log in /var/log/

[Larry Hall]

At 04:27 AM 9/22/2004, you wrote:

>Hi,
>I have noted that in /var/log/ there are setup.log and setup.log.full.
>
>setup.log contains the description of all my CYGWIN packages installation
>from the first installation (Jun 2003): it is a file of 250 MB! Can I
>remove these files without corrupt the CYGWIN installation?


Of course.  Log files are just that.  If you have no need of the logged
information (i.e. your installation went fine, etc.), then removing the 
files is an option.



--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


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

RE: New packge: lighttpd-1.3.0

[Robin Bowes]

> -Original Message-
> From: Gerrit P. Haase [mailto:[EMAIL PROTECTED] 
> Sent: 22 September 2004 14:19
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; 'Reini Urban'
> Subject: Re: New packge: lighttpd-1.3.0
> 
> Hello Robin,
> 
> I have a cygwin package without the cygwin specific README but with
> generic build script and patch to get sharted libraries for
> fastcgi-2.4.0, do you want to maintain a relase for cygwin?

Erm, I don't know.

What's involved?

R.
--
http://robinbowes.com  


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

Re: New packge: lighttpd-1.3.0

[Gerrit P. Haase]

Hello Robin,

I have a cygwin package without the cygwin specific README but with
generic build script and patch to get sharted libraries for
fastcgi-2.4.0, do you want to maintain a relase for cygwin?

Gerrit
-- 
=^..^=



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

Re: Referential Intigrity

[Christopher Faylor]

On Wed, Sep 22, 2004 at 10:52:58AM -, Mario Reis wrote:
>I beleavew you have a problema with Referential Intigrity Return Codes.
>No matter the cause it allways returns 1001:Duplicate keys; keys that
>still exit in use OnDelete etc..  The messages seam OK but not the
>codes.

Referential Intigrity is not a Cygwin package.  Please refer your questions
to the proper forum, i.e., not the cygwin list.

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

Re: Cygwin on Win98: initdb failed

[Christian Rank]

On Sep 21 16:42, Corinna Vinschen wrote:

> On Sep 21 15:02, Christian Rank wrote:
>>> The corresponding debugging info of cygserver reads:
>>> 
>>> cygserver: /netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_shm.cc,
>>> line 385: shmaddr: 82FFD000, shmflg: 0
>>> cygserver: /netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_shm.cc,
>>> line 393: Odd shmaddr: EINVAL
> 
> Urgh!  Ok, well... looking into the implementation of shmat, there's
> only one explanation for this behaviour.  Apparently MapViewOfFileEx
> returned memory which isn't aligned to the memory granulation.
> 
> [time passes, testing on a 9x system]
> 
> That's it.  Incredible.  I've checked in a patch to cygserver which
> takes this into account.  Please give cygserver from the next Cygwin
> snapshot (http://cygwin.com/snapshots.html) a try.

OK, I will test it with the next snapshot (not online yet).
Thank you very much for fixing this so quickly.

Best regards,
Christian

-- 
Dr. Christian Rank
Rechenzentrum Universität Passau
Innstr. 33
D-94032 Passau
GERMANY
Tel.: 0851/509-1838
Fax:  0851/509-1802
PGP public key see http://www.rz.uni-passau.de/mitarbeiter/rank



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

RE: Lot of undefined symbols at link time, even with -l option on good libraries

[Dave Korn]

> -Original Message-
> From: cygwin-owner On Behalf Of Frédéric ORMANCEY
> Sent: 22 September 2004 13:31

> problem seems coming from trailing @nn in library symbols.
> cygwin linker don't know how to translate a reference like 
> _FormatMessageA to [EMAIL PROTECTED]
> the calling convention ( C, Stdcall, C++, ... ) has effect only on 
> underscore preceeding symbol name, not on @nn notation.
> 
> It seems there is no solutions to this problem, I will 
> abandon cygwin to 
> build my Ada application under windows :-(

  You didn't read that letter that you were replying to very well:

> >default for Windows).  If you cannot get Ada to ask for the 
> proper symbol, 
> >you could try using the '--enable-stdcall-fixup' option (for 
> 'ld') to 
> >attempt to massage away the problem.  

  It doesn't seem from your reply that you have actually tried this.  Note
that to pass the option through to the linker from the compiler you would
need to add "-Wl," before it, but if you have a separate link stage in your
makefile that invokes the linker directly that would not be necessary.

cheers, 
  DaveK
-- 
Can't think of a witty .sigline today


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

RE: ./configure in any package gives "error: cannot find input file: \WINDOWS\oracle.ini" error

[Dave Korn]

> -Original Message-
> From: cygwin-owner On Behalf Of Igor Pechtchanski
> Sent: 22 September 2004 07:17

> On Wed, 22 Sep 2004, Mark Aufflick wrote:
> 
> > ./configure in any package gives "error: cannot find input 
> file: \WINDOWS\oracle.ini" error

> At a guess, something you installed earlier created an environment
> variable with a name that either configure or something called by
> configure uses.  You could try simply "env | grep oracle.ini".

  Or there is some executable in the $PATH that has the same name as one of
the tests or executables that configure depends on.  Try setting a really
minimal path with 

export
PATH=/bin:${SYSTEMROOT}/system32:${SYSTEMROOT}:${SYSTEMROOT}/system32/wbem

and then run configure and see if it helps.

cheers, 
  DaveK
-- 
Can't think of a witty .sigline today
 



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

RE: signal delivery problem (with pthreads)

[Dave Korn]

> -Original Message-
> From: cygwin-owner On Behalf Of Valery A. Frolov
> Sent: 21 September 2004 22:52

> I've checked it and got the same bad result (crash) on 2000, 
> XP and Win98.
> 
> I've installed cygwin bundle for compilation of sig_bug.c on XP, compiled
> sig_bug.c to sig_bug.exe and ran it. Nothing was changed - crash.
> 
> So could someone who got the _successful_ run of sig_bug.exe with recently
> (>1.5.7-1) releases or snapshots of cygwin1.dll send it 
> (sig_bug.exe) to my personal e-mail? 

  Well, here you go; source as well, just in case you have more than one
version of your testcase lying around, so you know exactly what I was
compiling.

[Actually, on second thoughts, I'm going to send this post to the list, so
I'll send you the files separately.  There have been further developments
while I was writing this post that I thought the list should be informed
about.]

  A funny thing happened to me on the way to email this to you, however:  I
thought I'd try running it again, and this time it crashed for the first
time!  However it still works fine almost all the time when run directly
from the command line, but I've noticed that when I run it in a loop with 

for i in 1 2 3 4 5 6 7 8 9 10 ; do ./sb.exe ; done

it crashes more often than not!  This is interesting, and suggests an
interaction with process spawn/forking.  The contents of the .stackdump file
are fairly interesting too:

Exception: STATUS_ACCESS_VIOLATION at eip=0085F030
eax=001F ebx= ecx=77E75A65 edx=001F esi=41516044
edi=0004
ebp=0086 esp=0085F004 program=C:\artimi.src\davek\test\pthread\sb.exe,
pid 2352, thread unknown (0x208)
cs=001B ds=0023 es=0023 fs=0038 gs= ss=0023
Stack trace:
Frame Function  Args
0086  0085F030  (0001, BC5D1B48, , 0001000C)
End of stack trace

  This is very strange indeed.  The eip is in between ebp and esp; in other
words, we're executing on the stack!  And look at the value in ecx:  that
happens to be the ret instruction at the end of KERNEL32!IsBadWritePtr.
_Very_ interesting.  Hmm, now I've finally got it to crash under insight!
Although the stack (or perhaps only the stack pointer) has been somewhat
trashed, I can see enough of it...

(gdb) info registers
eax0x1f 31
ecx0x77e75a65   2011650661
edx0x1f 31
ebx0x   -1
esp0xd5f004 0xd5f004
ebp0xd6 0xd6
esi0x415162eb   1095852779
edi0x4  4
eip0xd5f030 0xd5f030
eflags 0x10216  66070
cs 0x1b 27
ss 0x23 35
ds 0x23 35
es 0x23 35
fs 0x38 56
gs 0x0  0

(gdb) info frame
Stack level 0, frame at 0xd5f008:
 eip = 0xd5f030; saved eip 0x0
 Arglist at 0xd5f000, args: 
 Locals at 0xd5f000, Previous frame's sp is 0xd5f008
 Saved registers:
  eip at 0xd5f004

(gdb) frame
#0  0x00d5f030 in ?? ()

(gdb) x/64xw $esp-0x80
0xd5ef84:   0x00d5f208  0x61117310  0x00401090  0x00d5efcc
0xd5ef94:   0x000907d4  0x00160003  0x00d5efbc  0x610e2b47
0xd5efa4:   0x61117310  0x00401090  0x00d5efc8  0x00d6
0xd5efb4:   0x  0x001f  0x00d6  0x00401163
0xd5efc4:   0x00401090  0x0001  0x000f  0xfffefeff
0xd5efd4:   0x2000  0x00d5f00c  0x00d5f00c  0x6108e0bc
0xd5efe4:   0x001e  0x  0x0004  0x
0xd5eff4:   0x415162eb  0x0004  0x00d6  0x00d5f030

0xd5f004:   0x  0x0246  0x00d5f048  0x
0xd5f014:   0x00d5ef84  0x00d5ef84  0x00d5ef84  0x00d5f030
0xd5f024:   0x0002  0x  0x  0x0003
0xd5f034:   0x  0x00d5f048  0x0a053c30  0x0a053c88
0xd5f044:   0x0a053c30  0x00d5f058  0x004011ae  0x0003
0xd5f054:   0x0a053c30  0x00d5f098  0x610a97da  0x
0xd5f064:   0x  0x  0x  0x0001
0xd5f074:   0x  0x  0x  0x

  Right, what interesting values do we find there?  0x61117310 is in the
cygwin dll's data area, somewhere above reent_data, and what do we find
there?

(gdb) x/xw 0x61117310
0x61117310 :0x0a053cb8

(gdb) x/s 0x0a053cb8
0xa053cb8:   "select was interrupted 1 times\n"

  Ok!  It's printf's output buffer!  That ties in with that 0x610e2b47 which
is the return address from the call within printf to vfprintf.

  Next, that 0x00401090 gets there because of this code in my_sleep:

0x00401153 :  mov%esi,0x4(%esp,1)
0x00401157 :  movl   $0x401090,(%esp,1)
0x0040115e :  call   0x401710 
0x00401163 :  jmp0x40114b 

(gdb) x/s 0x401090
0x401090 :   "select was interrupted %d times\n"

which also explains the 0x00401163.

  So, we can conclude that the 

Re: Lot of undefined symbols at link time, even with -l option on good libraries

[Frédéric ORMANCEY]

problem seems coming from trailing @nn in library symbols.
cygwin linker don't know how to translate a reference like 
_FormatMessageA to [EMAIL PROTECTED]
the calling convention ( C, Stdcall, C++, ... ) has effect only on 
underscore preceeding symbol name, not on @nn notation.

It seems there is no solutions to this problem, I will abandon cygwin to 
build my Ada application under windows :-(

Larry Hall a écrit :
At 12:15 PM 9/21/2004, you wrote:
 

I think you're right, it seems to be a problem with trailing underscore in function 
naming.
For example :
in /usr/lib/w32api/libkernel32.a we found :
  T [EMAIL PROTECTED]
  U __head_libkernel32_a
  I [EMAIL PROTECTED]
which is required by win32-winbase.o, result of the build of 
/usr/lib/gcc/win32ada/win32-winbase.adb
  U _FormatMessageA
  U _FormatMessageW
  U _GlobalReAlloc
  U _LocalReAlloc
The source code for this part is the following :
pragma Import (Stdcall, Doit, "FormatMessageA");
I try change it with pragma Import (C, Doit, "_FormatMessageA"); or things like that 
with no success.
May be it's the trailing @28 after symbol name which cause error, but I cannot control 
it ( it's DLL calling convention parameter size ). Compiler/linker should usually add 
or remove trailing @nn if necessary.
To answer your general questions, I'am building a large Ada application ( 200 source 
files ), using W32 API, with Win2000 GNAT Compiler.
   


Sorry, I know nothing about Ada and how it works.  If the "pragma" statement
is supposed to take the place of the traditional function prototype in C/C++,
then I agree that it looks "OK" (again, based on my knowledge of Ada).  But
the result is that it's looking for symbols that use the 'C' calling 
convention rather than the 'stdcall' calling convention.  The libraries you
are linking to want the 'stdcall' calling convention (since it is the 
default for Windows).  If you cannot get Ada to ask for the proper symbol, 
you could try using the '--enable-stdcall-fixup' option (for 'ld') to 
attempt to massage away the problem.  


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 

 

--
*_Frédéric  ORMANCEY_*
Atos Origin Systems Integration  

/rue Ampère - BP 475  
31315 Labège Cedex/

/Tel// /: 05 61 39 75 21
/Fax /: 05 61 39 16 65 
[EMAIL PROTECTED] 
www.si.fr.atosorigin.com

===
Ce message électronique est confidentiel. Il peut contenir des 
informations protégées par le secret professionnel, le secret de 
fabrication ou autres règles légales. Si vous recevez ce message par 
erreur, il vous est interdit de le reproduire ou de le distribuer en 
tout ou partie, ou de le divulguer de quelque manière que ce soit à 
quelque personne que ce soit. Nous vous prions de bien vouloir en 
informer Atos Origin, par téléphone ou par retour d'e-mail puis de 
détruire le message et toutes copies de votre système informatique.
Le contenu de ce message ne reflète pas nécessairement ni les opinions 
d'Atos Origin ni celles des membres de son groupe. Bien que l'émetteur 
de ce message ait fait tout son possible pour maintenir son système 
informatique sans virus, il ne peut garantir que cette transmission ne 
comporte aucun virus et il ne pourra être tenu pour responsable de 
quelque dommage que ce soit résultant de la transmission d'un virus.
===


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

OT?! (Re: Using cygwin's GnuPG with enigmail)

[Mader, Alexander]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I've been using Cygwin GnuPG with enigmail since 2002.
Ismael schrieb:
| Can this be safely done? Or would I have any drawback?
If you mean "w/o crash" I would say yes. There was an drawback some
enigmail versions ago which was taken care of by enigmail: There was a
return code problem. This problem is documented here
mozdev.org/bugs/show_bug.cgi?id=2366
Best regards,
Alexander.
- --
Alexander Mader <[EMAIL PROTECTED]>   Fon: +49-30-93033-636
NILES Werkzeugmaschinen GmbHFax: +49-30-93033-603
www.niles.de
GPG public key: http://mader.seppi.de/pubkey-dienst.asc
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBUWkIUABVlkcx7ZMRAmSEAKC6MuCNcGPdwUtIA8a2Wo1M5xiI5QCfWXRs
TaK/R+eE8IdVVOQKisEKP1g=
=mE0+
-END PGP SIGNATURE-
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: New packge: lighttpd-1.3.0

[Gerrit P. Haase]

Hallo Robin,

>> Yes, but you cannot build PHP with fastcgi and Apache support at the
>> same time, so there should be several packages, runtime for every
>> webserver available (currently only lighttpd) plus one common
>> package (devel stuff).

> Can you expand a little on that? Do you mean something like:

> php-common
> php-cgi
> php-apache
> php-devel
> Etc. ?

mod_php for Apache and fastcgi PHP builds are to independant builds
from the same source with different configure options, so we need at
least two build scripts in the source package or one which handles
this conditionally, depnding on user request.

> Can cgi php use the same modules as mod_php? Should we build statically?

PHP can use all extensions it is written for, you probably want to
connect PostgreSQL or MySQL databases, if you use one or another
webserver.  It is just not possible to build CGI version and embedded
version at the same time.

>> > I imagine most of the problems arise when trying to decide on a
>> > standard set of modules to be included with the "standard" php
>> > package. Or is it possible to package php modules separately, e.g.
>> > the postgres, ssl, imap, etc.?
>> 
>> Just include everything possible seems to be ok;)  There should be all
>> important modules which are really needed, e.g. database modules for
>> mysql and pgsql, sqlite and others, all graphic stuff possible (GD,
>> JPEG, PNG, ...), cryptographic stuff like openssl, mhash, ...,
>> compression, pear, XML/XSLT, pdflib, PSPELL?  Well you see, one cannot
>> say which extension is important and which isn't, just try to use
>> every available extension seems to be ok IMO.

> That would be OK if all the extensions are built as modules, but building
> everything into one php executable would make it pretty big, wouldn't it?

Yes, extension should be shared modules if possible so one can decide
if they are loaded or not to keep the footprint smaller.


Gerrit
-- 
=^..^=



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

E-mail direct marketing... (May the word that has now been spoken, take deep root in )

[Clarifies Q. Alvarado]

Hello,

Advancement of your business by direct e-mail marketing. 
We offer e-mail mass mailing to any country.

We guarantee professional and quick performance of the work.

Contacts:

icq: 174677598
[EMAIL PROTECTED]



>From which words I shall consider three things:


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

RE: New packge: lighttpd-1.3.0

[robin-lists]

p> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Gerrit P. Haase
> Sent: 22 September 2004 10:31
> To: [EMAIL PROTECTED]
> Cc: 'Reini Urban'; [EMAIL PROTECTED]
> Subject: Re: New packge: lighttpd-1.3.0
> 
> Hallo R.,
> 
> > I think what is required is a separate php package - making it work
> > with a web server (apache or lighttpd) is just a configuration
> > issue. 
> 
> Yes, but you cannot build PHP with fastcgi and Apache support at the
> same time, so there should be several packages, runtime for every
> webserver available (currently only lighttpd) plus one common
> package (devel stuff).

Can you expand a little on that? Do you mean something like:

php-common
php-cgi
php-apache
php-devel
Etc. ?

Can cgi php use the same modules as mod_php? Should we build statically?

> > I imagine most of the problems arise when trying to decide on a
> > standard set of modules to be included with the "standard" php
> > package. Or is it possible to package php modules separately, e.g.
> > the postgres, ssl, imap, etc.?
> 
> Just include everything possible seems to be ok;)  There should be all
> important modules which are really needed, e.g. database modules for
> mysql and pgsql, sqlite and others, all graphic stuff possible (GD,
> JPEG, PNG, ...), cryptographic stuff like openssl, mhash, ...,
> compression, pear, XML/XSLT, pdflib, PSPELL?  Well you see, one cannot
> say which extension is important and which isn't, just try to use
> every available extension seems to be ok IMO.

That would be OK if all the extensions are built as modules, but building
everything into one php executable would make it pretty big, wouldn't it?

R.


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

Referential Intigrity

[Mario Reis]

I beleavew you have a problema with Referential Intigrity Return Codes. No
matter the cause it allways returns 1001:Duplicate keys; keys that still
exit in use OnDelete etc..
The messages seam OK but not the codes.


Reis



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

Re: cygwin, libtool, dlpreopen, and .rdata

[Gerrit P. Haase]

Hello Charles,

[...]

> But it can't, because .rdata is non-writable.  However, this is a 
> *runtime* error; the *link* succeeds.  But when you run the app, you get
> a popup window declaring:

> "The application failed to initialize properly (0xc005). Click on OK
> to terminate the application."

Ahh, this is the reason why I cannot get GConf running in
first place.  Thank you Charles for this information!!!

[...]

> Note, I found this problem in libtool-1.5.x, but it exists in HEAD, too.
>   The following patch is against HEAD...

I'll try if it works ok with this solution.



Gerrit
-- 
=^..^=



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

Re: New packge: lighttpd-1.3.0

[Gerrit P. Haase]

Hallo R.,

> I think what is required is a separate php package - making it work
> with a web server (apache or lighttpd) is just a configuration
> issue. 

Yes, but you cannot build PHP with fastcgi and Apache support at the
same time, so there should be several packages, runtime for every
webserver available (currently only lighttpd) plus one common
package (devel stuff).

> I imagine most of the problems arise when trying to decide on a
> standard set of modules to be included with the "standard" php
> package. Or is it possible to package php modules separately, e.g.
> the postgres, ssl, imap, etc.?

Just include everything possible seems to be ok;)  There should be all
important modules which are really needed, e.g. database modules for
mysql and pgsql, sqlite and others, all graphic stuff possible (GD,
JPEG, PNG, ...), cryptographic stuff like openssl, mhash, ...,
compression, pear, XML/XSLT, pdflib, PSPELL?  Well you see, one cannot
say which extension is important and which isn't, just try to use
every available extension seems to be ok IMO.


Gerrit
-- 
=^..^=



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

RE: New packge: lighttpd-1.3.0

[Robin Bowes]

Hi Gerrit,

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Gerrit P. Haase
> Sent: 22 September 2004 09:50
> To: [EMAIL PROTECTED]
> Subject: Re: New packge: lighttpd-1.3.0
> 
> Hello R.,
> 
> Am Mittwoch, 22. September 2004 um 02:33 schriebst du:

[snip]

> > I also downloaded and built the fastcgi dev. Kit
> > (http://www.fastcgi.com/dist/fcgi.tar.gz)
> 
> That is interesting, is this needed?  For lighttpd or for PHP?

The fastcgi dev. kit is needed to build php with fastcgi support. It took me a
few goes to work this out (I didn't just sit down and build this first time with
no errors!)

> > # ./configure --enable-fastcgi --enable-force-cgi-redirect 
> --with-layout=GNU
> > --with-pgsql
> 
> See above.  What is the difference with layout GNU and layout PHP?

It just puts files in different places; I don't know the exact details, and I
suspect it's not all that important for this exercise. When building a package
for cygwin I presume the developers have standards that should be applied to the
locations of files in every package?
 
> > # make
> > # make install
> 
> > # php -v
> > PHP 4.3.8 (cgi-fcgi) (built: Sep 22 2004 00:46:39)
> > Copyright (c) 1997-2004 The PHP Group
> > Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
> 
> > Well, that seems to work.
> 
> Wow, I'm impressed.

Yeah, I was rather surprised!

> 
> > I then downloaded and installed spawn-fcgi from the 
> lighttpd project download
> > page and built and installed it.
> > 
> (http://jan.kneschke.de/projects/lighttpd/download/spawn-fcgi-
> 1.2.0.tar.gz)
> 
> Therefore the first fastcgi package is needed?

I don't thing it is needed for this; just for php. But, I had already installed
it (fastcgi dev package) when I built spawn-fcgi so I don't know for sure.

> > I ran the PHP fastcgi interface like this:
> 
> > # spawn-fcgi.exe -f /usr/local/bin/php -p 1026 -C 5
> > spawn-fcgi.c.150: child spawned successfully: PID: 5824
> 
> Yes, great.
> 
> 
> > I also grabbed the spawn-php.sh example script
> > 
> (http://jan.kneschke.de/projects/lighttpd/download/spawn-php.s
> h) but this didn't
> > seem to work.
> 
> Tried to use #!/bin/bash instead of /bin/sh?

The bang path is set to #!/bin/bash. I don't think that's the problem. I've
reported this on the lighttpd list.

So, what now? I saw that Reini is going to have another look at the PHP package
in the light of some progress in another area. Meanwhile, I've got php working
(subject to further testing!) so I'll leave it at that I think. I'll try and
write this up and post a link when I'm done.

Cheers,

R.


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

Re: New packge: lighttpd-1.3.0

[Gerrit P. Haase]

Hello R.,

Am Mittwoch, 22. September 2004 um 02:33 schriebst du:

> Hi Gerrit,

>> But why wait for me?  Try it yourself?  No problem that
>> cannot be discussed at this list (as long as it is about problems with
>> building some open sourced code for cygwin).

> Well, I'll give it a go...

> I just downloaded the latest cygwin + gnu toolset. The lighttpd package is also
> installed.

> I also downloaded and built the fastcgi dev. Kit
> (http://www.fastcgi.com/dist/fcgi.tar.gz)

That is interesting, is this needed?  For lighttpd or for PHP?
I remember that I have  read at lightthpd docs that you just need to
configure with these options:

$ ./configure \
  --enable-fastcgi \
  --enable-discard-path \
  --enable-force-cgi-redirect \
  ...

http://jan.kneschke.de/projects/lighttpd/documentation/fastcgi.html#preparing-php-as-a-fastcgi-program


> I then grabbed the latest 4.3.8 php source tarball, un-tarred it and built it as
> follows:

> # ./configure --enable-fastcgi --enable-force-cgi-redirect --with-layout=GNU
> --with-pgsql

See above.  What is the difference with layout GNU and layout PHP?


> # make
> # make install

> # php -v
> PHP 4.3.8 (cgi-fcgi) (built: Sep 22 2004 00:46:39)
> Copyright (c) 1997-2004 The PHP Group
> Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies

> Well, that seems to work.

Wow, I'm impressed.


> I then downloaded and installed spawn-fcgi from the lighttpd project download
> page and built and installed it.
> (http://jan.kneschke.de/projects/lighttpd/download/spawn-fcgi-1.2.0.tar.gz)

Therefore the first fastcgi package is needed?


> I ran the PHP fastcgi interface like this:

> # spawn-fcgi.exe -f /usr/local/bin/php -p 1026 -C 5
> spawn-fcgi.c.150: child spawned successfully: PID: 5824

Yes, great.


> I also grabbed the spawn-php.sh example script
> (http://jan.kneschke.de/projects/lighttpd/download/spawn-php.sh) but this didn't
> seem to work.

Tried to use #!/bin/bash instead of /bin/sh?


> I then configured lighttpd to use the fastcgi for php and created sample file
> info.php in the home directory of the web site containing:

>phpinfo();
?>>

> When I opened by web browser to localhost I saw the php configuration page. It
> works!

Hurra!


> Not sure where to go with this now - I'll try setting up a php application that
> uses a database or something.

> Any suggestions?



Gerrit
-- 
=^..^=



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

RE: Beginner question: Cygwin bash vs. cygwin/bin directory in DO S

[Hughes, Bill]

Andrew DeFaria wrote:
> Nathan Green wrote:
> 
>> I am a newbie using Cygwin. I noticed that Linux commands can be
>> executed by running commands in the Windows Command Prompt in the
>> cygwin/bin directory. What is the purpose of the bash shell provided
>> by clicking on the Cygwin icon?
> 
> Do you Google? http://www.gnu.org/software/bash/bash.html would be a
> start. 

You could also try
http://www.tldp.org/LDP/Bash-Beginners-Guide/html/index.html

and later on http://www.tldp.org/LDP/abs/html/index.html

Bill
-- 
   ___
  oo  // \\  "De Chelonian Mobile"
 (_,\/ \_/ \ TortoiseSVN
   \ \_/_\_/>The coolest Interface to (Sub)Version Control
   /_/   \_\ http://tortoisesvn.tigris.org

This e-mail transmission is strictly confidential and intended solely
for the person or organisation to whom it is addressed. It may contain
privileged and confidential information and if you are not the intended
recipient, you must not copy, distribute or take any action in reliance
on it. If you have received this email in error, please reply to the
sender as soon as possible and delete the message. Please note that we
are able to, and reserve the right to, monitor e-mail communications
passing through our network.

The views expressed in this email are not that of the company unless
specified within the message.

The inclusion of this footnote indicates that the mail message and any
attachments have been checked for the presence of known viruses.

If you have any comments regarding our policy please direct them to
[EMAIL PROTECTED]

This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com


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

RE: Request for change to /etc/profile

[robin-lists]

Hi,

I've got a sort-of-related issue with the location of the home directory.

On my work laptop, my home directory is on a network share (mapped as a H:
drive) and "My Documents" is on their too. This is made available offline using
the ... "Make Available Offline" feature of WinXP.

When I'm connected to the network all is well and cygwin correctly finds my home
directory, However, if I'm not connected to the network, cygwin just starts in
root (/). My home directory is there on the machine, but cygwin doesn't find it.

Is there any chance that this could be fixed?

Thanks,

R.
--
http://robinbowes.com  

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> [EMAIL PROTECTED]
> Sent: 22 September 2004 08:31
> To: [EMAIL PROTECTED]
> Subject: Re: Request for change to /etc/profile
> 
> On 21 Sep, CyberZombie wrote:
> >  Or 'mkdir -p "$HOME"'...
> 
> No, that would do entirely the wrong thing!
> 
> If the place where /home is supposed to be mounted hasn't 
> been mounted,
> the last thing you want to do is create an alternate /home.
> 
> I can imagine the weird problems and reports ("all my files
> disappeared!"), that doing mkdir -p would cause!
> 
> My change means that if you can't make the user directory, you just
> don't try to create the skeleton files in it for them.
> 
> >  >$ diff /etc/profile /etc/profile.orig
> >  >38,39c38
> >  >< if [ ! -d "$HOME" ] && mkdir "$HOME"
> >  >< then
> >  >---
> > >  
> >  >
> >  >>if [ ! -d "$HOME" ]; then
> 
> luke
> 
> 
> --
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:   http://cygwin.com/problems.html
> Documentation: http://cygwin.com/docs.html
> FAQ:   http://cygwin.com/faq/
> 
> 


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

Re: cygwin, libtool, dlpreopen, and .rdata

[Reini Urban]

Charles Wilson schrieb:
With newer gcc's (cygwin version numbers 3.3.3-3, 3.4.1-1, but not 
3.3.1-3), const variables are placed in an .rdata section.  This causes 
problems when those variables contain references to OTHER vars that are 
imported from a dll -- because the runtime relocation machinery can't 
fixup the address, since the variable holding the address is const -- 
and is in .rdata!
excellent! will try php soon.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Using cygwin's GnuPG with enigmail

[Ismael]

Can this be safely done? Or would I have any drawback?
Sorry but searching the mailing list archives, I get in return any 
message signed using enigmal, so this is of no use. :)

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

Re: Request for change to /etc/profile

[luke . kendall]

On 21 Sep, CyberZombie wrote:
>  Or 'mkdir -p "$HOME"'...

No, that would do entirely the wrong thing!

If the place where /home is supposed to be mounted hasn't been mounted,
the last thing you want to do is create an alternate /home.

I can imagine the weird problems and reports ("all my files
disappeared!"), that doing mkdir -p would cause!

My change means that if you can't make the user directory, you just
don't try to create the skeleton files in it for them.

>  >$ diff /etc/profile /etc/profile.orig
>  >38,39c38
>  >< if [ ! -d "$HOME" ] && mkdir "$HOME"
>  >< then
>  >---
> >  
>  >
>  >>if [ ! -d "$HOME" ]; then

luke


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

setup.log in /var/log/

[Angelo Graziosi (D. Zanello)]

Hi,
I have noted that in /var/log/ there are setup.log and setup.log.full.

setup.log contains the description of all my CYGWIN packages installation
from the first installation (Jun 2003): it is a file of 250 MB! Can I
remove these files without corrupt the CYGWIN installation?

thank you.
angelo graziosi
[EMAIL PROTECTED]



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

Re: cygwin, libtool, gdb: dll not found

[Jan Nieuwenhuizen]

Charles Wilson writes:

> [cygwin list: I'm CC'ing this so that it goes into the archives, but
> it's pretty technical about the innards of libtool...]

Great.  This addresses my yet unanswered problem that holds back guile 1.7.1

http://www.cygwin.com/ml/cygwin/2004-09/msg00883.html

> With newer gcc's (cygwin version numbers 3.3.3-3, 3.4.1-1, but not
> 3.3.1-3), const variables are placed in an .rdata section.  This
> causes problems

but this I do not understand; I've tried 2.95.3 and 3.4.1; they both
present this same popup box to whomever happens to be sitting at the
console (btw, is there a way to get Windows to display the error in a
more sensible way, to the person who actually issues the command?):

> "The application failed to initialize properly (0xc005). Click on
> OK to terminate the application."

and the strange thing is that gdb says: dll not found.

> Index: config/ltmain.in
> ===

Thanks!  I'll try this tonight.

Jan.

-- 
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien   | http://www.lilypond.org

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

Re: cygwin, libtool, dlpreopen, and .rdata

[Gary V . Vaughan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Chuck!
On 22 Sep 2004, at 07:31, Charles Wilson wrote:
Because lt_preloaded_symbols[] is an array of const structs, it is 
placed in .rdata.  However, the "nothing" symbol is a DATA export from 
cyghello-2.dll -- so the runtime psuedo-reloc machinery needs to fixup 
the address stored in "lt_preloaded_symbols[3].address" to point to 
the actual, relocated memory location of the "nothing" variable.

But it can't, because .rdata is non-writable.  However, this is a 
*runtime* error; the *link* succeeds.  But when you run the app, you 
get a popup window declaring:

"The application failed to initialize properly (0xc005). Click on 
OK to terminate the application."
Woah, it's just like the old days when we were all afraid of DATA 
exports on windows ;-)

2004-09-21  Charles Wilson  <[EMAIL PROTECTED]>
* config/ltmain.in (func_generate_dlsyms): addresses
in _preloaded_symbols[] cannot go into .rdata section
if symbols are DATA imported from DLL, on windows,
because runtime relocations must happen.
* m4/libtool.m4 (_LT_LINKER_SHLIBS([TAGNAME])):
build exports for symbols in .rdata sections
Excellent catch.  Applied.  Thankyou very much!
Cheers,
Gary.
- --
Gary V. Vaughan  ())_.  [EMAIL PROTECTED],gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker   / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (Darwin)
iD8DBQFBUS0IFRMICSmD1gYRAqQGAJ427ZJqaNfApLEjZuREBJAE5RRqBQCbBlyJ
nHhi1DtLjWV1NB0VT2hHAao=
=6Vb8
-END PGP SIGNATURE-
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: ./configure in any package gives "error: cannot find input file: WINDOWSoracle.ini" error

[Mark Aufflick]

Thanks for the tip about error reports. The cygwin config output is below.

I had already checked my windows env variables in the control panel, but
damn Rational ClearCase feels free to crap all over your environment
without warning. I don't even use oracle...

Clearing the environment variables that reference oracle.ini fixed the
error about sed not finding oracle.ini.


But it's still not creating the makefile. STDOUT shows no error - the
last few lines are:

checking for _nl_msg_cat_cntr... no
configure: creating ./config.status
config.status: creating config.h
config.status: creating src/rep_config.h
config.status: executing default commands
bash$

config.log shows nothing interessting i can see and indicates that
configure's exit status was 0.

I can configure the packages successfully on a linux box.

Gah - so frustrating! Has anyone even seen this problem before? I have
tried freshly re-installing cygwin to no avail.

Cygwin Configuration Diagnostics
Current System Time: Wed Sep 22 17:28:45 2004

Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 3

Path:   C:\opt\cygwin\usr\local\bin
C:\opt\cygwin\bin
C:\opt\cygwin\bin
C:\opt\cygwin\usr\X11R6\bin
c:\Perl\bin\
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\System32\Wbem
c:\WINDOWS\system32\nls
c:\WINDOWS\system32\nls\English
i:\sybase\sql11\dll
i:\orawin\bin
c:\temp
c:\Program Files\SecureCRT\
c:\Program Files\Rational\ClearCase\bin
c:\Program Files\VisualEdge\Shared
c:\Python22
c:\Program Files\Embarcadero\July2002Shared
c:\Program Files\Embarcadero\DBA603
Z
.\
Y
.\
.\

Output from C:\opt\cygwin\bin\id.exe (nontsec)
UID: 82646(MAufflic) GID: 10545(mkgroup-l-d)
10545(mkgroup-l-d)

Output from C:\opt\cygwin\bin\id.exe (ntsec)
UID: 82646(MAufflic) GID: 10545(mkgroup-l-d)
0(root)  544(Administrators)
545(Users)   1001(isd)1000(tccdev)
10545(mkgroup-l-d)

SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS

HOME = `c:\'
MAKE_MODE = `unix'
PWD = `/cygdrive/c'
USER = `MAufflic'

ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\maufflic\Application Data'
CLASSPATH =
`J:\Exceed60\hcljrcsv.zip;J:\Exceed60;I:\Exceed60\hcljrcsv.zip;I:\Exceed60'
CLEARCASE_PRIMARY_GROUP = `tccdev'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `AA053174'
COMSPEC = `C:\WINDOWS\system32\cmd.exe'
CVS_RSH = `/bin/ssh'
DISPLAY = `:0.0'
DOREMOTE = `yes'
HOMEDRIVE = `C:'
HOMEPATH = `\'
HOSTNAME = `AA053174'
INFOPATH =
`/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:'
LANG = `enu'
LIB = `i:\sybase\sql11\LIB'
LOCATION = `NS_SYD01'
LOGNAME = `MAufflic'
LOGONSERVER = `\\NTSYDDC03'
MANPATH =
`/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man:/usr/X11R6/man'
NAL = `Windows_2000'
NUMBER_OF_PROCESSORS = `1'
NWLANGUAGE = `ENGLISH'
NWUSERNAME = `MAufflic'
OS2LIBPATH = `C:\WINDOWS\system32\os2\dll;'
OS = `Windows_NT'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PKG_CONFIG_PATH = `/usr/X11R6/lib/pkgconfig'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 15 Model 2 Stepping 9, GenuineIntel'
PROCESSOR_LEVEL = `15'
PROCESSOR_REVISION = `0209'
PROGRAMFILES = `C:\Program Files'
PROMPT = `$P$G'
PS1 = `\[\033]0;[EMAIL PROTECTED]: \w\007\]bash$ '
REGION = `.resources.mbl'
SHLVL = `2'
SYBASE = `i:\sybase\sql11'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINDOWS'
TEMP = `c:\DOCUME~1\maufflic\LOCALS~1\Temp'
TERM = `xterm'
TERMCAP = `xterm-r6|xterm|xterm X11R6
version:am:km:mi:ms:xn:co#80:it#8:li#24:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:ae=^O:al=\E[L:as=^N:bl=^G:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cr=^M:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:do=^J:ei=\E[4l:ho=\E[H:im=\E[4h:is=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E>:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:kD=\E[3~:kI=\E[2~:kN=\E[6~:kP=\E[5~:kd=\EOB:ke=\E[?1l\E>:kh=\E[1~:kl=\EOD:kr=\EOC:ks=\E[?1h\E=:ku=\EOA:le=^H:md=\E[1m:me=\E[m:mr=\E[7m:nd=\E[C:rc=\E8:sc=\E7:se=\E[m:sf=^J:so=\E[7m:sr=\EM:ta=^I:te=\E[2J\E[?47l\E8:ti=\E7\E[?47h:ue=\E[m:up=\E[A:us=\E[4m:kb=\010:'
TMP = `c:\DOCUME~1\maufflic\LOCALS~1\Temp'
USERDOMAIN = `NTADMIN'
USERNAME = `MAufflic'
USERPROFILE = `C:\Documents and Settings\maufflic'
VE_ECDIR = `C:\Program Files\VisualEdge\Enterprise Client Deployment
Pack'
WINDIR = `C:\WINDOWS'
WINDOWID = `2097166'
WINDOWS_LOGIN = `0'
_ = `/usr/bin/cygcheck'
POSIXLY_CORRECT = `1'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_M