Doing "aclocal && automake && autoconf" as the autobook suggests
doesn't change things... =(
(or: it does seldom work, but usually doesn't.. that's why I'm
thinking about granularity in NT's timekeeping)
automake 1.7.x and later require autoconf-2.54 or newer. Ordinarily,
the wrapper script
Moti Daniel <[EMAIL PROTECTED]> wrote:
> 2 fixes to the line, it should be:
>
> sometarget:
> $(shell echo -e '$(VAR1)' >> $@)
>
> this $(shell... makes a file called "somefile", in it
> you will see:
> "
> a.o:a.c
> cc $@
> "
>
> I'm including this sometarget in the makefile thus extending i
Lapo Luchini wrote:
That's not the point: I have no problem on my cybwin developement
machine: the problem is that ./configure-generated Makefile tries to
call the autotools on each different machine, even in no-one changed
configure.in or Makefile.am
The client machine shouldn't need autotoo
I'm having a problem with chroot - see the following strace:
CYGWIN_NT-5.1 AVOCADO 1.3.17(0.67/3/2) 2002-11-27 18:54 i686 unknown
63 60329 [main] linexec 2652 normalize_posix_path: src .
61 60390 [main] linexec 2652 cwdstuff::get: posix
/home/chris/line/rootfs
55 60445 [main] linexe
In an earlier post, Larry Hall (RFK Partners, Inc) wrote:
>> The login shell stuff sent me to look at the etc/passwd file and the
>> stuff about that in the cygwin FAQ. As an occasional user of cygwin I
>> have to say I find these documents written at too high a level to
>> take in easily. A coup
At 12:55 PM 12/1/2002, Chris Game wrote:
>In an earlier post, Larry Hall (RFK Partners, Inc) wrote:
>
> >> The login shell stuff sent me to look at the etc/passwd file and the
> >> stuff about that in the cygwin FAQ. As an occasional user of cygwin I
> >> have to say I find these documents written
On Sat, 2002-11-30 at 12:28, Ralf Habacker wrote:
> Hi,
>
> while porting the threaded qt-3 release to cygwin, it seems to me, that there is
> a bug in the current pthread implementation.
What version of cygwin?
Rob
--
---
GPG key available at: http://users.bigpond.net.au/robertc/keys.txt.
---
Currently, the character set in cyrillic console seems to be cp1251,
while in cmd.exe it is cp866. Nothing too wrong with this, except that
cp1251 lacks pseudographic symbols.
I am using cygwin to run tin 1.4 with codepage translation table from
koi8-r to cp1251. So the pseudographics does not s
> I'm having a problem with chroot - see the following strace:
<--snip-->
> At the start of the strace chroot (".") has been called; it
> succeeds at time
> 63935. (The same problem occurs with chroot( rootfs>) as well).
> Then chdir ("/") is called at time 64000. The result of conv_to_posix_path
Can standard GPL v2 code be included in Cygwin?
What if I look at how that code does something and then write my own
implementation? What if the two implementations are very similar?
What if I tell someone else on the mailing list how to do it?
Chris
--
Unsubscribe info: http://cygwin.com/m
Hi,
Im not to sure about changing codepage, something to do with the CYGWIN
environment variable (codepage:???).
On the latter if your having problems building the dll use the instructions
from http://cygwin.com/cvs.html to get the sources and
http://www.cygwin.com/faq/faq.html#SEC103 as a guide
> -Original Message-
> From: Robert Collins [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, December 01, 2002 10:19 PM
> To: Ralf Habacker
> Cc: cygwin
> Subject: Re: problem with mutexattr initialisation
>
>
> On Sat, 2002-11-30 at 12:28, Ralf Habacker wrote:
> > Hi,
> >
> > while porting
When I try "chroot ." in bash I get:
$ chroot .
chroot: cannot execute /bin/sh: No such file or directory
> -Original Message-
> From: Chris January [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, December 01, 2002 5:08 PM
> To: [EMAIL PROTECTED]
> Subject: RE: problem with chroot causing Cygw
Rolf, Chris,
Chroot is a very big club, indeed. Unless you've set up a separate
execution environment (including binaries, libraries, configuration or
auxiliary files such as those ordinarily located in /etc or /lib, etc.),
very little will work after a successul "chroot" call.
Note that "chro
> > > I'm having a problem with chroot - see the following strace:
> >
> > <--snip-->
> >
> > > At the start of the strace chroot (".") has been called; it
> > succeeds
> > > at time 63935. (The same problem occurs with chroot( > > rootfs>) as well).
> > > Then chdir ("/") is called at time 64000.
Lapo got me started. "Blame" him ;-)...
Charles Wilson <[EMAIL PROTECTED]> wrote in
[EMAIL PROTECTED]:">news:[EMAIL PROTECTED]:
>>
>> The client machine shouldn't need autotools or the know-how to use
>> them, right?
>
> Not necessarily. If configure.in doesn't have AM_MAINTAINER_MODE,
> then
Chris,
When an exec(2) system call fails do to a file format problem (ENOEXEC) as
opposed to a file-not-found error (ENOENT) or a permission error (EPERM),
the fallback action taken by the shell is to interpret the file as a script.
One could argue that the shell should be a little more intell
> I'm having a problem with chroot - see the following strace:
> At the start of the strace chroot (".") has been called; it
> succeeds at time
> 63935. (The same problem occurs with chroot( rootfs>) as well).
> Then chdir ("/") is called at time 64000. The result of conv_to_posix_path
> at time 2
I've updated the version of zsh to 4.0.6-2.
This version has many, many fixes from the base Zsh team, about 640 lines
in the ChangeLog. The 4.0.4-4.0.6 changelog is here:
http://www.fruitbat.org/Cygwin/zsh/ChangeLog
My notes on setting up zsh are here:
http://www.fruitbat.org/Cygwin/zsh/zsh.note
19 matches
Mail list logo
