Re: [ITP] perl-Tk
On Nov 20 00:34, Charles Wilson wrote: Yitzchak Scott-Thoennes wrote: Hence the suggestion of using the features provided by the alternatives package. Am I correct in assuming this works even for dynamically loaded dlls? No. It works for .so's on Linux, because the Linux loader understands symlinks. Cygwin piggybacks on the Window Runtime Loader, which does NOT understand symlinks (nor shortcuts!). Because alternatives relies entirely on symlinks, it doesn't work for DLLs on windows. Though Windows Vista will introduce a new concept on NTFS called symlinks, it seems it won't help alternatives. The Windows loader doesn't understand those native symlinks, at least not in my Beta 1 version. It still bails out with Application couldn't be initialized properly (0xc022). And the way file attributes are handled in symlinks is not as transparent, as they apparently intended to make it. Too bad, I don't know how to contact the Windows developers to discuss if that couldn't be changed before Vista hits the market. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc.
Re: Concern about new g-b-s logging change - loss of error detection
On Sat, 19 Nov 2005, Max Bowsher wrote:
This thread seems to have gone to sleep.
Sorry -- it was sitting in my Follow-Up folder, but I somehow didn't get
to reply to this.
Summary: The addition of the 'logging' g-b-s feature introduced a bug:
Errors during phases of package building do not halt the build, so that
an error during 'make' or 'make install' would not prevent the 'pkg'
operation running, and producing flawed package files.
If no one has time to fix the logging feature properly right now, could
we just revert the logging feature from g-b-s CVS HEAD until someone does?
Let's try to come up with a solution (see below), but if we can't very
soon, I'll disable the logging.
=== Full text of earlier part of thread follows: ===
Max Bowsher wrote:
Igor Pechtchanski wrote:
On Sat, 29 Oct 2005, Max Bowsher wrote:
Please forgive me if this has already been discussed - I've been
time-limited to scanning subject lines only recently.
Bourne shells consider only the exit status of the last command in a
pipeline when determining $? - this means that the addition of lots of
| tee somefile will cause errors occurring during the commands being
logged to be ignored.
This seems to me to be a more severe problem than not keeping the logs
in the first place - as a failing make could result in the packaging
of a partially built package.
Max,
Thanks for bringing this up. This hasn't been discussed, and I admit
I missed this aspect of the problem when reviewing the patch. I did
have a fleeting thought of changing the tees to redirections, but
didn't realize the importance of this. I just verified that even
with set -e in effect, bash will not terminate if an interior pipe
command fails.
I can think of two ways to tackle this: use redirection (with the
loss of immediate console output),
I don't like that idea. When building a large package, this would mean
many minutes without any feedback at all.
Agreed. I just wanted to bring this up for completeness.
or use $PIPESTATUS (which is a bashism, and is fragile, unless we use
${PIPESTATUS[$(([EMAIL PROTECTED]))]}).
I think using a bashism is OK. Even people who don't actually use bash
interactively will have it installed - it's in 'Base', after all.
So, we make g-b-s a /usr/bin/bash script instead of /bin/sh script? Are
there any objections to this? Is this script ever used in any (e.g.,
cross-compilation) environments where /bin/sh is *not* bash?
Why would ${PIPESTATUS[1]} not be OK?
Because that would only work for cases where the only pipe is added by
logging (i.e., fragile). If someone ever wanted to pipe something to
configure in that step, whoever made the change would need to know to
change ${PIPESTATUS[1]} to ${PIPESTATUS[2]}, which is too easy to miss
(i.e., fragile). I'm willing to be convinced that I'm being paranoid
here, though.
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!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Concern about new g-b-s logging change - loss of error detection
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Igor Pechtchanski wrote:
On Sat, 19 Nov 2005, Max Bowsher wrote:
Summary: The addition of the 'logging' g-b-s feature introduced a bug:
Errors during phases of package building do not halt the build, so that
an error during 'make' or 'make install' would not prevent the 'pkg'
operation running, and producing flawed package files.
If no one has time to fix the logging feature properly right now, could
we just revert the logging feature from g-b-s CVS HEAD until someone does?
Let's try to come up with a solution (see below), but if we can't very
soon, I'll disable the logging.
Good.
...
or use $PIPESTATUS (which is a bashism, and is fragile, unless we use
${PIPESTATUS[$(([EMAIL PROTECTED]))]}).
I think using a bashism is OK. Even people who don't actually use bash
interactively will have it installed - it's in 'Base', after all.
So, we make g-b-s a /usr/bin/bash script instead of /bin/sh script? Are
there any objections to this? Is this script ever used in any (e.g.,
cross-compilation) environments where /bin/sh is *not* bash?
Bash usually lives in /bin, not /usr/bin.
I would think that any Linux system featureful enough to have a
compiler, would have a /bin/bash.
Why would ${PIPESTATUS[1]} not be OK?
Because that would only work for cases where the only pipe is added by
logging (i.e., fragile). If someone ever wanted to pipe something to
configure in that step, whoever made the change would need to know to
change ${PIPESTATUS[1]} to ${PIPESTATUS[2]}, which is too easy to miss
(i.e., fragile). I'm willing to be convinced that I'm being paranoid
here, though.
Hang on: It is the *first* item in the pipe (the real command) that we
care about, anyway, not any filters placed after it. So,
${PIPESTATUS[0]}, and we don't need to worry about people adding to the
end of the pipe.
Max.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFDgLCgfFNSmcDyxYARAsbmAKCQi6Zk4Ey6zp4j5qe2Ravp6Tl9qACfcfIj
B8RJBVTLT5z9//YcvnXPBwI=
=NTyg
-END PGP SIGNATURE-
Re: [ITP] perl-Tk
On Sun, Nov 20, 2005 at 12:34:33AM -0500, Charles Wilson wrote:
Yitzchak Scott-Thoennes wrote:
Hence the suggestion of using the features provided by the
alternatives package. Am I correct in assuming this works even for
dynamically loaded dlls?
No. It works for .so's on Linux, because the Linux loader understands
symlinks. Cygwin piggybacks on the Window Runtime Loader, which does
NOT understand symlinks (nor shortcuts!). Because alternatives relies
entirely on symlinks, it doesn't work for DLLs on windows.
WJFFM (perhaps you missed the dynamically?):
$ cat mydll.c
#include stdio.h
void hello(void)
{
printf (Hello World!\n);
}
$ gcc -Wall -shared -o mydll.dll mydll.c
$ ln -s mydll.dll mydllalternate.dll
$ cat myprog.c
#include dlfcn.h
int main(int argc, char **argv)
{
void *dlh = dlopen(mydllalternate.dll, RTLD_NOW);
void (*dls)(void) = dlsym(dlh, hello);
dls();
return 0;
}
$ gcc -Wall -o myprog.exe myprog.c
$ ./myprog.exe
Hello World!
Re: [ITP] perl-Tk
Yitzchak Scott-Thoennes wrote: void *dlh = dlopen(mydllalternate.dll, RTLD_NOW); That's because dlopen() is a Cygwin function that understands things like LD_LIBRARY_PATH and posix paths. But if you use it you are not using the windows runtime loader, at least not directly. If you try your sample above using LoadLibrary it will fail. Brian
Re: [ITP] perl-Tk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gerrit P. Haase wrote: Already done. It builds fine, however I see some tests failing and the demo widget is not running properly here. Already posted a question about this at the main list. Based on what I responded there, can this be GTG? Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDgNfypiWmPGlmQSMRAlCkAJ9iZd74Vp0GM98ZeGNAgjKiqE50agCcC5MV Qj2WAkwnQ1vVbWTFlFf6jhI= =rYMj -END PGP SIGNATURE-
Re: [ITP] perl-Tk
On Sun, Nov 20, 2005 at 11:50:53AM -0800, Brian Dessent wrote: Yitzchak Scott-Thoennes wrote: void *dlh = dlopen(mydllalternate.dll, RTLD_NOW); That's because dlopen() is a Cygwin function that understands things like LD_LIBRARY_PATH and posix paths. But if you use it you are not using the windows runtime loader, at least not directly. If you try your sample above using LoadLibrary it will fail. Anyway, I'm satisfied that alternatives could be used with perl extension dlls.
Rsync and Chinese characters problem
I'm trying to setup a series of windows computers to automatically back themselves up to a remote rsync server. To accomplish this I installed cygwin with cron, ssh, and rsync on all the systems. However, a couple systems will not backup, looking at the logfiles reveals comments like file has vanished: and reports of filenames with multiple questionmarks as the filename. Right now I'm resorting to scp'ing, which of course transmits all files every time. Is there anyway to get rsync to work with a Chinese charcterset somehow? Thanks, Robert PS: I'm using a command like: rsync -vzae ssh /cygdrive/c/Documents and Settings [EMAIL PROTECTED]:
Re: Rsync and Chinese characters problem
On Sun, Nov 20, 2005 at 06:42:23PM -0800, Robert Lucas wrote: I'm trying to setup a series of windows computers to automatically back themselves up to a remote rsync server. To accomplish this I installed cygwin with cron, ssh, and rsync on all the systems. However, a couple systems will not backup, looking at the logfiles reveals comments like file has vanished: and reports of filenames with multiple questionmarks as the filename. Right now I'm resorting to scp'ing, which of course transmits all files every time. Is there anyway to get rsync to work with a Chinese charcterset somehow? Sorry, but this isn't a bug reporting mailing list. Please use the main cygwin list to discuss how to use an application. cgf
Re: Rsync and Chinese characters problem
Will do, sorry to post in the wrong place. Robert Christopher Faylor: On Sun, Nov 20, 2005 at 06:42:23PM -0800, Robert Lucas wrote: I'm trying to setup a series of windows computers to automatically back themselves up to a remote rsync server. To accomplish this I installed cygwin with cron, ssh, and rsync on all the systems. However, a couple systems will not backup, looking at the logfiles reveals comments like file has vanished: and reports of filenames with multiple questionmarks as the filename. Right now I'm resorting to scp'ing, which of course transmits all files every time. Is there anyway to get rsync to work with a Chinese charcterset somehow? Sorry, but this isn't a bug reporting mailing list. Please use the main cygwin list to discuss how to use an application. cgf
