dlltool and def files with dots and aliasing
Hi: I am trying to build an import library from a windows dll for which I do not have the source code. I am new to cygwin and programming on windows, and I understand that there are two main steps to this: 1. Extract a def file from the dll 2. Use dlltool to create the import library The method described in the cygwin documentation echo EXPORTS > cplex110.def nm cplex110.dll | grep ' T _' | sed 's/.* T _//' >> foo.def does not work in this case. I get "nm: cplex110.dll: no symbols" So, I tried pexports cplex110.dll | sed 's/^_//' > cplex110.def as described at http://www.emmestech.com/software/cygwin/pexports-0.43/moron1.html However, when run on this file, dlltool craps out with syntax errors. I was not sure what was going on, and finally I got my hands onto dumpbin.exe /EXPORTS to get more info from the dll. There seem to be two issues: 1. pexports does not yield a correct def file when aliasing is used in the dll 2. dlltool does not like dots in the exported symbol names. Ultimately, I think I have the following problem. Output of dumpbin: ordinal hint RVA name 119 76 00129808 CPXaddrows 120 77 CPXaddrows. (forwarded to [EMAIL PROTECTED]) 659 293 00129814 [EMAIL PROTECTED] 660 294 00129808 [EMAIL PROTECTED] . As far as I understand, the def file should contain the following: EXPORTS ... CPXaddrows CPXaddrows.= [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ... Run on this file, dlltool -d cplex110.def --dllname cplex110.lib -l libcplex.a -k breaks with a syntax error at the first line that contains a dot. This syntax error is independent from the aliasing: ... CPXaddrows CPXaddrows. [EMAIL PROTECTED] [EMAIL PROTECTED] ... does also break. When I remove all lines with a dot from the def file, dlltool works, and my program builds fine because it only calls CPXaddrows. Then, it yields a run time error after CPXaddrows is called. Does anyone have an idea about how to fix this. Thanks. Kerem -- 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: Wish Setup would accept my Perl
"Andrew DeFaria" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Well that tells you that your previous invocations of system and backquote
constructs were not portable to start with. It would be far better to
centralize such things to a subroutine to try to mitigate the portability
issues. Then again if you are gonna call programs that just don't exist on
anything but Windows you will have a problem. But perhaps you can do it in
a more "posix" way. And if all else fails you can call the cmd built in
with "cmd /c ".
Yes, I've done that in most cases, and tested $^O to know what to do. In the
case I noticed I was calling a Windows program by a Windows path and had no
reason to write it differently. So if I want to run that particular script
under Cygwin Perl I could branch to an sh-compatible call, or actually I
rather like the idea of "standardising" on system("cmd /c
...") even if it does waste a cmd.exe invocation :)
As I said I don't know exactly why your Tk isn't working. I do know that
Tk under Cygwin assumes a running X server. I rarely run an X server - I
simply use rxvt instead - so I don't like that requirement. I also work
with IBM/Rational products and often need to run ccperl or cqperl - both
of which are AS based. And they have Tk in there that works straight on
Windows (like rxvt does if it senses there is no X server running - I wish
Cygwin's Perl::Tk would do that!).
Actually I had no idea - and I must say that rather dissuades me from using
it. I have no other need for an X server, and I quite like the way AS
Perl/Tk gives me Windows controls on Windows and X widgets on X. (I have
installed AS Perl on Solaris and run some of my Perl/Tk scripts there
without problem. Thanks for pointing that out.
--
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: Wish Setup would accept my Perl
"Andrew DeFaria" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Well that tells you that your previous invocations of system and backquote
constructs were not portable to start with. It would be far better to
centralize such things to a subroutine to try to mitigate the portability
issues. Then again if you are gonna call programs that just don't exist on
anything but Windows you will have a problem. But perhaps you can do it in
a more "posix" way. And if all else fails you can call the cmd built in
with "cmd /c ".
Yes, I've done that in most cases, and tested $^O to know what to do. In the
case I noticed I was calling a Windows program by a Windows path and had no
reason to write it differently. So if I want to run that particular script
under Cygwin Perl I could branch to an sh-compatible call, or actually I
rather like the idea of "standardising" on system("cmd /c
...") even if it does waste a cmd.exe invocation :)
As I said I don't know exactly why your Tk isn't working. I do know that
Tk under Cygwin assumes a running X server. I rarely run an X server - I
simply use rxvt instead - so I don't like that requirement. I also work
with IBM/Rational products and often need to run ccperl or cqperl - both
of which are AS based. And they have Tk in there that works straight on
Windows (like rxvt does if it senses there is no X server running - I wish
Cygwin's Perl::Tk would do that!).
Actually I had no idea - and I must say that rather dissuades me from using
it. I have no other need for an X server, and I quite like the way AS
Perl/Tk gives me Windows controls on Windows and X widgets on X. (I have
installed AS Perl on Solaris and run some of my Perl/Tk scripts there
without problem. Thanks for pointing that out.
--
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: Wish Setup would accept my Perl
"Brian Mathis" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] I think the biggest problem you're having is conceptual. It's easy to view a bash prompt as just a better DOS prompt that gives you unix commands in addition to windows command line commands. ... The solution is to start breaking the habit of using a bash prompt for windows commands. Open a DOS command window and use that (as much as it hurts). Any perl run from that command window will use AS perl. Even "better", don't run AS perl scripts from a prompt at all, double-click on them and start them like any other windows app. Do not try to use AS perl from a bash prompt. Anything run from a bash prompt should use cygwin perl. Actually I tend to go the other way. I do most of my work in a bash shell and if I need to use a Windows command I start a command prompt. (BTW, thanks to all of you who pointed out Console2 - I love it!) However if I were to follow your last advice I would have to convert my AS scripts to Cygwin as noted previously. Other parts of this thread have discussed the issues I've created for myself, and they are in fact relatively minor, except that as I noted I am rather uncomfortable with the idea that I must run Perl/Tk under an X server. But let me ask you this, please: what about running Cygwin programs from Windows. Some of the Perl scripts that I run from bash I also run as integrated tools from Eclipse, Windows Explorer, etc., and some of them rely on Cygwin commands. (The detail is a bit grungy: it's actually a Tk interface to SCCS.) To accomplish this I have put cygwin\bin on my Windows path. What is your opinion on that, please? You should not have AS perl in your cygwin path -- cygwin should not know about it at all. Yes, I now do not have AS Perl in my Cygwin path. I also think this is a bad idea: "#!/local/perl/bin/perl finds my AS perl (which is in D:\Local\Perl, and D:\Local is mounted on /local)" Why, please? -- 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: Wish Setup would accept my Perl
"Jevin Sweval" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] At work, we develop using both Cygwin's perl and AS's perl (we distribute our app to people without Cygwin but with ActivePerl). Thank you for these comments, Your environment is similar to my situation; my coworkers to whom I distribute some of my scripts may not need or want Cygwin. But let me ask you a detail (which I have also asked elsewhere in this thread): in order to invoke a script that calls cygpath (or any other Cygwin program for that matter) I assume it is necessary to have cygwin\bin in your Windows path? -- 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: Wish Setup would accept my Perl
"Michael Kairys" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] As an aside, there seems to be something broken in my installation re. Tk (or perhaps I'm missing something). If I run a script containing (only) "use Tk" I get: Can't load '/usr/lib/perl5/vendor_perl/5.8/cygwin/auto/Tk/Tk.dll' for module Tk: No such file or directory at /usr/lib/perl5/5.8/cygwin/DynaLoader.pm line 230. It was noted elsewhere in this thread that Cygwin Perl/Tk requires a running X server. I find this disappointing and, since I have no other need for an X server at present, even prohibitive; but I would like to know more about how to set this up. Where can I go to learn more about this? (I see there is a gmane.os.cygwin.perl group but it is not active..) -- 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: Wish Setup would accept my Perl
On 11 December 2007 12:21, Michael Kairys wrote: > To accomplish this I have put cygwin\bin on my Windows path. What is your > opinion on that, please? A wholly excellent idea IMO :) You can run into the occasional confusion about PATH ordering where there are utilities of the same name. This generally happens with 'find.exe' and 'link.exe'. Since the cmd.exe version of find is completely useless when compared to grep, and since I only invoke link.exe from devstudio, I put the cygwin bin dir at the start of my path and let it override windows tools. 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-1.5.25-5 is missing newlib math updates
On Dec 10 13:09, Cary R. wrote: > Attached are the two ChangeLog entries from newlib and a patch of the math > directory differences between my modified 1.5.24 and 1.5.25. I did a quick > visual check and this single patch appears to match the two I originally > sent. Please let me know if I can be of further assistance. Thanks for the patches. I applied them to the 1.5.x branch. Barring any further catastrophies in 1.5.25, I will release a new 1.5.25 within a couple of days. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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-1.5.25-5 is missing newlib math updates
On Dec 11, 2007 8:06 AM, Corinna Vinschen wrote: > Thanks for the patches. I applied them to the 1.5.x branch. Barring > any further catastrophies in 1.5.25, I will release a new 1.5.25 within > a couple of days. While you're at it... http://sourceware.org/ml/newlib/2007/msg00912.html http://cygwin.com/ml/cygwin/2007-10/msg00252.html 2007-09-04 Kazunori Asayama <[EMAIL PROTECTED]> * libm/math/wf_tgamma.c: Add missing include. === RCS file: /cvs/src/src/newlib/libm/math/wf_tgamma.c,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- src/newlib/libm/math/wf_tgamma.c2002/06/07 21:59:56 1.1 +++ src/newlib/libm/math/wf_tgamma.c2007/09/04 17:33:10 1.2 @@ -14,6 +14,7 @@ */ #include "math.h" +#include "fdlibm.h" #ifdef __STDC__ float tgammaf(float x) -- 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: BUG: Timezone failures with threads under Cygwin 1.5.25
On Dec 10 17:00, Jerry D. Hedden wrote:
> [...]
> Under 1.5.24, this test always passes. Under 1.5.25, it is
> now frequently failing. If I add a debugging call in the
> central most loop:
>
> print("got: $lt exp: $localtime\n");
>
> I get the following as typical of the problem:
>
> 5 perl-current > ./perl -Ilib ext/threads/t/libc.t
> 1..11
> ok 1 - use threads
> got: Wed Dec 31 20:00:08 1969 exp: Wed Dec 31 19:00:08 1969
> [...]
> This shows a 1 hour difference between the expected and
> actual results - which looks like a timezone issue.
>
> As the changes for 1.5.25 include numerous references to
> timezone handling changes, I suspect there may be some
> re-entrancy bug in those changes.
It would be more helpful if you would send self-contained code which
doesn't have to be tweaked to do a test. I'm not a perl developer, so
it took me some time to get it running. I'd also really prefer
testcases in plain C which I can simply run under GDB. Interpreter code
just adds unnecessary complexity.
I assume the perl libs are using localtime_r, right? Otherwise you
can't rely on reentrency nor thread-safety. Anyway, localtime is
supposed to be thread-safe in Cygwin.
The only change in 1.5.25 related to localtime is the fact that the
environment variable "TZ" is now left alone by Cygwin. Up to 1.5.24 the
function tzset() (called by localtime()) also sets the environment
variable "TZ", which is apparently incorrect according to POSIX. "TZ"
is used in later calls to decide whether some other code has to be run
or not.
And exactly that's the problem. Since TZ is now never set, that other
code, which is not thread-safe, is called much more frequent than
necessary. Actually it should only be called once per process, now it's
called once per invocation of tzset(). I've applied a patch to the 1.5.x
branch and will release an updated 1.5.25 in the next couple of days.
Thanks for the report,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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: Problems with PostgreSQL 8
So far, I put postmaster to run, but it does not receive any connection. trying to start /etc/rc.d/init.d/postgres fails. Running cygsrv -S cygserver results in error 120. My conclusion is I cannot run Postgres 8 on this plataform. If anyone can run Postgres 7 or know any *working* tutorial, just tell me (I´ve followed 3 or 4 tutorials and all them gives me the same results - no connection to the DB). Cheers! Ricardo -- 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-1.5.25-5 is missing newlib math updates
On Dec 11 09:06, Lev Bishop wrote: > On Dec 11, 2007 8:06 AM, Corinna Vinschen wrote: > > > Thanks for the patches. I applied them to the 1.5.x branch. Barring > > any further catastrophies in 1.5.25, I will release a new 1.5.25 within > > a couple of days. > > While you're at it... > http://sourceware.org/ml/newlib/2007/msg00912.html > http://cygwin.com/ml/cygwin/2007-10/msg00252.html > > > 2007-09-04 Kazunori Asayama <[EMAIL PROTECTED]> > > * libm/math/wf_tgamma.c: Add missing include. Thanks, applied to the 1.5.x branch. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
kill -STOP mencoder_pid does not stop process execution
Dear List, sometimes I have to pause the execution of the mencoder process on my cygwin hosted by an XP SP2. If I press Ctrl+S the mencoder is stopped nicely. I wanted to pause it from a script. I tried the normal UNIX way sending a SIGSTOP signal to the process (kill -STOP mencoder_PID) from an other bash window. Running "ps" I could see it had "S" status, but mencoder was still writing to stdout and the CPU usage was still nearly 100%. I even tried "kill -TSTP mencoder_PID", but the same result. I tried to google for this problem without luck. Why it behaves like this? How can I gracefully pauses a process execution from a script? I also found an other strange thing, which may be connected to this problem. Pressing ctrl+Z on mencoder I get a prompt, but mencoder still writes to the screen. I can enter any command and it is executed properly. Running "fg" mencoder becomes the foreground process and it writes to the screen (as normal). Why does not stops if ctrl+Z is pressed? Thanks in advance! TT _ Rövid angol nyelvlecke következik. Elektronikus postafiók/postaláda - Mailbox www.mailbox.hu -- 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: BUG: Timezone failures with threads under Cygwin 1.5.25
Jerry D. Hedden wrote:
> [...]
> Under 1.5.24, this test always passes. Under 1.5.25, it is
> now frequently failing. If I add a debugging call in the
> central most loop:
>
> print("got: $lt exp: $localtime\n");
>
> I get the following as typical of the problem:
>
> 5 perl-current > ./perl -Ilib ext/threads/t/libc.t
> 1..11
> ok 1 - use threads
> got: Wed Dec 31 20:00:08 1969 exp: Wed Dec 31 19:00:08 1969
> [...]
> This shows a 1 hour difference between the expected and
> actual results - which looks like a timezone issue.
>
> As the changes for 1.5.25 include numerous references to
> timezone handling changes, I suspect there may be some
> re-entrancy bug in those changes.
Corinna Vinschen wrote:
> It would be more helpful if you would send self-contained code which
> doesn't have to be tweaked to do a test. I'm not a perl developer, so
> it took me some time to get it running. I'd also really prefer
> testcases in plain C which I can simply run under GDB. Interpreter code
> just adds unnecessary complexity.
I was working on this when I got your email. Attached.
> I assume the perl libs are using localtime_r, right? Otherwise you
> can't rely on reentrency nor thread-safety. Anyway, localtime is
> supposed to be thread-safe in Cygwin.
I believe this is correct.
> The only change in 1.5.25 related to localtime is the fact that the
> environment variable "TZ" is now left alone by Cygwin. Up to 1.5.24 the
> function tzset() (called by localtime()) also sets the environment
> variable "TZ", which is apparently incorrect according to POSIX. "TZ"
> is used in later calls to decide whether some other code has to be run
> or not.
>
> And exactly that's the problem. Since TZ is now never set, that other
> code, which is not thread-safe, is called much more frequent than
> necessary. Actually it should only be called once per process, now it's
> called once per invocation of tzset(). I've applied a patch to the 1.5.x
> branch and will release an updated 1.5.25 in the next couple of days.
Hope my test program helps to verify this.
/*
*
* Test program that evokes 'localtime'+threads bug
*
* Build: gcc -o loctim_bug loctim_bug.c
* Run:./loctim_bug.exe
*
*/
#include
#include
#define MAX_THR 25
#define MAX_LOOP 1
/* Set this to 24 minus your non-DST timezone */
/* For example, EDT = -5, therefore use 19*/
#define EXPECTED 19
void *
time_loop(void* data)
{
int arg = *((int *)data);
time_t when = (time_t)arg;
int ii;
struct tm *tm;
struct timespec sleep, remainder;
sleep.tv_sec = 0;
sleep.tv_nsec = 1000;
for (ii=0; ii < MAX_LOOP; ii++) {
tm = localtime(&when);
if (tm->tm_hour != EXPECTED)
printf("BUG in thread %2d: expected: %d got: %d\n",
arg, EXPECTED, tm->tm_hour);
nanosleep(&sleep, &remainder);
}
}
int
main(int argc, char **argv)
{
int ii;
pthread_t p_thread[MAX_THR];
int args[MAX_THR+2];
/* Launch threads */
for (ii=0; ii < 50; ii++) {
args[ii] = ii;
pthread_create(&p_thread[ii], NULL, time_loop, (void*)&args[ii]);
}
/* Make sure threads finish */
args[MAX_THR] = MAX_THR;
time_loop((void*)&args[MAX_THR]);
args[MAX_THR+1] = MAX_THR+1;
time_loop((void*)&args[MAX_THR+1]);
printf("Done\n");
}
/* EOF */
--
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: get cygpath to leave relative paths as relative?
On Dec 10 22:34, Brent wrote: > If I execute > mypath=`cygpath -w ../` > echo $mypath > > I get > d:\unix\nextVersion\script > > OK, d:\unix\nextVersion\script is the correct windows version of the path, > but it is in absolute form. I would prefer it if cygpath left it in relative > form, i.e. > echo $mypath > should output > ..\ This is not always possible when converting POSIX paths to Win32 paths for a couple of reasons. One reason is that a relative path might contain symlinks, another one is that a path containing .. could cross mount points. To recognize both cases extra processing is necessary which might convert the path to an absolute form. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: get cygpath to leave relative paths as relative?
On Mon, 10 Dec 2007, Brent wrote: > If I execute > mypath=`cygpath -w ../` > echo $mypath > > I get > d:\unix\nextVersion\script > > OK, d:\unix\nextVersion\script is the correct windows version of the > path, but it is in absolute form. I would prefer it if cygpath left it > in relative form, i.e. > echo $mypath > should output > ..\ > > Executing > cygpath --help > indicates that the only related option is -a, but that forces conversion > to absolute paths, which is the opposite of what I want. It seems, > unfortunately, as if cygpath has -a on by default and has no way to turn > it off! > > Is this a known bug or implementation quirk in cygpath, or did I > overlook something? (Web searching on cygpath and "relative path" > generated a ton of hits, but none out of the first 100 that I looked > thru seemed related...) In addition to what Corinna said, if you don't have any symlinks in the relative path, you should be able to use the forward slash variant without using cygpath. All Windows system calls (and most Windows programs) understand forward slashes just fine. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "That which is hateful to you, do not do to your neighbor. That is the whole Torah; the rest is commentary. Go and study it." -- Rabbi Hillel -- 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: BUG: Timezone failures with threads under Cygwin 1.5.25
On Dec 11 10:24, Jerry D. Hedden wrote: > Corinna Vinschen wrote: > > It would be more helpful if you would send self-contained code which > > doesn't have to be tweaked to do a test. I'm not a perl developer, so > > it took me some time to get it running. I'd also really prefer > > testcases in plain C which I can simply run under GDB. Interpreter code > > just adds unnecessary complexity. > > I was working on this when I got your email. Attached. Thanks for this testcase. It exhibited a threading issue in tzset which was already present in older Cygwin versions. I've applied another fix to Cygwin which (hopefully) solves this issue once and for all. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: kill -STOP mencoder_pid does not stop process execution
On Dec 11, 2007 10:18 AM, TAJTHY Tamás wrote: > Dear List, > > sometimes I have to pause the execution of the mencoder process on my cygwin > hosted by an XP SP2. If I press Ctrl+S the mencoder is stopped nicely. I > wanted > to pause it from a script. I tried the normal UNIX way sending a SIGSTOP > signal > to the process (kill -STOP mencoder_PID) from an other bash window. Running > "ps" > I could see it had "S" status, but mencoder was still writing to stdout and > the > CPU usage was still nearly 100%. I even tried "kill -TSTP mencoder_PID", but > the > same result. I think this is because of this longstanding cygwin issue: http://cygwin.com/ml/cygwin-patches/2003-q4/msg00055.html Which I think may also be the reason why it usually makes my console unusable if I try to use ^Z to suspend, eg, $ yes | less (Although I haven't looked at this stuff in ages, so maybe I don't know what I'm talking about -- I'm sure CGF will pipe up if I'm completely wrong). Lev -- 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/
All directories marked as non-writable on FAT32
Newest Cygwin: 1.5.25 Hi, with the newest Cygwin (see above) all directories on a FAT thumb drive[1] are marked as "500" (should be 700) - although the directories are of course writable. I think this is a bug and should be fixed. Thanks, Thorsten PS directories on C: (NTFS) show as 700 or 770 [1] OS is Vista - haven't tested it under XP -- 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: All directories marked as non-writable on FAT32
On Dec 11 18:17, Thorsten Kampe wrote: > Newest Cygwin: 1.5.25 > > Hi, > > with the newest Cygwin (see above) all directories on a FAT thumb > drive[1] are marked as "500" (should be 700) Grr, I mixed this up because I failed to see an exclamation mark. So that was broken for all non-NTFS filesystems. I fixed that in cvs. Will be in the next 1.5.25 release. Thanks for the report, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: squid-2.6.STABLE17-1: Web Proxy Cache
Hi A new version of 'squid' has been uploaded to a server near you. Cygwin NEWS: o Maintainer change o New Upstream release o Switched to cygport build framework o Cleanup of installation directories squid NEWS: === o http://www.squid-cache.org/Versions/v2/2.6/changesets/ o http://www.squid-cache.org/Versions/v2/2.5/changesets/ DESCRIPTION: Web Proxy Cache UPDATE: === 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. Save it and run setup, answer the questions and pick up 'squid' from the 'Web' category (it should already be selected). DOWNLOAD: = Note that downloads from sources.redhat.com (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- Dr. Volker Zell volunteer cygwin squid maintainer CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to 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. -- 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: rcs-5.7-4: The Revision Control System
Hi
A new version of `rcs' has been uploaded to a server near you.
Cygwin NEWS:
o Maintainer change
o Switched to cygport build framework
o Documentation and manual pages now under /usr/share/{man/doc} hierarchy
o The patch posted in http://sources.redhat.com/ml/cygwin/2001-07/msg00161.html
has been removed as it's not reproducible under latest cygwin
DESCRIPTION:
The Revision Control System (RCS) manages multiple revisions of files.
RCS automates the storing, retrieval, logging, identification, and merging of
revisions.
RCS is useful for text that is revised frequently, e.g., programs,
documentation,
graphics, papers, and form letters.
UPDATE:
===
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.
Save it and run setup, answer the questions and pick up 'rcs' from
the 'Devel' category (it should already be selected).
DOWNLOAD:
=
Note that downloads from sources.redhat.com (aka cygwin.com) aren't
allowed due to bandwidth limitations. This means that you will need to
find a mirror which has this update, please choose the one nearest to you:
http://cygwin.com/mirrors.html
QUESTIONS:
==
If you want to make a point or ask a question the Cygwin mailing list is
the appropriate place.
--
Dr. Volker Zell
volunteer cygwin rcs maintainer
CYGWIN-ANNOUNCE UNSUBSCRIBE INFO:
=
To unsubscribe to 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.
--
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: question with xargs and jar- seems to drop files.
On 05/12/2007, Mike Marchywka <[EMAIL PROTECTED]> wrote: > I seem to have an odd problem with xargs and jar. I'm not sure if I can > isolate a simple test > case but essentially it only seems to be taking some of the input files. > > This seems to work suggesting the file list is acceptable to jar: > > $ more latest65day | jar [EMAIL PROTECTED] wtf2.zip>jarlog2.txt > > this, however, only includes a some files, apparently lopping off certain > directories: > > $ more latest65day | xargs jar -cvf wtf2.zip>jarlog.txt > > > $ xargs --version > GNU xargs version 4.3.8 > Built using GNU gnulib version 2007-05-26 > > [EMAIL PROTECTED] /cygdrive/e/new/temp > $ jar -V > jar (fastjar) 0.92-gcc > > Copyright 1999, 2000, 2001 Bryan Burns > Copyright 2002 Free Software Foundation > > Thoughts on diagnostic process of known problems? At first, I thought it had > to do with > errors encountered during the jarring but I think I've eliminated all of > those ( missing files > mostly). Also, as I indicated before, my configuration is suspect but I > wouldn't expect it > to cause problems like this. I expect you've got this covered, but last week when I had a similar problem with xargs and tar, it turned out that my problem was that I hadn't read the xargs manpage (not recently anyway). Its second sentence is "xargs ... executes the command ... one or more times ...". The solution was to use tar's --files-from option. For jar: -@, see above (except that you should redirect jar's standard input to your file-of-files with "http://groups.google.co.uk/group/comp.unix.shell/search?q=useless+use+of+cat ;). -- 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: kill -STOP mencoder_pid does not stop process execution
Dear Lev, > 2007. 12. 11. k. 19:06, "Lev Bishop" <[EMAIL PROTECTED]> írta: >> sometimes I have to pause the execution of the mencoder process on my cygwin >> hosted by an XP SP2. If I press Ctrl+S the mencoder is stopped nicely. I >> wanted >> to pause it from a script. I tried the normal UNIX way sending a SIGSTOP >> signal >> to the process (kill -STOP mencoder_PID) from an other bash window. Running >> "ps" >> I could see it had "S" status, but mencoder was still writing to stdout and >> the >> CPU usage was still nearly 100%. I even tried "kill -TSTP mencoder_PID", but >> the >> same result. > >I think this is because of this longstanding cygwin issue: >http://cygwin.com/ml/cygwin-patches/2003-q4/msg00055.html Aha... This can be a reason. :-( Is there a way how to stop and continue a process from a script from an other console??? Thanks in advance && Good byte! TT _2 személyes INGYENES korfui útat is nyerhetsz! -- 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: Wish Setup would accept my Perl
2007/11/7, Brian Mathis <[EMAIL PROTECTED]>: > On Nov 7, 2007 10:44 AM, Andrew DeFaria <[EMAIL PROTECTED]> wrote: > > DePriest, Jason R. wrote: > > > I once, like you, wondered why I couldn't just have one installation > > > of Perl or Python that works in either environment. Since I write > > > scripts, not code, > > > > An aside? How is a Perl script not Perl code?!? Just wondering... > > > > > I assumed it was because it was just too hard to do and began to use > > > each program in its appropriate place. > > > > Hmmm... I'm curious. As you said you have both AS Perl and Cygwin's > > Perl. Now you say use each one where it is appropriate. I can't think of > > a reason why using one or the other is more appropriate than the other. > > As you state below regarding PPM, AS Perl is obviously Windows centric > > and Cygwin's Perl is admittedly Posix centric. Being as I don't see many > > Unix/Linux Perls with a Window's centric viewpoint I would think that > > sticking with Posix through and through (including CPAN rather than the > > uniquely AS PPM) would provide the best shot at being the most portable > > out of the gate! > > How about if you are writing a Windows application? What if you need > to manipulate the Registry or access Win32::OLE objects? You > certainly need AS Perl for that. It's not hard to imagine why you'd > need a Windows-centric version. Win32::OLE COM objects, Registry access, Win32:GUI and all of libwin32 works fine on cygwin perl. With cygwin perl you have the best of both worlds. Well, with the current perl release there is a problem with the latest libwin32, which needs a perl update which does not work yet good enough, but with the prev libwin32 everything should work which works on AS perl also. The only thing which doesn't work on cygwin perl are some closed source binary-only MSVC modules (2 or 3 three), and the Win32::API module with gcc callbacks. This compared to the thousands of cpan modules which DO NOT work with ActiveState perl is a nice advantage of cygwin perl. Only if I have to distribute single file exe's I prefer AS perl with perl2exe or par. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ http://spacemovie.mur.at/ http://helsinki.at/ -- 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: Problems with PostgreSQL 8
2007/12/11, cappellano <[EMAIL PROTECTED]>: > So far, I put postmaster to run, but it > does not receive any connection. trying to start > /etc/rc.d/init.d/postgres fails. Running cygsrv -S cygserver results > in error 120. My conclusion is I cannot run Postgres 8 on this > plataform. > > If anyone can run Postgres 7 or know any *working* tutorial, just tell > me (I´ve followed 3 or 4 tutorials and all them gives me the same > results - no connection to the DB). I also have a working postgres 7 also which is not tested on win98 neither on my setup site. Just try to Add http://rurban.xarch.at/software/cygwin/ to your setup site and add the postgresql7.4 package there. But I wonder if this will work, because your real problem seems to be the missing IPC support with your failing cygserver. This is not related to postgresql at all. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ http://spacemovie.mur.at/ http://helsinki.at/ -- 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: Wish Setup would accept my Perl
"Reini Urban" <[EMAIL PROTECTED]> wrote in message Win32::OLE COM objects, Registry access, Win32:GUI and all of libwin32 works fine on cygwin perl. With cygwin perl you have the best of both worlds. Is it correct that Cygwin Perl/Tk requires a running X server? -- 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: Wish Setup would accept my Perl
Michael Kairys wrote: > > "Reini Urban" <[EMAIL PROTECTED]> wrote in message >> Win32::OLE COM objects, Registry access, Win32:GUI and all of >> libwin32 works fine on cygwin perl. With cygwin perl you have the best >> of both worlds. > > Is it correct that Cygwin Perl/Tk requires a running X server? > That is one of the stranger assertions to pass by here in a while. More so than the (OT, as there is that other list) complaint that installing X from cygwin setup is a pain. -- 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: get cygpath to leave relative paths as relative?
Corinna wrote:
>This is not always possible when converting POSIX paths to Win32 paths
>for a couple of reasons. One reason is that a relative path might
>contain symlinks, another one is that a path containing .. could cross
>mount points. To recognize both cases extra processing is necessary
>which might convert the path to an absolute form.
Thanks for responding.
You use qualifiers like "not always possible" and "might". Does that imply
that cygpath CAN leave relative paths as relative under certain circumstances?
What I am seeing is that it always converts relative paths to absolute paths,
even in cases that are outside the scenarios that you mention. In particular,
I have no symlinks. But I am not sure what you mean by "cross mount points.
Sorry for my ignorance, but are you saying that if my path list contains paths
that come from different physical drives ("mount points"?), then this will
cause cygpath to always revert to absolute form? If that is the meaning, then
my path list does "cross mount points" because I have multiple physical drives.
On the other hand, I wrote a simple test script that basically just contains
the line
echo `cygpath -pw ../:../..`
I executed that script from a cygwin bash shell located several directories
deep within one physical drive, so that the ..'s are guaranteed to stay within
the same drive (i.e. so the path list above should never "cross mount points").
But cygpath still spits out absolute paths even in this case.
So, it is as if cypath always has the -a option on even if you do not specify
it.
Igor wrote:
>... if you don't have any symlinks in the relative path,
> you should be able to use the forward slash variant without
>using cygpath. All Windows system calls (and most Windows programs)
>understand forward slashes just fine.
Thanks for pointing out that most Windows system calls understand /'s just fine
too--I had observed that with java before, but did not realize that it was so
universal.
But the absence of symlinks will not help me avoid a call to cygpath because my
path list by default uses unix style : chars as path separators, but if the
script is running on windows (e.g. via cygwin), then the program that will use
that path list (java in my case) needs windows style ; path separators. (My
script is intelligent enough to autodetect if is being run on cygwin, and it
takes certain custom actions such as this in this case, because I want the
script to run on any unix.)
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
--
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: Almost nothing works for me in Cygwin 1.5.24-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I removed everything but "C:\Program Files\cygwin" from my PATH and I reinstalled Cygwin twice, from separate mirrors... Still getting the same errors. - -Rob -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) iD8DBQFHX3gK+KyO/KUp2FYRAhYqAJsHV3z8aeRawkV0YnQOYK+6W2KKigCdHI7s EOO4HfQwmijfbM0D/3xf83s= =v9Jo -END PGP SIGNATURE- cygcheck.out Description: Binary data -- 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/
